MATCH 1
The measured bound matches the claim.
DRIFT 1
The claim says 3 comparisons; the record shows the worst case is 11.
UNVERIFIABLE 1
The claim has no falsification condition, so the packet refuses to pretend.
What This Is
This is a small review packet for one binary-search thesis. The point is not binary search. The point is the review boundary: the packet keeps claims, measurements, verdicts, and unmeasured claims separate enough for another reviewer to inspect.
The verifier boundary excludes worker context, reasoning trace, intermediate steps, prior chat, and notes. If the packet cannot support a claim, the result stays UNVERIFIABLE.
Included Records
| File | Role |
|---|---|
spec.json | Original claims and falsification conditions. |
run.json | Witnessed run record, verdicts, seals, and integrity checks. |
report.md | Human-readable summary of verdicts and evidence. |
review.md | Cleanroom review boundary and excluded context. |
Verify Locally
From a fresh clone of HarperZ9/crucible:
pip install -e ".[dev]"
python -m crucible review path/to/crucible-cleanroom-demo/bundleExpected result:
cleanroom bundle PASSDownload Hash
SHA-256: 2D4E819E4032F07E3A54D35AF2DC78161C1D2F04C43F89C26B56878D6377D1F1
What To Critique
- Does the packet include enough to re-check the verdict?
- What fields imply more trust than they should?
- Where should signatures, attestations, or provenance anchors fit?
- What should stay outside this packet?
- Is
UNVERIFIABLErepresented clearly enough for reviewers?
Non-Claims
This does not certify code, safety, compliance, or correctness beyond the tiny demo. It is a small example of a review packet that can say MATCH, DRIFT, or UNVERIFIABLE.