Idea
v1.6.23 is a machine-readable governance release.
The pressure behind this version is straightforward: if Ota asks humans, CI, and...
For further actions, you may consider blocking this person and/or reporting abuse
governance has to be emitted as structured truth is the right target, but the hard half isn't emitting it, it's keeping the emitted thing honest after it ships. a JSON receipt that says approved: reason X can lie exactly as confidently as a human comment, and it's worse because it looks like data so nobody re-reads it. the failure i keep hitting: someone edits the enforcement branch, nobody touches the code that writes the governance field, and now the structured truth is structured and wrong. what i'd want next to these fields is a reconciliation guarantee, the receipt built on the same line where the decision is made rather than assembled afterward from a second read of state, plus a preflight check that what the receipt claims fired actually fired. move the reason into the branch that grants it and there's no second place to forget it.
the --reason flag on crossing/merge is the same theme one level down. a free-text reason a human types is self-attested, so the receipt captures what the operator claimed, not what got verified. still a real gain because the claim is now attributable, but it'd be worth making the schema say which fields are captured (the human asserted this) vs derived (the system checked this), since an agent consuming them downstream will otherwise treat both as equally true. good direction, evidence as a first-class output is what agent contracts have been missing.
Strong point. Emitting governance as JSON is only half the job; the harder part is keeping it reconciled with the exact branch that made the decision.
The direction for Ota is the same one you’re describing: the authoritative record should be emitted at the decision site, not reconstructed afterward from a second read of state, and the schema should distinguish caller-asserted fields from runner-derived or boundary-attested ones.
That’s the next governance trust refinement I’m adding to Ota.
Where have you seen this drift most in practice: the runner decision itself, CI/merge wiring, or the emitted receipt/evidence layer?
the receipt/evidence layer, and it's not close, but the reason is the useful part: drift tracks distance from the decision. the runner decision itself basically can't drift, it does whatever the branch says by definition, it IS the source of truth. CI/merge wiring drifts in one narrow way, a threshold duplicated between the gate and the runtime so the gate blesses something the runner would have scored differently, but you catch that the first time the two disagree loudly. the receipt is where it hurts because it's maximum distance: written later, usually in a different module, from a second read of state, and it's the exact layer everyone downstream trusts as THE record. so the drift is easiest precisely where the blast radius is biggest.
the concrete shape i hit most: a field recomputed at serialize-time. a row gets scored while spend reads 6000, then a later normalization stage rewrites spend into a bucket, and when the receipt re-reads spend to explain the score it cites the bucket, not the 6000 the decision actually used. nothing errored, the score is unchanged, the story next to it just quietly stopped matching the inputs it was built from. that's the whole reason i test that the points named in the reason sum to the score, it's the cheapest tripwire for exactly this.
on your taxonomy, caller-asserted / runner-derived / boundary-attested is the right cut and boundary-attested is the sneaky bucket. it FEELS derived because the system observed it, but it's captured from outside your trust boundary, so its ceiling is only as good as whatever attested it. if you don't tag it explicitly it silently collapses into runner-derived and gets trusted a notch above what it earned, which is the same class of bug as a narrated reason, just about provenance instead of logic.
Very apt!
I agree on boundary-attested being the sneaky bucket. It arrives structured so people instinctively over-trust it, but provenance-wise it is still only as strong as the boundary that attested it.
This is directly shaping Ota for me too: authoritative governance needs to be recorded at the decision site, not recomputed later, and provenance class needs to stay explicit instead of collapsing into one generic “machine-generated” bucket.
When this goes wrong in practice, what usually ends up being the most useful tripwire first: field-level reconciliation like your points-to-score check, hook/branch identity checks, or provenance-class mismatches?
field-level reconciliation, and it's not close either, for a reason that generalizes: it watches the outcome, not the mechanism. a reconciliation check fails only when the record is already lying, which means zero false alarms from benign refactors, and it catches the end symptom regardless of which upstream cause produced it, renarrated field, stale threshold, serialize-time recompute, all of them eventually break the arithmetic. one tripwire, many failure classes, and it costs an afternoon: parse your own output, assert the parts sum to the whole. it's also the only one of the three that's self-explanatory when it goes red, whoever sees the failure understands the crime without knowing your taxonomy.
provenance-class mismatch is the second layer, and the reason it can't be first is also the reason it's indispensable: it catches the lie reconciliation can't see. a receipt can reconcile perfectly while citing boundary-attested data as if it were derived, the arithmetic is clean and the trust label is wrong. the practical version isn't really a tripwire though, it's a schema decision: make the class a REQUIRED field on every value, and the silent collapse into "machine-generated" becomes a validation error instead of a judgment call. you get the check almost for free by refusing to let the field be optional.
hook/branch identity checks i'd build last or not at all. they watch the mechanism, and mechanisms churn legitimately, every refactor makes them cry wolf, and a check that cries wolf gets disabled, which is worse than not having it. the one place they earn their keep is when the decision output has no arithmetic to reconcile, pure allow/deny with no parts, then identity is the only handle left. so the ordering principle i'd hand ota: first the check that fails only when the harm is real, then the one that catches lies arithmetic can't see, and only then the ones that watch how instead of what.
Watch the outcome first, not the mechanism, that’s a very strong rule.
Field-level reconciliation catches the real harm with almost no false alarms, and provenance-class checks catch the trust inflation that arithmetic cannot see.
So, when the decision is pure allow/deny with no arithmetic to reconcile, what has ended up being the least noisy tripwire in practice?