// reproducibility bench

proof bench

Every forensic engine output below is pinned to a committed golden file. On every commit, npm run check:flagship re-runs each engine against the same fixed synthetic inputs and fails the build if a single byte of output drifts. This page is that gate, made public — a skeptic’s view of exactly what is proven.

728goldens re-verified / commit
107reference scenarios
294distinct forensic tools

how this stays honest

Two layers of determinism, both gated in CI:

engine layer — these 728 goldens. Same build SHA + same inputs → byte-identical output, or the build fails. This table is generated from the goldens and drift-checked by npm run forensics:verify-proof-bench, so it can never overstate what is tested.
session layer — a case can export a case.replay.json recipe (tool · version · build SHA · input + expected output SHA-256). See validation methodology.
parser layer — renaming or removing a recognized vendor field, or regressing a fidelity verdict, fails CI via the drift detector. Honest per-parser grades live on the parser-grade ledger.

Scope: all inputs are synthetic. Goldens prove the engines are deterministic and unchanged — they are not a claim that an engine is exhaustive. The fidelity ledger is where coverage is graded honestly.

scenario goldens (107)

sorted by golden count — the most-exercised scenarios first. each engine run is re-verified against the scenario’s pinned synthetic evidence.

proof index validation methodology parser-grade ledger fixture packs

this bench reflects the live committed goldens — regenerated by npm run forensics:gen-proof-bench and drift-gated in npm run check. it cannot drift from what CI actually runs.