System Architecture & Deterministic Runtime Specification

The invariant has a direct consequence: nothing inside the execution substrate may decide, mid-flight, that a transition is still permissible. Alignment is not maintained by the model or the operator's discipline — it is re-established, by deterministic gate and external verification, at every boundary where an execution token is granted. A persuasive argument is not a verdict. Momentum is not admissibility.

The runtime is organized into three strictly ordered tiers. Each tier owns one class of failure, and no tier may borrow the authority of another.

There are no blanket execution passes. Each consequential transition requires a fresh verified receipt, derived from post-step telemetry and the updated reality conditions reported by the boundary. A receipt certifies exactly one transition — the one that follows it — and nothing beyond it.

This is what makes the runtime safe under dynamic condition shifts. If external conditions change mid-cycle, or the evidence returned by the boundary becomes indeterminate — a revoked verdict, an UNKNOWN state — execution drops into a frozen checkpoint anchored to the last verified state hash. The substrate never attempts ungrounded self-recovery: it does not invent the verdict it was denied, does not downgrade a revoked grant to a warning, and does not continue on stale authorization. Resumption requires a fresh verified receipt, nothing less.

Checkpointed state persistence

State is persisted only at step boundaries, and each boundary is anchored by its immutable state hash. A checkpoint is addressable and verifiable, never mutated in place — resuming from a checkpoint means resuming from the hash, not from a best guess of where work left off.

Deterministic idempotency keys

Every external write payload carries an idempotency key derived deterministically from the step's state hash and action contract. A retried step re-derives the same key, so a duplicate execution is absorbed by the receiver rather than duplicated in the world. Side-effects are counted once, by construction.

Fail-closed suspension vs. exponential backoff

Fault isolation is stratified by fault class. Transient network layer failures — timeouts, 5xx responses, connection resets — trigger exponential backoff with deterministic jitter, retrying the same atomic step under the same token. Admissibility failures — INADMISSIBLE or UNKNOWN verdicts, revoked receipts, boundary drift — trigger fail-closed suspension. Backoff resumes work; suspension requires re-verification.

The distinction is the point: the runtime can be patient with the network and inflexible with its boundary, and it never confuses the two.

The full request path, from ingress through the admissibility boundary to per-step receipt chaining:

[ Ingress Payload ]
      │ (t₀ Hash)
      ▼
[ State Root Commit ]
      │
      ▼
[ Upstream Admissibility Boundary (UAB) / Deterministic Gate ]
      ├── If INADMISSIBLE / UNKNOWN ──► [ Fail-Closed Freeze + Telemetry Receipt ]
      └── If ADMISSIBLE ──────────────► [ Token Grant: Atomic Step Execution ]
                                                │
                                                ▼
                                       [ Step Receipt Generated ]
                                                │ (Loop back for Step N+1 re-verification)

Two exit paths exist and only two: a token grant that advances the machine to the next atomic step, or a fail-closed freeze that preserves the last verified state hash until re-verification. Everything else — persuasion, mood, momentum, a well-argued exception — is not an exit path and is not representable in the machine.