halt-as-deliverablelisted

# HALT as Deliverable ## Problem A quality discipline (pre-registration, pre-flight check, sanity gate) refuses to produce the intended result because it detected an inconsistency in the surrounding state. The engineer reflex is to fix the inconsistency and re-run, treating the HALT as a setback — which discards the most valuable artifact the work produced. A discipline-gate catching its own author's accidental falsification, before any contaminated result ships, is an uncopyable credibility signal: it proves the discipline works on real, unrehearsed material. Where the framework's credibility matters more than the specific result, the HALT is the higher-value deliverable. ## Use when - A pre-registered prediction is falsified by a known class of error before the experiment executes: registry drift, version mismatch, schema change, baseline/tag documentation inconsistency. - A pre-flight verification refuses the run because operational state is inconsistent with the experiment's preconditions. - A self-audit, linter or regression check catches a defect in the author's own shipped work — the defect the audit existed to demonstrate the absence of. - Any "the discipline refused to produce X, and here is why" outcome where the why is structurally informative rather than transient infrastructure noise. Deciding between the two paths: | Apply HALT-as-deliverable | Apply fix-and-re-run | |---|---| | The HALT reveals a structural inconsistency the audience would car