A corrected reply can leave a broken workflow.

This small executable example accompanies Repair the claim. Recheck the consequences. Compare leaving a result unchanged, fixing the reply, and checking the affected workflow state.

There is no language model here. Five hand-authored fixtures and exact checks make the state changes visible. This is an illustration, not a benchmark or a production system.

Try a case

What the checks cover

The policy allows a 14-day return window, conditional eligibility and human approval. The reply must leave the decision pending; the handoff must request review; the case must remain open; no payment may have been sent.

The dependencies are explicit: policy → reply → handoff and case state. They are supplied by the example, not discovered by an AI. A system with unknown dependencies needs a different way to establish that its checks are complete.

When repair stops

Each strategy gets at most one repair. Missing or conflicting policy evidence causes escalation. A payment already sent also causes escalation: changing a local status does not undo an external action.

Run and inspect it

Download the JavaScript source, then run it with Node.js:

node repair-checks.mjs

The output lists each fixture, strategy, repair count and remaining failures. The same source drives this page and the downloadable example.

What remains untested

These checks do not evaluate source truth, natural-language interpretation, prompt injection, model-judge bias, unknown downstream effects, latency or cost. Passing them establishes only that the supplied state satisfies these five rules. A real evaluation would need independently reviewed examples, held-out cases and a simpler baseline.