When a constraint fails deep inside a nested object or a list element, how is the field path built and where does it mislead the caller?

## How the path is built A validation engine validates a model graph, not a flat record. It descends: for each property it checks the rules declared there, and where a property is itself a model, or a collection of them, it walks into it and keeps going. As it descends it composes a path, appending one segment per step. The composed segments are typically: - a **property name** for a plain step: `customer` - an **index** for a positional collection element: `items[2]` - a **key** for a keyed collection entry: `attributes[colour]` - the **container's own path** when the rule is on the collection rather than on an element: a "at least one item" rule fails at `items`, not at `items[0]` So a rule on the quantity of the third ordered line fails at `items[2].quantity`, and a caller who can read that path can highlight exactly one input control out of fifty. ## Where it misleads the caller ### The names are model names, not wire names This is the defect that ships most often. The path is composed from the **property names of the typed model**. The body the client sent used whatever names the serializer maps to — a different casing convention, an explicitly renamed property, a flattened nested structure. A client searching its own form for `shippingAddress.postCode` finds nothing when it sent `shipping_address.post_code`. The fix is mechanical but must be deliberate: the converter translates each segment through **the same naming rules the mapper used**, rather than emitting model names and hoping. Where a property was renamed individually, the translation has to consult that rename, which is why teams that care keep model and wire names identical and let one naming strategy do the rest. ### Indexes are only as stable as the collection An index means "the element at this position **in what was validated**". If the server filtered, sorted or deduplicated the collection during binding, position *n* on the server is not position *n* in the caller's form. For unordered collections there is no meaningful index at all, and engines fall back on an arbitrary position or an element identifier. Where elements carry a natural identifier, reporting it alongside the index gives the caller something that survives reordering. ### Container and element rules look alike and are not `items` failing a size rule means "send a different number of lines"; `items[0].quantity` failing means "fix this one number". Flattening both into "items has an error" makes the client highlight the whole section for a single bad field, which callers read as the API not knowing what it wants. ### Segment syntax is not free text Any path syntax has to survive names that contain its own separators — a keyed entry whose key holds a dot or a bracket will break a naive split. The converter should emit segments the client can parse unambiguously, either by escaping them or by carrying the path as an ordered list of segments and letting the published format be assembled from that. ## A practical rule for the converter 1. Build from the engine's structural path, never by string-concatenating in the handler. 2. Translate each segment into wire naming, using the mapper's own rules. 3. Preserve the container/element distinction rather than collapsing it. 4. Keep a machine-readable structure available, and derive whatever textual form the contract publishes. 5. Test with a deliberately nasty payload: a nested model inside the second element of a list inside another model. Shallow tests rarely catch the naming mismatch, because at depth one the names usually coincide. ## What the caller actually does with a path Worth stating plainly, because it sets the bar for correctness. A client receives the error body and, for each entry, looks up the input control registered under that path and attaches the message to it. That lookup is an exact match against the names the client itself used when it built the request. It does not guess, it does not fuzzy-match, and when the lookup misses, most clients fall back to showing a generic banner — or to showing nothing. So a path that is merely *nearly* right produces the worst outcome available: the server did the work of finding every failure, the response carries all of it, and the user sees "something went wrong". Nothing in the server's logs records that the caller could not use the answer, which is why this class of bug survives for months. The reliable signals are a client-side metric counting unmatched paths and a contract test that asserts the exact path strings for a deliberately nested payload. ## Why this is a senior question Every part of it works perfectly in a demo with one flat model and fails in production against a real payload: nested structures, renamed properties, lists the server tidies before validating. The candidate who has lived through it names the model-to-wire naming mismatch immediately, because it is the bug that made a client's field highlighting silently do nothing while every server-side test stayed green.