Readiness bands
The verification loop grades every handover with a readiness band · Strong, Needs work, or (rarely) Unknown.
The verification loop assigns each candidate handover a readiness band. It's the honest signal of whether a cold model could continue from this handover.
| Band | Meaning | Saved? |
|---|---|---|
| Strong | Completeness target met, no unresolved gaps or contradictions, drift check passed, safety clean. | ✓ Saved as a real handover. |
| Needs work | The handover has gaps, contradictions, or unsafe omissions that still matter · the verification loop couldn't close them. | ✗ Returned as "Needs work · missing: …" with the exact gaps, not saved as confident. |
(There is also an internal Unknown state for the rare case where there is too little signal to score at all; it is never treated as a confident handover.)
What feeds the band
- Confidence · the completeness score against the target sections.
- Missing inputs · what's absent or too thin.
- Contradictions · internal conflicts in the filled handover.
- Unsafe omissions · what safety forced out that the reader still needs to know about.
- Drift check result · could a cold model continue from this alone?
A handover saves as real only at Strong · with no missing inputs (or only safety-justified ones), no unresolved contradictions, the drift check passed, and safety clean. Anything short of that is an honest "Needs work" that says exactly what to fix, never a dressed-up half-handover.
Readiness is descriptive, not a hardcoded claim
The band reflects the real state of the extraction (structural completeness and the absence of contradictions), not a fixed magic number. A complete, contradiction-free handover reads Strong even when the model didn't state a confidence value. The target is domain-aware: a writing or research project isn't penalised for lacking, say, a codebase architecture it was never going to have. The aim is for readiness to track whether a cold model could actually continue, not a rigid checklist.