Audit architecture — register, execute, adjudicate, correct, replay, preserve

Register. Claims carry structured predicates sealed before their adjudicating data; predicates are immutable after first adjudication (an HTTP 409 HARKing guard). Registries seal append-only with SHA-256 manifests, annotated tags, GitHub releases, and OpenTimestamps Bitcoin anchors (blocks 959483–960086).

Execute. An event-sourced engine archives every rendered prompt, completion, decoding configuration, action, payoff, seed, and provenance field — 5,505 completed runs, 54,276 rounds, 108,552 seat decisions, 36,251 provider-request events. Sealed execution schedules, transactional budget caps, and fail-closed freezes govern dispatch.

Adjudicate. Verdicts come from sealed adjudicator code that never reads claim prose, with selftest fixtures; the author adjudicated nothing. Twelve registered author predictions were refuted and published.

Correct. External review exposed family-error, dependence, construct, and boundary-uncertainty defects. Corrections are additive: sealed records are never edited; current interpretations travel beside them. A 22-instance process-failure ledger is public; every resolution that touched confirmatory standing went the conservative direction.

Replay. The public capsule verifies 4,919 archived Phase 3–5 runs (4,916 confirmatory + 3 legacy diagnostics) with zero credentials and zero live model calls: 4,896 LLM runs byte-exact plus 20 deterministic baselines independently recomputed.

Preserve. Sealed discussion branches, the v10 text freeze, manuscript history, and the dead-predictions ledger keep the interpretive record inspectable. The boundary is stated in the paper: the pipeline can enforce a registered predicate exactly; it cannot guarantee that the predicate represents a valid estimand, test family, or construct.