Editorial dates are assigned for this collection; they do not represent original publication or author approval dates. The update date records this site revision.
Separate types of gaps
Distinguish a failed device from an inaccessible area, unfinished third-party interface or unapproved change. Each needs a different next action.
Give the item a stable reference
Log device ID, expected behavior, observed result, date, responsible party and proposed correction. A photograph can help when the owner permits it.
Close with evidence
Retest the original scenario, record witness and result, and update the owner’s final package. Avoid calling an untested condition a passed test.
Working example: The scenario below is illustrative. It describes a practical design and review method, not a completed customer project or a guaranteed result.
A working scenario
A device appears on a punch list as “to check later” with no location or owner. Such an item can vanish after handoff.
The decision to make before buying
Assign a stable ID, expected behavior, observed result, severity, blocker, responsible party, due date and retest rule to each exception.
A useful acceptance test
At each review, demand an observable retest or documented acceptance of residual risk by the appropriate owner; close only with evidence.
What the owner should receive
Deliver the final register with open and closed status, attachments, decisions and warranty or service routing.
Questions owners ask
When is an exception actually closed?
When the responsible owner can see the agreed behavior pass a documented retest, or an authorized decision explicitly accepts the remaining limitation. “Vendor said fixed” does not show what was tested. Attach evidence to the same item identifier.
How should severity be assigned?
Base it on operating consequence and required approvals, not only repair effort. A misleading door status may matter more than a cosmetic label; a safety-related item needs qualified review under the applicable process.