The validation architecture

It helps to keep two questions apart. Verification asks whether the system was built as specified, and it has something to check against: the tests, the spec, the constitution. Agents handle it increasingly well. Validation asks whether the specified system is the right one, and the only reference for that question is human intent itself, including the parts nobody has put into words yet. Those parts tend to surface when a person uses the running software, and for that reason validation stays with humans in this method, at every level of automation. The limit comes from the structure of the question, so it does not shrink as models improve.

Three demo points, placed by risk

Human attention is a limited budget, so the method places it where the risk of building the wrong thing is highest rather than spreading it over everything.

The skeleton demo. The first slice of any feature is a walking skeleton: thin, ugly, end to end, and shown to a human before more slices are built. In the order-system example, this demo revealed within five minutes that the table showed one row per invoice line while the user thinks in whole orders. The fix cost half a slice at that point; found at the end, it would have affected the whole feature.

The feature demo. Before a feature seals, a human walks through the running software in full. In the example, the customer’s operations lead drove it herself, on a copy of her real data, and completed a simulated month-end close in 22 minutes without exporting to Excel.

Risk-pulled demos. Slices that touched the constitution, stopped the line, or sit in drift-prone areas get a short demo on demand. One slice in the example touched the idempotency clause, and five minutes of hands-on checking of the retry behavior settled it.

The verdict is a small artifact

Every demo ends in one of three recorded outcomes. Here is the record from the feature demo above:

# Verdict: reconciliation view / feature demo
Verdict: MISALIGNED (partial) and INTENT EVOLVED
Driven by: ops lead (customer), hands on keyboard

Feedback: credit-memo placement makes month-end matching harder.
No written intent mentioned this; she had never seen it laid out.

Resulting artifacts:
- 2 spec changes drafted and approved in session -> 1 small story
- new feature intent filed: "reconciliation view for credit memos"

Feedback that shows a mismatch becomes spec changes before the session ends. The third outcome, “intent evolved”, records that seeing the software changed what people want. The method files this as a discovery rather than a defect, and in the example project the reconciliation feature itself had started as exactly this kind of finding at an earlier demo.

Demos are driven, not watched

One rule in this area allows no exceptions: a demo watched as a recording, or read as a summary, does not count as validation. Agents may prepare everything, including the environment, the data, and the walkthrough script, but during validation the human operates the software directly. The value of the gate lies in direct contact with the running system, and a summary in between removes exactly the part that matters.

Why the gate matters more as automation grows

Agents that improve their own process will optimize whatever they can measure, and internal measures tend to lose their connection to what people actually care about. The recorded demo verdicts serve as the outside measure that keeps this in check: proposed process changes are evaluated against them rather than against internal numbers. In the example project, an agent proposal to shorten skeleton demos was declined because the verdict history showed those demos catching 60 percent of all mismatches. So the demo keeps its place even in a highly automated setup, as the measurement that everything else is judged against.

Full treatment: Keeping humans in charge of what matters.