In a nested form model, why must values, errors, touched flags and field registration share one path scheme?

## What a path is Once a form holds arrays of objects, a field cannot be named by a single identifier. It is named by a **path** — an ordered list of segments read from the root of the model. A name segment means "key of an object"; a numeric segment means "position in an array". A path is either kept as an array of segments or flattened into a string with a separator, and that choice has consequences (below). The path exists because the form has to answer questions about a field that is *not* a variable anywhere: "what is this field's value", "does it have an error", "has the user touched it", "is its control live right now". Each answer lives in a different structure, and the path is the join key between them. ## The four tables one path has to serve | Table | What it stores | What breaks with a private scheme | |---|---|---| | Values | the data itself, nested | none — this is usually the scheme everything else must adopt | | Errors | a verdict per field | a verdict that cannot be matched to the field that produced it | | Flags | touched, dirty, visited | errors shown before the field was edited, or never shown | | Registration | which controls are live | rules running for fields with no control, or skipped for live ones | The asymmetry matters: values are naturally nested, while errors and flags are usually kept flat, keyed by the stringified path. That is fine — as long as the key really is the same path the value is stored at. ## Ambiguity: the cost of flattening A path flattened with a dot separator is ambiguous the moment a field name contains a dot. A field literally named `a.b` and a nested pair `a` then `b` produce the same key, so one field's error can land on the other, and a lookup can return a sibling's value. The same applies to bracket notation and any name containing a bracket or a quote. The defences: - keep paths as **arrays of segments** internally and flatten only for display or as a map key with an escape rule; - **escape** the separator when flattening, and unescape on parse — never build the key by naive concatenation; - forbid separators in field names at the point the schema is declared, which is cheaper than escaping but constrains the data model; - treat a numeric-looking name segment carefully: if a number always means "array position", an object whose keys are numbers cannot be addressed unambiguously. ## Why a reorder is the hard case A numeric segment encodes a **position**, and position is exactly the property a reorder changes. So after a move: 1. The value array is correct — the entries moved, and the path to each value is *by definition* wherever it now sits. 2. Any flat table keyed by the old stringified path is now wrong: the verdict at position 2 describes whatever used to be there. 3. Registration keyed by path is wrong in the same way, so a rule may run against a control that belongs to a different row. The fix is not to abandon paths — they are how nested data is addressed — but to key the **row** by its own identity and derive the path from the row's current position at the moment of the lookup, or to re-map every path-keyed table inside the same update that performs the move. Either way the move is a single transaction across the tables, not an array operation with cleanup afterwards. ## Registration and the phantom field Registration is the table candidates forget. When a conditional field or a removed row stops rendering, its entry must be withdrawn, or the model still believes a field exists at that path: its rule keeps running, its verdict keeps counting toward overall validity, and submit stays blocked by something with no control to point at. The symmetric bug is over-eager withdrawal — unregistering on any re-render, so a field that is still on screen loses its rule. ## Where models differ A runtime that re-runs the component function tends to rebuild the path for each field on every render, so a path computed once and captured becomes stale. A fine-grained runtime often hands each field a subscription tied to its path, so a moved row needs its subscription re-pointed. A compile-time runtime can resolve some paths statically for fixed fields but not for array positions, which are only known at runtime. The invariant survives all three. ## The practical rules - One scheme, declared once, used by every table. - Paths as segment arrays; flatten only with escaping. - Rows carry identity; positions are derived, never stored as the identity. - Mount and unmount move registration in the same update as the value.