Protocol / v0.1
Five gates. Fail closed at every one.
A run either crosses all five gates and returns a sealed receipt, or it stops at the first gate it cannot satisfy.
Authorization vs. consequenceAuthorization decides whether an action may run. Yuvin goes further: it reserves the target, bounds execution, and verifies the resulting source state. Ordinary allow/deny is one part of the boundary; governed consequence adds reservation, bounded dispatch, readback, and a sealed final receipt.
This page describes public behavioral guarantees. It is not a specification of connector implementations, policy compilation, signing internals, or deployment topology.
The gates
- 01EvidenceIs mandatory proof valid and bound?
- 02Policy + AuthorityMay this exact action happen now?
- 03ReservationIs the target exclusively held?
- 04ExecutionMay one bounded attempt cross?
- 05ReadbackDoes the source match expected state?
Normative rules
Six rules. Open one for its full text and its failure mode.
R1 / A proposal is a candidate, never a permission.
A candidate names one action, one target, the evidence it depends on, and the state expected afterwards. It is frozen before evaluation. Anything not named in the candidate cannot happen.
Missing or ambiguous target → reject before Gate 1.
R2 / Evidence must be valid, bound, and current.
Each mandatory proof is bound to this candidate, not to the session or the agent. Validity windows are evaluated at decision time, not at attachment time.
Expired, unbound, or absent proof → blocked at Gate 1.
R3 / Authority lives outside the model.
Policy, human grant, scope, and time window are resolved from systems the model cannot write to. Authority is matched against the exact action and target, including amounts and identifiers.
Scope mismatch or missing grant → blocked at Gate 2.
R4 / The target is held exclusively before dispatch.
A reservation prevents a concurrent or duplicate attempt from reaching the same target. Without a reservation there is no bounded attempt, only a hope.
Reservation unavailable → blocked at Gate 3, no dispatch.
R5 / Exactly one bounded attempt may cross.
Dispatch is a single authorized attempt with an explicit budget. Retries are new candidates that re-enter at Gate 1.
Budget exhausted or ambiguous acknowledgement → recovery path, not a retry loop.
R6 / Success is read back from the source.
Final state is read from the system of record and compared to the expected state declared in the candidate. A connector acknowledgement is not proof.
Mismatch or unreadable source → run is not verified, and the receipt says so.
Receipt schema
What a governed run leaves behind.
Every run emits the same structure, verified or blocked.
Receipt JSONverified example
{
"receipt": "rcp_8f2ca91e",
"issued": "2026-03-04T09:12:41Z",
"candidate": {
"action": "deploy",
"target": "service-web/production",
"expected_state": { "digest": "8f2c" }
},
"gates": {
"evidence": { "state": "pass", "ref": "ci:sig/8f2c/a91e" },
"authority": { "state": "pass", "ref": "change-427", "scope": "deploy" },
"reservation": { "state": "pass", "ref": "env:prod/service-web" },
"execution": { "state": "pass", "attempts": 1, "budget": 1 },
"readback": { "state": "pass", "source_state": { "digest": "8f2c" } }
},
"final_state": "verified",
"side_effects": 1
}