Strict epoch transition conformance v1

Experimental local contract: four traces, 28 steps. It extends the fixed-corpus strict admission adapter without changing protocol messages or the runtime. Expected outcomes are specified in the generator, never captured from Rust.

Request and fixtures

Use epoch_trace with capacity and steps, explicitly selecting strict_v1. Load strict-epoch-fixtures-v1.json; initialize epoch 7 at [100,200) with the requested capacity and control conflict mode. The next fixture is an independently signed test claim for epoch 8 with a descriptor valid at [200,300). Its public test seed must not be used operationally. Existing admission/restart/usability/conflict steps retain the STRICT_TRANSITIONS_V1.md contract and harness receipt handles. Legacy adapter mode must refuse epoch_trace.

Additional observations

{"action":"advance","epoch":8,"start":200,"end":300,"now":200,"authentication":"strict_v1"}
{"action":"reopen_epoch","epoch":7,"start":100,"end":200}

advance copies the current policy and substitutes the supplied epoch, interval and authentication fields. It attempts durable rollover at now. On success, use the new policy and report advanced: true; on failure retain the old policy and report advanced: false plus reason. Both report journal_unchanged, claims and conflicts. The observation itself has ok: true; this does not mean the requested rollover succeeded. Invalid cases in this suite report reason invalid epoch transition without modifying the journal.

reopen_epoch closes the ledger and attempts reopening with the supplied epoch and interval, leaving other policy fields unchanged. Report accepted and journal_unchanged. If refused, reopen with the original current policy so later steps can verify continued operation. As with the earlier policy probe, compare all persisted admission-accounting bytes if using a different storage layout.

A valid rollover requires a strictly increasing epoch, a nonoverlapping interval, start <= now < end, no clock regression, and unchanged scope and authentication policy. It retires prior claim/conflict accounting. Old receipts are unusable and old claims are rejected. These local rules do not prescribe network-wide clocks, synchronized epochs or automatic policy migration.

Measured coverage

• Retire epoch-7 claims, admit epoch-8 claims and replay after restart.
• Preserve state on early/expired/non-increasing/overlapping or authentication-changing rollover requests.
• Refuse reopening epoch-8 state under epoch-7 policy; accept the current policy.
• Retire old conflict state and remain usable after restart.

The native adapter passes all four traces, plus the eight strict and six legacy transition regression traces. Fixtures regenerate byte-for-byte. Reports and source hashes live in docs/results/strict-epochs-v1/.

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

Fixture regeneration uses generate_strict_epoch_vectors.py with the existing cryptography test environment. Python is test tooling, not a runtime requirement.

Limits and next gate

These are same-author, finite, orderly local transitions. They do not establish power-loss durability, resistance to whole-directory rollback, distributed epoch agreement or full Core conformance. Python's authentication adapter implements no transition state machine. The next assurance gate is independent implementation of the published authentication, admission and epoch contracts, with discrepancies reported against these exact versioned suites. The hostile Fly progress target remains failed; transition conformance cannot turn best effort into a guarantee.