blueRecall
Given a defective reagent lot, a stale calibration, or a software defect, traces the dependency graph in a lab run manifest and signs a per-claim verdict — REVOKED, RERUN-REQUIRED, DEGRADED, UNAFFECTED, or CANNOT-CERTIFY — plus the smallest rerun set that restores what's affected.
Lab and research-integrity reviewers.
No automatic deletion, retraction, notification, or production-system write, and no claim that an unaffected result is scientifically true.
blueRecall starts from bad news — a reagent lot recalled, a calibration found stale, a software defect — and asks which recorded conclusions depended on it. The four screens follow the bundled twelve-conclusion defective-lot sample from the library, through intake, to the impact map and its rerun plan, and end at the signed receipt. Nothing is deleted, retracted or sent; the software produces linked determinations for a person to act on.
Impact review library — one review waiting, tagged Attention. Below it, the three ways to start: drop a bundle, reuse sources saved in this browser, or load the packaged twelve-conclusion defective-lot sample. The box under the cards repeats on every screen.
New impact review opens intake.
Step 1 of 4. Every file is hashed before it is parsed and never modified. The intake check on the right says what is still missing — here, nothing. The page states it plainly: nothing is executed until you confirm at step 4.
Map fields, Configure and Confirm follow; the impact map is what comes out.
Conclusion impact map — twelve conclusions, each given one of five dispositions, each defined on its card: Revoked (depends directly on the invalidated property and can no longer stand), Rerun required (can be restored), Degraded (may still be used), Unaffected, and one Cannot certify, where the dependency binding is incomplete so neither impact nor safety can be shown — the screen says to review that one first. The rerun plan names one experiment that restores three conclusions.
Export writes the signed review; Signed receipt opens it. Whether anything is actually retracted or rerun is a decision someone makes with this in hand.
Signed receipt — the same twelve-conclusion review, closed out. The signed fields are read from the receipt itself, not the database, and Verify now recomputes the output hash and checks it against what's stored rather than trusting either. Pinning an expected signer is the one check that distinguishes a genuine receipt from one forged with a fresh keypair.
Under active build. See the status page for measured, current-state completion.