Local admission transition profile v1

Experimental profile · 5 September 2026 · fixed-corpus conformance subset

Boundary and state

This profile tests the durable local authorization boundary after signed-byte parsing. It does not standardize Beacon JSON or network APIs. The corpus uses five independently signed Python fixtures with deliberately simple floating-point values. General cross-language Beacon canonicalization remains unresolved.

State consists of pinned policy, accepted claim IDs and receipts, credential-slot allocations, quarantined slots, and a committed time watermark. A valid receipt means permission to compete for retention, never a storage or attention grant. The local disk and clock assumptions in Core Draft 0 apply.

Operations and transition rules

admit(claim, descriptor, now) MUST validate policy/epoch, descriptor binding and lease, proof eligibility, signatures, slot accounting, and capacity before acknowledging a new allocation. A new allocation is appended and synced before a receipt is returned. Exact replay revalidates inputs and returns the original receipt without another allocation. Invalid attempts MUST NOT change accounting. The current profile does not advance its watermark on replay or rejection.

A differently bound claim in an occupied slot is rejected. This rejection alone MUST NOT quarantine the slot: an unauthenticated attempted rebind is not evidence. conflict(first, second, now) authenticates both distinct allocations for the same credential slot, then durably records quarantine. Duplicate valid evidence is an idempotent no-op. Reversed evidence order has the same identity. Evidence does not require either descriptor to have been locally retained.

usable(receipt, now) is a read-only current-policy check. Unknown, expired, quarantined, or rollback-time receipts are unusable. In the preserved saturation control, a full conflict registry also disables unrelated sponsored receipts. Open-cost receipts are not disabled by that registry. Callers MUST recheck usability before acting on a previously issued receipt.

restart closes and reopens the ledger under exactly the same pinned policy. Committed allocations and quarantine survive. This trace operation is a clean reopen, not a power-loss or interrupted-write test. The harness retains receipt values as an external caller would; it does not reconstruct them from disk.

Executable adapter contract

An admission_trace JSON request contains capacity (1–16) and steps (0–64). Every request starts a fresh ledger. Policy and named fixtures are exactly those in conformance/transition-fixtures.json; an independent adapter must load that corpus, not synthesize equivalent-looking descriptors. Steps are:

{"action":"admit","fixture":"a","now":100}
{"action":"usable","fixture":"a","now":199}
{"action":"conflict","first":"a","second":"b","now":100}
{"action":"restart"}

The response is {"ok":true,"results":[...]}. Every step result contains ok, claims, and conflicts; admission/restart add no fields, usability adds usable, and successful conflict processing adds changed. Rejected operations include error. The exact fixture-specific expected errors are in the suite; these are local harness diagnostics, not public protocol error messages. Unknown fields are rejected by the adapter. Unknown fixtures or invalid limits abort the trace.

The five fixtures are a and b (same credential slot, different descriptors), c (another slot), open (sufficient eight-bit work), and weak (authentic but insufficient work). Their signatures and object hashes are constructed with Python hashlib/cryptography. Expected state counts are separately stated in the generator, not recorded from Rust output.

Coverage and limitations

Six traces cover 34 operations: replay, clean reopen, expiry, work rejection, backward time, claim capacity, conflict rejection, durable quarantine, duplicate evidence, unrelated sponsorship suspension, and the separate open-cost lane. The runner executes the actual Rust ledger through the adapter.

This is neither a complete transition standard nor proof of crash safety. Missing traces include policy rollover, corrupt journals, failed sync, key revocation, evidence delivery, multiple replicas, and arbitrary malformed descriptors. Existing Rust tests cover some of these separately; that is not independent conformance. Full Core conformance remains unavailable.