Where does a cross-field rule such as confirm-password or a start-before-end date range attach, and when must it re-run?

Most rules are a function of one value. A cross-field rule is a function of two or more - passwords that must match, a range whose end must not precede its start, a total that must equal the sum of its parts, a field that becomes required because of another field's answer. Everything awkward about them follows from that arity. ## Where the rule attaches - **On the enclosing group.** The rule is declared where both values are visible - the form object, or the sub-object holding the pair. It runs whenever any value inside that group changes, and it names the field that should display its message. This is the shape most declarative schemas use, because the rule's scope and its inputs coincide. - **On one field, with declared dependencies.** The rule sits on the field that will show the message, and lists the other fields it reads. The form builds a dependency map and re-runs the rule when any listed field changes. This keeps errors co-located with the field that displays them, at the cost of a registration step that is easy to forget. What does not work is a rule attached to one field that silently reaches for another value at run time. It produces a correct verdict at the wrong moments: it runs when its own field changes, and not when the value it secretly depends on does. ## The dependency-map problem The requirement is one sentence long: **a change to a field re-runs every rule that reads that field**, not merely the rules declared on it. Getting it wrong looks like this: 1. The user types a password, then a mismatching confirmation. The pair rule runs, and the confirm field shows a mismatch. 2. The user corrects the *first* field. Its own rules re-run and pass. 3. Nothing re-ran the pair rule, so the confirm field still shows the mismatch over two values that now agree. The user's only escape is to touch the confirm field again, which they have no reason to do, since the message is pointing at a field they consider finished. | Rule shape | Re-runs when | Message shown on | |---|---|---| | Single-field rule | That field changes | That field | | Pair rule on the group | Either participant changes | A nominated field, or the group | | Pair rule on one field with declared inputs | That field or any declared input changes | The declaring field | | Pair rule reaching for another value implicitly | Only its own field changes (the bug) | The declaring field, staler than it looks | ## Timing at the edges - **Wait for both participants.** A range rule over an empty end date has nothing to compare. Report the emptiness with the field's own required rule and hold the range verdict until both sides have values, otherwise the user gets a confusing complaint about the range while the real problem is a missing value. - **Order the rules.** Run cheap per-field rules first and let the cross-field rule run only when its inputs individually pass. A date-range comparison against an unparseable date produces nonsense. - **Pick one owner for the message.** Printing the same complaint on both fields doubles the noise; the convention is to show it on the second field of the pair, the one the user most recently completed, and to leave the first clean. - **Clear on both paths.** When the rule passes, the message must disappear even if the field that shows it was not the field that changed. This is the same eager-clearing discipline single-field rules need, applied through the dependency map. - **Respect the display gate.** A cross-field error should still wait for the participants to be touched, or for a submit attempt. A rule that fires the instant the first of two fields is filled accuses the user of a mismatch they were never given a chance to avoid. ## Two-or-more, and conditional requirements The same machinery covers rules with more than two inputs (a set of percentages that must sum to a total) and rules where one field's answer changes another field's rule entirely - a shipping method that makes an address required. In the second case the dependency is on a *rule*, not just a verdict: changing the controlling field changes which rules apply to the dependent one, so the dependent field must be re-judged, and a message raised under the previous configuration must be dropped rather than left standing. ## What the framework does and does not give you A runtime with fine-grained tracking makes this almost free: express the verdict as a derived value that reads both fields, and the framework re-computes it exactly when either changes, because the dependency is observed rather than declared. A runtime that re-runs the component function recomputes everything anyway, so the derivation is also automatic - the risk there is a rule wired to a change handler rather than to the value. Where rules are registered imperatively with a form library, the dependency list is manual, and a missing entry is invisible until a user fixes the wrong half of a pair.