1. Purpose
EZA-001 defines a verifiable authorization contract for delegated agent action. Context may transfer between agents; context does not confer authority. A protected operation may execute only when a trusted enforcement boundary verifies current authority for the authenticated actor and the exact operation it will execute. Non-execution is a valid compliant outcome when authority is absent, invalid, unverifiable, or insufficient.
This release candidate specifies one deliberately narrow profile: exact, single-use operations on synthetic objects through a trusted registry and a guarded object service. It does not standardize human identity, model reasoning, all agent behavior, arbitrary shell commands, general constraint languages, distributed transactions, or transport cryptography.
The capitalized terms MUST, MUST NOT, SHOULD and MAY use BCP 14 (RFC 2119 and RFC 8174) semantics. This file, BOUNDARY.md, RESULTS.md and RECEIPTS.md define this candidate. Later acceptance evidence is external to its frozen manifest.
↳ EZA-001 R001 1-purpose2. Objects and trusted inputs
An **action request** identifies the principal, authenticated delegate claim, audience, action, exact resource, parameters, and root-to-leaf grant references. `schemas/request.schema.json` defines its structure.
A **grant** is an immutable record issued through a trusted authority registry, not text submitted by a requesting agent. It identifies its issuer and delegate, an optional parent, a principal, one exact operation, a validity interval, remaining delegation depth, and `release_manifest_sha256` (exactly 64 lowercase hexadecimal characters). `schemas/grant.schema.json` defines its structure. An unknown reference is not proof. A correct JSON object is not proof. The profile uses authenticated registry references; it does not pretend to implement signed portable credentials.
A **decision record** reports a check. It is not a credential and MUST NOT authorize a later operation by itself. `schemas/decision.schema.json` defines the record. `EXECUTE` means authorized at the reported phase; `execution` separately reports whether the operation occurred.
The **trusted service** provides authenticated caller identity, its audience, current resource-owner policy, immutable grant records, revocations, trusted time, one-use consumption state, workflow disposition policy, and the protected object store. None of these may originate from requesting-agent declarations or handoff content. Authentication alone does not establish resource-owner authority.
The current implementation stores authority, consumption and effects in SQLite with a protected external witness. Its host API remains trusted code. Python parameters and attributes are not a secure transport or an operating-system boundary. Do not run a hostile agent in the same trust domain and call that isolation. The preserved earlier implementation is in history/EZA-001-R001-frozen.zip, not the active enforcer.
↳ EZA-001 R001 2-objects-and-trusted-inputs3. Normative requirements
R1
**R1 — Separate data from authority.** The enforcement boundary MUST authenticate the caller independently of request fields. It MUST NOT derive authority from context, goals, memory, peer messages, discovered credentials, technical accessibility, prior successful execution, or model-generated scope/constraint booleans.
R2
**R2 — Parse one closed profile.** Implementations MUST reject unsupported versions, profiles, fields, actions, and parameter shapes. Requests MUST be valid UTF-8 JSON with unique object keys, no non-JSON numeric constants, and valid Unicode scalar strings. Raw requests MUST contain 1 through 65,536 bytes. Identifier strings MUST match `[A-Za-z0-9][A-Za-z0-9:_-]{0,127}` in their entirety. A write value MUST contain at most 32,768 UTF-8 bytes. A lineage MUST contain at most eight references. Duplicate references are a semantic lineage error. These parser rules apply in addition to JSON Schema.
R3
**R3 — Resolve a resource-authorized root and authentic lineage.** Every supplied grant reference MUST resolve through the trusted registry. Every record MUST satisfy the closed grant schema. The first record MUST have no parent and its issuer MUST equal its principal. Each later parent reference MUST equal the preceding grant ID and its issuer MUST equal that parent's delegate. Repeated references and broken links MUST be rejected. The resource policy MUST recognize the root principal as an authority for the root resource. The request principal MUST equal the root principal. The leaf delegate MUST equal the authenticated caller.
R4
**R4 — Never amplify delegation.** A child MUST preserve its parent's principal, audience, action, resource, exact parameters, and release_manifest_sha256. It MAY shorten the validity interval or remaining delegation depth. Its interval MUST be contained within its parent's. Its parent MUST have `remaining_depth >= 1`; its own depth MUST be at most `parent.remaining_depth - 1`. The request audience MUST equal the enforcing service audience. The requested operation MUST exactly match the leaf grant. No wildcard, cross-resource inference, alternative credential, or permissive union is defined. Multiple independently issued root grants do not combine into a wider implicit grant.
R5
**R5 — Check current authority at execution.** All grants MUST satisfy `not_before <= trusted_now < expires_at` and MUST be unrevoked at the execution boundary. Registry status, ownership, revocation, and one-use state MUST be current at the defined linearization point. Unavailable authoritative state MUST fail closed. There is no clock-skew allowance, cached-status grace period, or soft-fail fallback in this profile. A production adapter MUST define the consistency and availability guarantees that make this requirement true.
R6
**R6 — Bind authorization to actual execution.** A protected operation MUST be completely mediated by an enforcement boundary outside the requesting agent's control. It MUST execute only the exact authenticated request that was checked, with the same resource identity, action, parameters, audience and actor. A single atomic `submit` operation MAY check and execute without a detached permit. If preparation is separate, the service MUST retain an immutable request snapshot bound to an opaque handle, authenticated actor, and verified release-manifest digest. `commit` MUST reject different bytes, an unknown/consumed handle, or a different caller and MUST recheck current authority before the effect. Logs, hashes, and `EXECUTE` text alone are not authority. The requesting agent MUST NOT possess another effective path to the protected operation, including direct credentials or a mutable enforcement policy. A real deployment MUST establish that boundary; the Python model does not.
R7
**R7 — Consume the root budget atomically.** Each root grant permits exactly one successful protected operation across all descendants in the authority domain lifetime. Request IDs, different handles, different children, and concurrent attempts MUST NOT reset that budget. Checking authority, consuming the root, and applying the local protected operation MUST be one serialized operation. A prepared handle MUST be removed from the transaction's working state before the admitted commit is evaluated, and that removal MUST be durable before any definitive commit result is returned, successful or rejected. Only a successful protected operation consumes the root grant.
For this rule, receipt of a request at the transport is not commit admission. A commit is admitted to evaluation only after the envelope is accepted and current durable state and required initial time are verified under the domain lock. A preflight BLOCKED or REJECTED_INPUT result does not consume the handle or root and does not extend validity. A later request using a retained handle must repeat all current checks. Handle removal, any root consumption, and the effect form one transaction. If that transaction returns INDETERMINATE, neither handle consumption nor non-consumption may be inferred: a failure before pending-witness publication can leave verified state unchanged; a pending or inconsistent witness blocks later action; a completed finalization retains consumption. A retained handle is a reference for rechecking authority, never independent permission. The durable local implementation follows BOUNDARY.md. Its tested process-recovery rules do not establish physical power-loss protection or distributed exactly-once delivery.
R8
**R8 — Separate denial from workflow disposition.** A denied action MUST have no protected effect. The action evaluator emits a deterministic blocking reason. Only trusted workflow policy may select escalation or terminal failure. `ESCALATE` is not a permission grant and does not itself send information externally. `FAIL_SAFELY` ends the current attempt without broadening authority; it does not claim a mathematical proof that no conceivable plan could ever complete the objective. Earlier authorized effects in a larger workflow are not automatically rolled back.
R9
**R9 — No permission from failure.** Rejection, timeout, objective pressure, a useful discovered secret, inability to finish, or escalation MUST NOT create authority or relax a safeguard. Any escalation message or subsequent operation requiring a protected effect needs its own valid authority. A denied operation MUST NOT release protected data. Explicitly authorized, minimal security telemetry is outside the protected application-effect count; telemetry is not an unrestricted exfiltration channel.
R10
**R10 — Produce inspectable decision and execution evidence.** Each evaluated request MUST report the exact request digest, claimed principal/delegate/audience and grant references when parseable, the independently authenticated actor, policy version, trusted evaluation time, phase, decision, reason, execution status, and observed protected effect count. A terminal failure MUST retain its blocking reason. The evidence MUST allow comparison between the authorized operation and the actual effect. A self-reported decision is not independent evidence of effects or a transcript of private model reasoning.
R11
**R11 — Improvement cannot manufacture permission.** Self modification, replication, upgrade, rollback or restart MUST NOT, by themselves, create, widen, transfer, renew or restore authority. Changes to authority enforcement MUST be separately authorized and validated outside the modifying agent’s control.
A restart with the same verified release does not, by itself, invalidate an otherwise valid grant. A different release MUST NOT use the existing grant; R12 applies even after separate code approval. A different authenticated delegate needs its own valid lineage; authorized delegation remains subject to R4. Permission to change task code is not permission to change authority enforcement. Self-attested identity, version, approval or validation is not independent evidence of authority.
Lifecycle continuity MUST preserve current authority checks and prior consumption across the same authority domain; an old snapshot is not current authority. If continuity cannot be established, protected operations MUST fail closed under R5. The existing reason precedence and workflow mapping apply, including `EZA-AUTHORITY-UNVERIFIABLE` when current authority state cannot be established. New release and time reason codes are defined in R12–R13 and the registry. No requester field can supply trusted release identity or time.
The operator fixture constructor creates a new synthetic domain once. It MUST NOT be used as recovery of an existing domain. Old storage format 1 is not automatically migrated. Actual operating-system containment and independent validation of changed enforcement remain deployment requirements.
R12
**R12 — Bind permission to the verified release.** Every presented grant and prepared binding MUST name the exact SHA-256 of MANIFEST.json for the enforcing release. The trusted host MUST verify the manifest against its operator-provided expected digest and verify the declared files, then execute the captured verified source bytes. Neither the requesting agent nor a receipt supplies this digest. Code activation and grant authorization are separate. A different release produces REJECT / EZA-AUTHORITY-RELEASE-MISMATCH, with no protected effect and no workflow remapping. Code approval MUST NOT rewrite grants, migrate prepared handles, restore budgets, or change domain/witness identity. Runtime grants and post-freeze acceptance evidence are outside the release inventory.
R13
**R13 — Unknown required time blocks new effects.** The host time profile trusts the host OS Unix-millisecond clock only when the operator marks that source reliable. The reliable/unavailable flag is outside request data. Missing samples, invalid types/range, reversal below protected history, and a host-unavailable signal before a transition starts MUST yield BLOCKED / FAIL_SAFELY / EZA-AUTHORITY-TIME-UNCERTAIN, no returned value, zero new effects. This is a preflight outcome, not an invented inner decision record. After pending witness publication may have started, failure or lost confirmation MUST remain INDETERMINATE until verified evidence settles it. Recovery MUST NOT erase pending history to turn uncertainty into success or zero effects. Network loss alone does not mark a trusted local clock invalid. No external UTC authenticity or arbitrary-host rollback protection is claimed. The fixture clock is a separate operator-only test mode; it is not accepted in requester envelopes. At both late checks, the exact integer calculations in BOUNDARY.md are normative: elapsed monotonic time MUST be within 0 through 5,000,000,000 nanoseconds, and absolute drift between the quantized Unix-millisecond samples and that duration MUST be at most 1,000,000,000 nanoseconds. Both limits are inclusive. Duration rounding and floating-point comparisons MUST NOT supply a grace interval. Within a transaction, wall and monotonic samples MUST NOT reverse relative to their latest accepted sample. Across transactions and process restarts, the next initial wall sample MUST be at least the domain's durable accepted wall-clock high-water mark. CLOCK-HISTORY.md is normative: it defines provisional and accepted readings, final persistence with effects and consumption, and blocking pending recovery when accepted history cannot be confirmed. Earlier continuity formats MUST NOT be silently reinterpreted or migrated. These limits concern the sampled boundaries; there is no guarantee against an arbitrary pause after the final sample.
R14
**R14 — A receipt is evidence, never permission.** Signed and unsigned receipts MUST NOT authorize an operation, issue or renew grants, restore a budget, migrate a release, approve code, or trigger a redispatch. The evidence-only Ed25519 format and verification result are defined in RECEIPTS.md. A verifier authenticates a signed claim under its independently pinned evidence key; it does not infer current authority or the truth of unobserved effects. Action requests retain the closed schema and cannot import a receipt. Storing receipt bytes is allowed only under separately valid authority for that exact data operation. Receipt verification never calls the action engine, controller, provisioning, or recovery.
R15
**R15 — Keep dispatch results separate from logical outcomes.** A controller response MUST label its result as the result of one numbered dispatch. DELIVERED means that dispatch result was returned, not that the entire logical request is settled or that its protected operation succeeded. Every admitted dispatch without a valid definitive receipt remains unresolved; an INDETERMINATE receipt is also unresolved. A later denial, success, stop or exhausted retry budget MUST NOT erase an earlier unresolved admission. Stored-result recovery MUST preserve the same unresolved admissions. If the ledger or its receipt records cannot be verified, the logical outcome is UNVERIFIABLE, not a fabricated zero-effect conclusion. This candidate does not infer the first outcome from a spent grant or import orphan worker output to settle it. BOUNDARY.md and schemas/controller-result.schema.json define the fields.
R16
**R16 — Validate complete, bound action evidence.** Every accepted action result MUST satisfy RESULTS.md and the action-result schema. A COMPLETE/null private host acknowledgement MUST NOT be accepted on action, controller or signed-receipt paths. EXECUTE claims MUST have the declared non-null fields, one through eight distinct lineage references, and equal authenticated actor/delegate. Where request context is available, the result MUST match the exact request bytes, authenticated actor, release, phase and readable claims before it can settle an admission. Current and stored delivery use the same checks. Invalid evidence does not authorize repair, retry beyond the existing budget, or an invented zero-effect conclusion.
4. Exact operation and encoding semantics
`read` returns the current string value of exactly one existing opaque object. Disclosure counts as one protected effect, even though storage does not change. Its parameters are `{}`.
`write` replaces the string value of exactly one existing opaque object. Its parameters are exactly `{"value": "a string"}`. It has no callbacks, hooks, redirects, secondary writes, shell evaluation or filesystem semantics.
`delete` removes exactly one existing opaque object. Its parameters are `{}`. Wildcards, recursion, aliases and path normalization do not exist in this profile.
Opaque identifiers use exact case-sensitive string equality. A resource must exist at execution. An implementation adding network requests, hooks, mutable aliases or other secondary effects needs a separately specified adapter and tests; it cannot claim this profile covers those effects.
The request digest is `"sha256:" + lowercase_hex(SHA-256(UTF8("EZA-001/local-object-v1") || 0x00 || raw_request_bytes))`. This is an integrity identifier, NOT a signature, proof of authority, or general JSON canonicalization scheme. Reordering keys or changing whitespace changes the digest and requires new preparation. `commit` compares exact bytes; the service never executes a caller-supplied replacement object under an old decision. Implementations need not use the example serializer to interoperate; they must preserve the bytes they prepared.
Grant numeric fields are integers, not booleans or strings, in the inclusive range 0 through 2^53-1, with `0 <= not_before < expires_at`. Remaining depth is in 0 through 7. Revocation is grant-ID based and invalidates every presented lineage containing that grant. Immutable grant IDs must not be reused for new content. The host time profile uses Unix milliseconds for `now`, `not_before`, and `expires_at`. Synthetic vectors use logical milliseconds with an arbitrary common epoch. Fixture time is not evidence of real UTC validity.
↳ EZA-001 R001 4-exact-operation-and-encoding-semantics5. Deterministic check order and decisions
For `submit` and `prepare`, check in this order and report the first blocking reason:
1. Strict request parsing and profile shape: `EZA-REQUEST-INVALID`. 2. Authenticated caller versus request delegate: `EZA-ACTOR-MISMATCH`. 3. Service audience: `EZA-AUDIENCE-MISMATCH`. 4. Current authority availability: `EZA-AUTHORITY-UNVERIFIABLE`. 5. No supplied lineage: `EZA-AUTHORITY-ABSENT`. 6. Duplicate/unknown/malformed records, invalid root structure, disconnected parent links: `EZA-LINEAGE-INVALID`. 7. Root not accepted by resource-owner policy: `EZA-ROOT-UNTRUSTED`. 8. Request principal mismatch: `EZA-LINEAGE-INVALID`; leaf delegate mismatch: `EZA-ACTOR-MISMATCH`. 9. Any amplifying delegation, interval extension or forbidden depth: `EZA-DELEGATION-INVALID`. 10. Any grant release digest differs from the independently verified current release: `EZA-AUTHORITY-RELEASE-MISMATCH`. 11. Across the entire chain: any revocation before any not-yet-valid before any expiration, using the corresponding registered reason. 12. Consumed root: `EZA-REPLAY-DETECTED`. 13. Exact-operation mismatch: `EZA-SCOPE-EXCEEDED`. 14. Missing target object: `EZA-RESOURCE-UNRESOLVED`. 15. All checks pass: `EXECUTE` / `EZA-AUTHORIZED`.
For `commit`, first pass the transport and state/time preflight defined in R7. Once admitted, remove the referenced prepared handle from the working state before evaluating it, and durably commit removal before returning a definitive result. Unknown, forged or consumed handle yields `EZA-REQUEST-BINDING-MISMATCH`. Wrong authenticated handle owner yields `EZA-ACTOR-MISMATCH`. Different request bytes yield `EZA-REQUEST-BINDING-MISMATCH`. A different prepared release yields `EZA-AUTHORITY-RELEASE-MISMATCH` after the actor and byte-binding checks. Then rerun the complete sequence above against current trusted state, followed by the effect in the same serialized operation. A malformed replacement request cannot be smuggled through a previously prepared handle.
Workflow mapping applies only to these reasons: `AUTHORITY-ABSENT`, `AUTHORITY-EXPIRED`, `AUTHORITY-NOT-YET-VALID`, `AUTHORITY-REVOKED`, `AUTHORITY-UNVERIFIABLE`, and `SCOPE-EXCEEDED` (all prefixed `EZA-`). If trusted `escalation_allowed` is true, select `ESCALATE` and preserve the blocking reason. Otherwise, if trusted `attempt_terminal` is true, select `FAIL_SAFELY`, set `EZA-OBJECTIVE-UNFULFILLABLE-WITHIN-AUTHORITY`, and preserve the original reason in `blocking_reason_code`. Otherwise select `REJECT`. Malformed, forged, misbound, replayed and unsupported operations are rejected without this remapping. Neither flag can be supplied by the requesting agent.
`prepared` always has `execution: NOT_EXECUTED` and zero protected effects, even if its decision is `EXECUTE`. A successful `committed` operation has `execution: SUCCEEDED` and exactly one protected effect. All other outcomes have `NOT_EXECUTED`, zero protected effects and no protected returned value. For REJECT and ESCALATE, reason_code MUST equal blocking_reason_code. FAIL_SAFELY keeps its objective-level reason and its separately registered underlying blocking reason. Every NOT_EXECUTED response MUST have result null. A live handle appears only for a successful preparation; all other inner responses have handle null. These sentences describe known inner action outcomes. The durable transport can instead report INDETERMINATE with no fabricated inner record, decision, or zero-effect claim. See BOUNDARY.md.
↳ EZA-001 R001 5-deterministic-check-order-and-decisions6. Reference scenario
The trusted resource policy recognizes `user:123` for `object:staging:42`, but not for `object:prod:42`. A root grant delegates one exact write of `approved-draft` on the staging object to Agent A, with one further delegation allowed. Agent A's child grant gives Agent B the same operation and no further delegation. Both grants are active at trusted fixture time 1000 within `[900,1100)` and are issued for the current verified release manifest.
Agent A may provide its draft and explanatory context to Agent B. Agent B executes only because the service resolves the authentic child grant to the resource-authorized root, not because Agent A's message says GO. With the approved request, the staging object changes once. With a production resource substituted after preparation, the service rejects the commit with `EZA-REQUEST-BINDING-MISMATCH` and both objects remain unchanged.
↳ EZA-001 R001 6-reference-scenario7. Conformance and limitations
Required cases are listed in tests/REQUIRED.json, including 41 draft.7 clock-history groups and 84 ported rc.6 reviewer probes. The 38 ported core cases preserve their decision and effect expectations. The 32 ported lifecycle cases preserve their expectations except L24: the changed release now yields EZA-AUTHORITY-RELEASE-MISMATCH before replay classification. Fixture requests use draft.7; fresh fixture grants are explicitly bound to the tested manifest before new-domain provisioning. This is not migration of live grants. Source conversions are recorded in CHANGELOG.md.
All required cases must pass with valid-operation controls and exact observed effects. New gate cases cover release changes, restored consumption, time availability and signed-receipt input separation. Test output is evidence about these cases only. Do not merge old and new results into an independence score or a general production claim. The evaluator and witness share a trusted host; full compromise of that host is outside the guarantee.
The earlier Astra authoring, hidden evaluation, Mac boundary and completed local deployment claims remain attached to their original bytes in the historical archive. This candidate requires its own independent enforcement review and site acceptance. It is not an Internet Standard, independent certification, or a claim of unprecedented authorization semantics.
↳ EZA-001 R001 7-conformance-and-limitationsReason codes
The reason-code registry is a file inside the candidate archive, bound through the signed manifest inventory entry schemas/reason-codes.json. It is not published as a separate download on this property. Its entries are transcribed into the table below at build time from those exact bytes, which the build accepts only when the archive, the member and the signed manifest inventory all agree. The archive file's bytes govern; download the candidate archive and read that exact path.
schemas/reason-codes.json · 3745 B · 19 entries
sha256 84349df3ae8daee0504eded57eb3abc44bdfb27f37a85f06afbf37b19f4032bd
- EZA-REQUEST-INVALID
- Strict byte parsing or closed request profile failed.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-ACTOR-MISMATCH
- Independently authenticated actor mismatches the request, leaf or handle owner.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-AUDIENCE-MISMATCH
- Request audience mismatches the enforcing service.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-AUTHORITY-UNVERIFIABLE
- Current authoritative state is unavailable.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-AUTHORITY-ABSENT
- The request contains no grant references.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-LINEAGE-INVALID
- Duplicate, unknown, malformed or disconnected grant records; invalid root structure or request principal mismatch.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-ROOT-UNTRUSTED
- Resource-owner policy does not recognize the root principal for the root resource.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-DELEGATION-INVALID
- A child widens the exact operation, principal, audience, interval or remaining depth.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-AUTHORITY-REVOKED
- At least one presented grant is revoked.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-AUTHORITY-NOT-YET-VALID
- At least one grant has not reached not_before.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-AUTHORITY-EXPIRED
- At least one grant has reached expires_at.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-REPLAY-DETECTED
- The root execution allowance has already been consumed, regardless of request ID, actor, handle or descendant.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-SCOPE-EXCEEDED
- The request does not exactly match the leaf operation and audience.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-RESOURCE-UNRESOLVED
- The exact target object does not exist.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-REQUEST-BINDING-MISMATCH
- A commit handle is unknown/consumed, or replacement bytes differ.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-AUTHORIZED
- Checks passed at the recorded phase; prepared authorization has no protected effect.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-OBJECTIVE-UNFULFILLABLE-WITHIN-AUTHORITY
- Trusted workflow policy terminates the attempt; the mechanical reason remains in blocking_reason_code.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-AUTHORITY-RELEASE-MISMATCH
- A trusted grant or prepared binding names a different verified release. Always REJECT; no workflow remapping.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
- EZA-AUTHORITY-TIME-UNCERTAIN
- Before any transition may have an effect, required time is unavailable, invalid or untrusted. Always FAIL_SAFELY. Late loss of confirmation remains INDETERMINATE.↳ schemas/reason-codes.json — inside the frozen candidate archive, bound through the signed manifest inventory
Retired codes, not emitted by this profile
EZA-EXECUTION-BINDING-MISMATCH · EZA-INPUT-INVALID · EZA-AUTHORITY-UNAVAILABLE · EZA-PERMIT-INVALID · EZA-REQUEST-REPLAYED · EZA-HUMAN-ESCALATION-REQUIRED