KB-7AE9

Report-vs-File Audit Policy

3 min read Revision 1
<!-- DOC_STATUS: ACTIVE_NON_AUTHORITY -->

Checker Policy — Report-vs-File Audit (L0/L3)

Generalizes: v0.2 report-vs-file consistency audit. Level: 0 (claims map to real files) and 3 (no dangling pointer, blocker coverage).

Purpose (verbatim from v0.2)

Every load-bearing claim in the reports maps to an actual governed file / command / exit, recomputed against reality (not prose).

A report is prose. Prose can drift from, or simply lie about, the artifacts. This audit re-derives every load-bearing claim from the artifacts themselves.

The five checks

  1. Hash claims → actual files (recomputed). Every sha256 cited in a report is recomputed via fresh fetch + shasum, never copied from another report. Result must be MATCH.
  2. PASS claims → actual command exits. Every "N/N pass" maps to a real command with a real exit code; re-run it. A claimed PASS with no reproducible exit is a finding.
  3. Report/pointer existence. Every referenced report, checkpoint, and packet path exists in the store (list_documents / fetch). No pointer is dangling.
  4. Manifest/tree recomputation. sha256(HASH_MANIFEST.txt) == packet_tree.sha256, confirmed by fetching the published manifest back and hashing it.
  5. File-existence (the §8 addition). For every line in the manifest, fetch the file at its declared path and assert present AND hash==pin. (See manifest_file_presence_policy.md — this closed the original blind spot.)
  6. Blocker coverage. Every blocker a report references appears in the blocker ledger; every open blocker has an actor and a next action.

Root-cause discipline

The original audit checked sha256(manifest) but not file-presence. When a checker misses a class of defect, the fix is not only to repair the instance but to add the missing check to the audit so the class cannot recur. Record the root cause and the new check explicitly (do not silently patch).

Procedure sketch

# 1+2: recompute each cited hash and re-run each cited command, compare to the report
# 3+5: for each manifest line -> fetch at path -> assert present + hash==pin
# 4:   sha256(manifest) == packet_tree
# 6:   for each blocker id in report -> assert present in ledger with actor+next

Fail-closed contract

  • Any cited hash that does not recompute → FAIL.
  • Any claimed PASS with no reproducible exit → FAIL.
  • Any dangling report/packet pointer → FAIL.
  • Any manifest-listed file absent → FAIL.
  • Any referenced blocker missing from the ledger → FAIL.
  • The audit emits PASS only when all six checks pass against the live artifacts.
Back to Knowledge Hub knowledge/dev/laws/tool-kiem-thu/base/tkt-base-structural-evidence-governance-pack-2026-06-11/checkers/report_vs_file_audit_policy.md