binary-provenance-audit.md

evidence/breadth-05/coverage/binary-provenance-audit.md
# Native binary provenance audit

## Finding

The retained evidence does **not** establish that the ordinary `loom` or `loom-dfg-sim` binaries were built from revision `48615bc5925ef4b9db8b4550b5d4322933cf4b7b`.

`breadth-autonomous-v1/subject-pin.json` records, in one pre-run check, checkout `git rev-parse HEAD = 48615…` and ordinary `loom` SHA-256 `85d37aaf871913771571f91d085fb36ebe2857f8a6d74e2e34196024d1621057`. It contains no build command, build timestamp, compiler/link receipt, embedded revision, or source-to-binary attestation. Slot results and raw-run records repeat that hash; they do not add origin evidence. The earlier `breadth-pilot-v1/infrastructure-corrections/subject-command-v1/validation.json` likewise binds the command, checkout revision, binary hash, and observed invocation result only.

No local `.ninja_log`, `CMakeCache.txt`, build manifest, or build receipt for these ordinary binaries was retained under project-data. I found no local record that maps SHA `85d37…` to a source commit. The simulator results name `build/tools/loom-dfg-sim/loom-dfg-sim` but do not retain even its SHA-256 in `breadth-12/RESULT.json` or `breadth-20/RESULT.json`, so their executable identity is weaker still.

The externally observed August 27 mtimes for both ordinary binaries, compared with the pinned revision's August 31 commit date, are evidence against a normal in-place build from the pinned revision. They are not sufficient to identify the actual source revision because copying/restoring can preserve or alter mtimes. Exact origin therefore remains unknown, with same-revision provenance unsupported and likely false.

## Publication qualification

Report the autonomous native outcomes as observations of the retained ordinary executable identity: for `loom`, SHA-256 `85d37…`; for the simulator, the recorded path with binary hash unavailable. Describe `48615…` as the checkout/source revision used to supply source and documentation, not as the verified build revision of those executables. Claims that these runs test implementation revision `48615…` should be withdrawn or explicitly marked unverified.

A freshly built instrumented executable at `48615…` is a new subject, not an instrumentation-only replay of the original executable. Before attaching its coverage to the original outcomes, compare per-case exit status, checker verdict, and materially relevant output against the retained ordinary-binary run. Any divergence must be reported as subject-version/provenance divergence; it cannot by itself be attributed to instrumentation or treated as a defect reproduced at `48615…`.

The current instrumented `loom-dfg-sim` build failure in `CgraClosedWait` (default construction of a `std::variant` under the current Clang 21/GCC 13 environment) leaves simulator coverage unavailable. It should be retained as a build/toolchain outcome. Repairing source would create another subject and is outside this coverage replay.

## Minimal stronger evidence, if available remotely

The useful read-only artifacts would be the ordinary build tree's `.ninja_log`, binary build ID/debug metadata or embedded revision strings, and any contemporaneous configure/build log that records both source HEAD and link output hash. `.ninja_log` alone can date the link but normally cannot prove the source commit. Without a receipt tying source tree state to the resulting hash, the conservative qualification above remains necessary.

## Evidence paths

- `experiments/breadth-autonomous-v1/subject-pin.json`
- `experiments/breadth-pilot-v1/infrastructure-corrections/subject-command-v1/validation.json`
- `experiments/breadth-autonomous-v1/slots/breadth-01/artifacts/raw_runs.txt`
- `experiments/breadth-autonomous-v1/slots/breadth-12/RESULT.json`
- `experiments/breadth-autonomous-v1/slots/breadth-20/RESULT.json`