This is a tooling and decisions-log change. It touches nothing under content/, AGENTS.md or protocols/, and adds no citations. The arbiter-core change broadens the §3.15 checks rather than loosening them: RUN_RECORD and SEAT_REPLY now match run records and raw replies at any depth under proposals/, and an off-path record is flagged in its section title. The account also names every file a record says it wrote that is absent at head, and its self-describing header is updated to match the code, closing the gap that let #426's experiment runs reach the panel as 'no run records'. The tests pin the edges: proposals/run.yaml and content/.../run.yaml are excluded, .problems.txt is not a reply, and sitting runs read as before. A reply is still marked 'carried' (cut first) only when it matches an installed assessment in the change, so nothing is newly hidden. The check.ts change adds provenance by stamping inputHash with the sha256 of the blind packet every seat is sent. The DECISIONS entry states plainly that the earlier design sentence about a ledger hash was wrong and that the six experiment runs predate the fix. Declining point 3 (the seat-written runId tag) is answered on the record with a concrete reason: replies are identified by run directory and filename, and the verb's unique stamp goes on installed assessments. That is the 'fix or reply saying why not' route §3.15 prescribes for a lone review note. The 'Supervised-by: founder (direction in session, 2026-09-29)' stamp follows the prior entry's convention, and I see no positive evidence it is invented. Suggestions only, not violations: state in the schema that a check run's inputHash is the packet's hash, not the ledger's. Also ensure the follow-up actually corrects the experiment's 'hold everything' note and the design sentence as promised.

The change strengthens provenance and auditability: `runAccount` now discovers run records at any depth under `proposals/`, identifies files a run claims to have written but which are absent, and compares nested runs’ seat replies with installed assessments. `runCheck` now records a SHA-256 hash of the packet sent to seats, addressing the prior `inputHash: null` gap without presenting historical runs as having hashes they lacked. The decisions entry explicitly preserves that historical limitation and stamps the founder supervision with date and channel rather than retroactively altering provenance. The diff neither edits AGENTS.md nor weakens a constitutional check, and the added tests cover both ordinary and experimentally filed runs.

This pull request directly answers review note #428 by enhancing tooling around run accounting and check provenance. In `src/lib/arbiter-core.mjs`, `RUN_RECORD` and `SEAT_REPLY` regexes are widened to recognize runs filed at deeper paths under `proposals/`, and `runAccount` now explicitly reports files a run record claimed to write that are missing at the head revision. In `src/pipeline/check.ts`, `run.stamp.inputHash` is properly populated with the sha256 hash of the blind packet sent to the seats. These changes strengthen inspectability without weakening any checks or touching AGENTS.md.

The diff only touches arbiter run-account tooling, the check verb’s inputHash stamp, matching tests, and a DECISIONS.md entry. It expands RUN_RECORD/SEAT_REPLY so a check run filed under an experiment folder is still accounted for, labels that location, and names wrote-paths absent at head—fixing the prior gap that hid runs rather than weakening §3.15. Stamping sha256 of the sent packet on the run record improves provenance; no AGENTS.md edit, no content/ citations, and no fabricated records appear. The third point (shared tag in raw replies) is left unchanged with a recorded rationale and does not loosen any check.

This is a tooling-only change answering review note #428, and it strengthens rather than weakens the §3.15 checks: the run account now reads run records wherever they are filed under proposals/, names files a run record claims to have written that are absent from the repository, and compares raw seat replies with installed assessments — closing exactly the visibility gap the OpenAI seat objected to (three check runs reaching the panel as 'no run records'). The new inputHash stamp in src/pipeline/check.ts adds provenance (what ledger a check judged) that was previously missing, with tests covering it; nothing here dodges or loosens a check. The decision not to change the runId tag inside raw replies is argued concretely (the verb's own stamp sits on the installed assessment; replies are identified by directory and file name; forcing a per-run id into the packet would break vendor caching) and is an editorial judgment recorded in DECISIONS.md, not a weakening of a §3.15 check. No AGENTS.md edit, no content/ change, no citations added, no confidence material, and the founder-direction stamps in DECISIONS.md follow the recorded-channel rule. The historical claims about the experiment's runs and the caching figures postdate what I can verify from the packet, but nothing in the material is internally inconsistent, and the follow-up change that will report the experiment's ledger hash is flagged rather than hidden.