update_goal could say "complete" but never say what it ran, what it skipped, or
what it is worried about. The first is checkable and the other two are not, and
that asymmetry is the design: `verified` commands are matched against this
session's real receipts, while `unverified` and `risks` are declarations the
host has no way to infer and therefore keeps verbatim.
A claim can only add. Every host-found gap survives reconciliation untouched, so
accepting the model's account costs nothing in strictness — and a verification
that never ran, exited non-zero, or last ran before the newest mutation becomes
an unbacked_claim gap, leading the report because it is the worst kind.
The claim rides the ledger: update_goal receipts already carry their arguments,
so the report reads the latest successful call and needs no new plumbing. A
rejected call claims nothing.
e2ebench prices it as unbacked claims — asserted verifications the ledger
denied. Behavior is unchanged: the goal FSM still gates exactly as before, and
the report still only observes.
esengine
4caf5d7f2f
