@Joseph Manion Joseph — this is the sharpest pushback I've had on any of these posts, and it names a gap I'd papered over. Honest answer to your question: partially. I store the raw label and the role the agent extracted, so both survive. But the parsed result isn't a typed object — it's a free-text field — and there's no validation gate between interpretation and output. My fail-closed rule covers missing data, not ambiguous interpretation. Those aren't the same failure. One thing about my setup that makes your point sharper rather than weaker: my agent doesn't place orders. It builds a card and sends it to my phone, and I enter it manually. Sounds like a human-in-the-loop safeguard — except the whole design goal is that I can enter it blind, without opening a chart. So functionally the card is the execution authority. The human step verifies nothing. I'm adopting your structure. Natural language as the authoring interface, compiled to a typed intent, validated, stored alongside the decision. Interpretation drift is exactly the kind of thing that bites silently for months — same class of failure as the six stale rules I found in last week's review. Thanks for this.

@Joseph Manion The replay trail you describe is already in the spec — raw label, compiled intent, parse status, spec version, and the final card fields all land on one line in the card log. One thing missing: my ID is per run, not per decision, and one trigger can produce several cards. Fixing that. The schema-vs-semantic split is the real gap, and I'd missed it. My parse_status is binary and only covers parseability. A confidently wrong interpretation gets ok and flows straight through to a card I'm meant to act on blind. The spec fail-closes on an unparseable trigger but has nothing for parseable and wrong. Your breakeven example hits a field I actually have — the intent carries an after_fill action. Nothing currently checks that its preconditions are present and mutually consistent. Adding a cross-field consistency layer, splitting the status into schema/semantic, and a third state for ambiguous that fail-closes. Worth noting your Day 39 and Day 40 points are the same failure class: a check that appears to have run without verifying anything. That's the boundary I need to make explicit, not just another missing-data branch.

@Joseph Manion Joseph — both landed, and both are built. The traceability table is in place: every output and failure mode now has the step that produces it, the evidence, the validator, and the response when validation fails. Thanks for the tips — this kind of pushback is worth more than agreement.

@Joseph Manion Ran your suggestion against the spec on paper before building the stubs — it found a gap immediately. Faults 1–3 and 5–7 all have a defined response. The one that doesn't: what happens when the validator itself is unavailable. The traceability table names a validator per output, but nothing says what to do when that dependency is broken. Default behaviour would be to skip validation and continue — so the output looks validated when it isn't. Worst possible failure mode, and it was invisible until I framed it as an injection. The false-success case isn't hypothetical for me either. My TradingView connector returns success: true on things that didn't happen — it has overwritten a finished template and a saved layout that way. The spec has a row for it. Never tested it. Real injection has to wait until the agent is actually running; you can't inject a fault into a document. But the paper pass is cheap and catches spec gaps before they get built in. Thanks — good call.

@Nora Saulīte totally agreed.

@Nora Saulīte - The SOP is a great tool to map out these things. Lots of things I did not think of by myself, but Lewis is showing us the path