RFC 0008: Sealed Runs — deterministic replay across the watershed

[BigBirdReturns]

What changed

• accepts RFC 0008, Sealed Runs — Deterministic Replay Across the Watershed
• records the delegated owner rulings for D1–D8 in the durable decision record
• defines an additive replay-run@1 profile and replays@1 extension; no frozen kernel change
• distinguishes replay-verified checkpoints from completed and abandoned runs through a signed run_status and terminal-action cross-check
• requires a self-contained Genesis profile and frozen vectors rather than a floating dependency on an Arc repository tip
• requires an Arc-first determinism and durable-state inventory preflight before any replay format freezes

Why

The AXM family already has both halves of the larger medium, separated by product line:

• the games line executes content-addressed authored law deterministically, but its exported run is a summary rather than a replayable record;
• the ops line seals, signs, and independently verifies immutable records, but its shards do not execute.

This RFC defines the narrow convergence boundary: games clients produce a complete canonical replay package, Genesis seals it unchanged through the one-pass compiler, and a profile-aware independent verifier re-executes and byte-compares every checkpoint.

The cross-line audit also closed three gaps before acceptance:

• unimplemented profiles remain honestly unchecked under existing Genesis law; they do not invent a profile failure code;
• every normative replay rule and vector required by a stranded verifier is frozen in Genesis, with Arc remaining the authoring source rather than a live dependency;
• an in-progress artifact proves a complete prefix only. It cannot be presented as a completed run without a matching terminal action, status, and final state.

The native unsigned run remains playable and holder-owned. Kernel PASS, self-replay, profile-checked replay, independent replay, and time attestation remain distinct claims.

Ratification

The owner explicitly delegated the convergence decision and implementation lane on 2026-07-14. RFC 0008 is therefore ACCEPTED, with D1–D8 recorded inline as delegated rulings and still auditable/overrulable by the owner.

Merging this RFC accepts the lane and its walls. It does not claim the profile is implemented. Implementation follows the ordered Arc-first sequence recorded in the RFC, beginning with a format-free determinism preflight.

Checks

• git diff --check — clean
• documentation-only change; GitHub CI is the authoritative repository gate

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6a457f524f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Start the journal after the founding state

This line makes the founding transition part of journal.jsonl, but the frame contract above says every journal frame is a transition after founding-state.json and requires frame 0's before_state_sha256 to equal the hash of founding-state.json. If one implementation records founding as frame 0 while another treats founding as the pre-journal bootstrap, their frame counts, hash chains, and status checks will not interoperate, so the RFC should unambiguously say the journal starts with the first post-founding transition.

Useful? React with 👍 / 👎.