Strict local admission transition conformance v1

Experimental adapter contract. This suite applies the strict authentication predicate to durable local admission; it does not define a journal byte format. Expected outcomes are authored separately from the Rust adapter. The author is shared, so this is not independent implementation evidence.

Inputs and state

Run strict-transitions-v1.json against an adapter explicitly selecting strict_v1. Load the named objects and signed claim bytes from strict-transition-fixtures-v1.json. Each request is a fresh isolated ledger with the fixture policy, overridden max_claims = capacity, no prior claims/conflicts and the control conflict mode. Capacity is 1–16; at most 64 steps are allowed. Fixture seeds and signatures are public test material, never operational identities.

The existing admission_trace operations admit, usable, conflict and restart retain their transition contract. Restart reopens persisted accounting; the test harness retains receipt handles for subsequent usability probes. Authentication never confers retention, retrieval or attention. Replays must revalidate signatures.

The additional step is:

{"action":"reopen_policy","authentication":"legacy"}

Close the ledger and attempt reopening it with only the requested authentication policy changed. Report accepted from that attempt and journal_unchanged from comparing the journal before and after. If the attempt fails, reopen with the original policy so later steps can test continued operation. If it succeeds, use the requested policy. Report ok: true, these two booleans, and current claims and conflicts; this is an observation operation, so ok does not mean the requested policy was accepted. Same-policy reopen must succeed without mutation; strict-to-legacy reopen must fail without mutation. An implementation with another storage layout should compare all persisted admission-accounting bytes instead.

Coverage and limits

Eight traces contain 46 steps: replay/restart/expiry, conflict quarantine, capacity, insufficient work, clock ordering, saturated conflict handling, weak identity/issuer/claim/descriptor signatures and policy-pinned reopen. Bad signature attempts after a valid admission cannot exploit an existing claim cache entry.

The identity fixture has adequate open cost and weak identity signatures; it must fail strict authentication. Other negative fixtures preserve the original claim binding while changing one signature. No expected result is captured from the adapter. The generator derives public fixtures and hand-specifies outputs.

This corpus is finite. It does not cover arbitrary objects, crash/power loss, malicious disk rollback, epoch transitions, network negotiation, Thread/Vault verification or full Core conformance. The Python authentication adapter does not implement these transitions. Strict capacity/driver traces remain unsupported.

Reproduction

python3 conformance/generate_strict_transition_vectors.py
cargo build --release --locked --features strict-auth --example core_conformance
python3 conformance/run.py --suite conformance/strict-transitions-v1.json --output NEW_REPORT.json -- target/release/examples/core_conformance --strict-auth

The native reference passes 8/8 strict traces. The six legacy traces still pass without --strict-auth. See docs/results/strict-transitions-v1/ for results.