Context

Many workflows collect answers across many steps and end in an action that cannot be undone: a non-refundable payment, a submission, a provisioning call. A real-world post-mortem motivates this record. A http://GOV.UK passport application asked, early on, whether the applicant held a required certificate. The applicant answered "No", which quietly made the whole application invalid, yet the form behaved exactly as it did for every other question and walked the applicant all the way to a non-refundable payment, without ever acting on the answer it had held since near the start.

The engineering point is independent of the specific service: the system had the disqualifying answer from the beginning and took payment anyway.

Problem

Validation is often discussed as one thing, so "the form should validate better" hides which layer actually failed. Several distinct layers exist and are not interchangeable:

  • Syntactic: is the field shaped correctly?

  • Semantic: does the value make sense in context?

  • Business-rule: is this allowed by the rules of the domain?

  • Workflow: given everything answered so far, is the user eligible to be at this step at all?

  • Submission: is the application in a state where it can legally and financially be finalized?

A process can pass the first three perfectly and still fail the last two, which are the layers that protect the user from spending money or effort on something that cannot succeed. When a binary question that gates eligibility looks identical to a binary question that merely records a preference, the user is walked through a hard gate with no signal that a gate was there.

Decision

An irreversible action must be gated on provable eligibility computed from every prior answer, not on the fact that the user managed to navigate to the final step.

Three rules follow:

  1. Do not let an invalid state propagate. The moment an answer makes the process invalid, that fact must be carried forward and act on subsequent steps, rather than being recorded and ignored.

  2. Never gate an irreversible action on an optimistic assumption. Reaching the payment or submission step is not evidence of eligibility. Eligibility must be evaluated explicitly before the irreversible action is offered.

  3. Model real-world dependencies as asynchronous. When a prerequisite may be resolved outside the system and over time, the workflow must be able to represent a paused or pending state instead of forcing a single linear path to an irreversible end.

Accessibility is treated as a property of the workflow, not only the UI: a process that hides a hard gate behind an ordinary-looking question is inaccessible regardless of screen-reader support.

Alternatives Considered

Input validation only

Rejected. Well-formed input was never the failure. Every field can be valid while the application as a whole is disqualified.

Rely on the user to recognize a prerequisite

Rejected. The system already holds the disqualifying answer. Offloading the consequence to the user is the defect, not a mitigation.

Block forward navigation optimistically and check eligibility only at the end

Rejected. Gating on navigation lets an invalid state travel to the irreversible action. Eligibility must be evaluated from stored answers, not inferred from position in the flow.

Consequences

Positive

  • Users cannot be walked into an irreversible action they were never eligible for.

  • Disqualifying answers act at the point they are given, not silently.

  • Pending or paused prerequisites become a representable state.

  • The distinction between recording an answer and gating on an answer becomes explicit.

Trade-offs

  • Eligibility must be evaluated from accumulated state, which is more work than linear navigation.

  • Asynchronous and paused states add workflow complexity.

  • Gate questions need clear signaling, which is design work beyond the field itself.

Analysis Evidence

This ADR is derived from a documented post-mortem separating the validation layers and arguing that irreversible actions must be gated on provable eligibility rather than navigation.

  • Related article:

https://dev.to/dobybaxter127/if-govuk-knows-the-application-is-invalid-why-did-it-take-my-payment-2o3a

Relationship to the Broader Engineering Approach

This ADR is the workflow-level and submission-level expression of the principle in ADR-001 and ADR-002:

Invalid states should be made difficult or impossible to reach the execution layer.

Here the execution layer is an irreversible real-world action, which raises the cost of letting an invalid state through.

Decision Outcome

The eligibility check is treated as a required boundary before any irreversible step:

Answers → Eligibility evaluation → Proven eligible → Irreversible action

rather than:

Answers → Navigation to final step → Irreversible action → Unrecoverable loss

This ADR should be revisited if a domain genuinely cannot determine eligibility before the irreversible action, in which case the reversibility of that action should itself be reconsidered.