Defect states

The defect states keep a claimed fix apart from a correction that a targeted recheck supports.

1. OpenA finding raised by a reviewer, or by a person returning work.
2. FixedIts owner names the fixer and the fix.
3. RecheckedAgainst the original criterion, with evidence and limits.

The recheck either

• VerifiedPassed, and recorded.
• Unresolved or recurredFailed. The ledger check fails until a later recheck passes.

Closed sits beside this path: a later review did not raise the finding again, which is not a recheck.

State	Meaning
open	The finding is in the ledger and no fix is claimed yet. A finding answered without a fix stays open.
fixed	A fix is claimed: its owner marked it fixed, naming the fixer and the fix. Nobody has rechecked it yet.
closed	A later review did not raise the finding again. An observation, not a check, and no evidence that the correction worked. A row someone closes by hand is recorded as a repair claim instead, and waits for a recheck.
verified	A targeted recheck against the original criterion passed and was recorded, with its method, evidence, checker and limits. When the row lists several outputs the finding reaches, each needs its own passing recheck.
recurred	A recheck of a verified fix failed. The ledger check fails until a later recheck passes.
unresolved	A recheck of an open, fixed or closed finding failed. The ledger check fails until a later recheck passes.

Closed is not verified. The absence of a complaint is not evidence of a correction, so no row is ever promoted from closed to verified without a recheck. A recheck by the person who made the fix is marked as a self-check, a model’s recheck is advisory, and a verification is never acceptance. When a faulty default, a standing instruction, contributed to the failure, the finding verifies only with a recheck of a later run under the revised instruction, naming a trace record that exists and the commit that changed the instruction.