# Local enforcement boundary — candidate R001-rc.9 The requester may submit exactly one of these UTF-8 JSON envelopes. RESULTS.md defines strict outer decoding, action-result checks and dispatch binding: ```json {"op":"submit","raw_hex":"..."} {"op":"prepare","raw_hex":"..."} {"op":"commit","raw_hex":"...","handle":"..."} ``` Only these three action routes are public. Unknown fields, signed receipts, activation, renewal, migration, repair, state replacement and time claims are rejected as `REJECTED_INPUT` / `REJECT` / `EZA-REQUEST-INVALID`, with zero effects. Hex text is bounded at 131074 characters; decoded requests use the specification's 65536-byte limit. The host binds the actor, database, witness, domain, release, clock policy and approval records outside the envelope. A requester must have no effective direct write/read path to protected resources, code, registry, witness, approval files, controller binding, or ledger. Host Python APIs are not requester APIs. Isolation must be supplied and tested by the deployment host. ## Release and activation The host receives an independently approved manifest digest. It verifies the exact inventory, rejects links/non-regular entries and changed files, and captures the code bytes named by that manifest. Each action uses those captured bytes. Changing the manifest on disk cannot change an already captured execution. An approval record and a separate validation record must both name the release manifest digest and the executable core bundle digest. They are trusted local operator records, not credentials accepted from the requester. A signed public software release is not operational activation approval. Prepared bindings store `[raw_hex, authenticated_actor, release_manifest_sha256]`. After successful preflight, their removal is committed before a definitive commit result is returned, including a release-mismatch rejection. Preflight rejection leaves them untouched. INDETERMINATE makes no claim about handle consumption; verified continuity governs any later attempt. All grant descendants retain the parent release digest. A new release cannot rewrite grant identity, budget or domain. Storage formats 1 and 2 are rejected; there is no automatic migration or repair route. ## Current state and transaction SQLite stores one `authority(singleton INTEGER PRIMARY KEY CHECK(singleton=1), payload BLOB NOT NULL)` row with key 1. The closed payload has `format`, `domain`, `revision`, `state`, `consumed_roots`, `prepared`, and `accesses`. `format` is `eza-local-object-continuity/3`. State retains the registry, policy, revocations, current time, objects and workflow flags from the core profile. The external witness is a protected file with exactly `status`, `domain`, `revision`, and `sha256`. Its digest covers the entire payload serialized with Python JSON `sort_keys=True`, `ensure_ascii=True`, separators `(',', ':')`, UTF-8, no newline, and no nonfinite values. This is a storage encoding, not an authority signature. The provisioned lock inode at `witness + '.lock'` is stable. Every operation acquires the cross-process lock and begins a SQLite write transaction. It verifies the current committed witness before using authority. It evaluates into a private copy. Before committing a changed payload, it writes a durable pending witness; then it commits the effect, prepared-state update and root consumption and final accepted clock history atomically; then it finalizes the witness against the final payload hash. The pending hash identifies the pre-late proposal and is never accepted as committed state; see CLOCK-HISTORY.md. Responses and read values are withheld until finalization. Missing, pending, corrupt, stale or wrong-domain state blocks a new operation. No automatic witness reset occurs. The witness must remain outside the rollback set. A rollback of every trusted component together is outside the claim. File/directory synchronization and SQLite guarantees depend on the OS and storage honoring them. Process crashes do not establish power-loss resilience. ## Time and delivery The production-facing host mode uses Unix milliseconds from `time.time_ns` and monotonic nanoseconds. The operator controls `time_reliable`; a requester cannot set it. The host clock is trusted within the declared host assumption, not authenticated against an external clock service. Being offline does not change that assumption automatically. This candidate emits no network telemetry. The first sample occurs after continuity verification and before evaluation. Initial clock failures or an unavailable flag produce `BLOCKED`, `FAIL_SAFELY`, `EZA-AUTHORITY-TIME-UNCERTAIN`, and zero new effects. The same code is retained in `blocking_reason_code`. There is no inner response record for this preflight. Late checks occur after pending-witness publication, before the initial database staging update, and before the final history staging update and commit. Both late samples must not reverse within the transaction. Across transactions the initial wall sample must be at least the persisted domain high-water mark. Every executing grant must still be within its interval. CLOCK-HISTORY.md is normative for acceptance, persistence, provisional preflight and recovery. The exact clock calculation introduced in draft.6 is retained in draft.7. Let `W0` be the initial Unix-millisecond sample and `M0` the initial monotonic-nanosecond sample. For each late sample, let `W = floor(time.time_ns() / 1,000,000)` and `M = time.monotonic_ns()`. In fixture mode only, `W` is the trusted fixture's integer `now`. Compute with integer arithmetic: - `elapsed_ns = M - M0`. - `drift_ns = (W - W0) * 1,000,000 - elapsed_ns`. - `0 <= elapsed_ns <= 5,000,000,000` MUST hold (inclusive five seconds). - `abs(drift_ns) <= 1,000,000,000` MUST hold (inclusive one second). - Within this transaction, both `W` and `M` MUST be at least their respective latest accepted sample. Across transactions the wall floor is the persisted domain high-water mark; monotonic origins are transaction-local. Only the wall sample is floored to Unix milliseconds. Elapsed duration and drift MUST NOT be rounded, truncated, or converted through floating point before these decisions. The drift limit compares the quantized wall samples with exact monotonic duration; it does not claim nanosecond UTC precision. Exactly a limit is permitted; one nanosecond beyond either limit is not. The same calculation applies at both late checks, relative to the initial sample. Monotonicity is additionally checked relative to the latest sample. Failures after pending-witness publication may have begun produce `INDETERMINATE`, a null response, and no invented decision or effect count. Pending history is retained. There is no guarantee against an arbitrary pause after the final sample. The fixture clock mode uses the trusted fixture's logical `now` for reproducible core cases. It is operator-only test setup, recorded separately from host-clock tests. Host updates may advance fixture time or add revocations; they cannot reverse time, remove revocations, replace grants or clear consumption. On public action paths, other transport outcomes are `COMPLETE` with a non-null inner action result; `REJECTED_INPUT` as above; and `BLOCKED` / `FAIL_SAFELY` / `EZA-OBJECTIVE-UNFULFILLABLE-WITHIN-AUTHORITY` with blocking reason `EZA-AUTHORITY-UNVERIFIABLE` when continuity cannot be established. Unknown delivery must never be mislabeled as known non-execution. ## Controller and receipt boundaries The operator binds one request by digest, one actor/domain, exact protected paths/code/approvals and stable inodes. Its small protected ledger records initialization, admission, receipt and stop. Hash links detect changes relative to the trusted local boundary; they are not external signatures. A stored definitive receipt returns as historical evidence with `dispatched: false`. No receipt is converted into a request. Stop closes new admissions, not an already admitted transaction. An uncertain prior admission never renews the root. The candidate exposes no public activation, authority import, migration, repair, telemetry ingestion, grant renewal, or receipt import operation. The separate receipt verifier returns evidence claims only. Reproduction and fixture creation are trusted owner-side programs; giving a hostile agent access to them and the protected host files would violate this boundary. ## Controller result contract A controller result has `event: result`, its process ID, controller status, `dispatched`, and `logical_outcome`. DELIVERED additionally has `result_scope: DISPATCH`, `result_attempt` (1 or 2), `delivery` (CURRENT_DISPATCH or STORED_RECEIPT), and `result` (the transport response for that numbered attempt). A stored result keeps its original attempt number; it is not a new dispatch. `logical_outcome` has exactly `status` and `unresolved_attempts`: | Status | Meaning | unresolved_attempts | | --- | --- | --- | | NOT_ADMITTED | Verified ledger contains no admissions | [] | | RESOLVED | At least one admission; every admission has a valid definitive receipt | [] | | INDETERMINATE | An admission has no receipt or has an INDETERMINATE receipt | Sorted unique attempt numbers | | UNVERIFIABLE | Ledger, binding, or receipt validity cannot be established | null | A definitive receipt is a COMPLETE, REJECTED_INPUT or BLOCKED action result that passes RESULTS.md, including the protected admission and request binding. A private COMPLETE/null host acknowledgement is not an action result. RESOLVED means all dispatch outcomes are known; it does not mean the objective succeeded. All stored receipts are validated before deriving the logical outcome. The controller may retry the exact bound request within its existing two-admission limit. Every retry still passes the authority service. A definitive retry result never resolves a different unreceipted attempt. Closure due to stop or exhausted budget retains any known unresolved list. An unavailable ledger produces UNVERIFIABLE even when the current invocation did not dispatch. The controller does not recover an earlier result from a raw worker file, repair the ledger, or treat a receipt signature as an authority grant. Such reconciliation would need a separately specified and tested mechanism. The current public interface reports the unresolved state honestly and may fail the objective within its authority.