Inspection is evidence work: designing for traceability
An inspection system's output is not an opinion. It is a record someone will rely on later, sometimes adversarially. Design for that moment.
- Operations
- Architecture
- Data
Most business software is designed for the person using it today. Inspection and document-control systems have a second user who matters just as much: the person who reads the record months or years later, often because something went wrong, sometimes looking for someone to blame.
That second user changes everything. The output of an inspection is not a note. It is evidence.
Where these systems fail
In my experience, inspection and document control rarely fail in the obvious places. They fail in the gaps:
- An observation captured in one place and filed in another, with no link between them.
- A document revised, but the old revision still in circulation because nobody propagated the change.
- A finding recorded without who made it, when, or against which version of the standard.
- A photo that proves something, stored somewhere that nobody can connect to the finding it proves.
Each gap is small. Together they mean that when the record is finally challenged, it cannot answer the one question that matters: how do we know?
Principles for evidence systems
Every fact has an author and a time. Not just the record as a whole — each finding, each change, each attachment. Who recorded it, when, and on what device or through what process.
History is append-only. Corrections are new entries that reference what they correct, not edits that erase the past. The ability to see exactly what the record said on a given date is not a nice-to-have; it is the point.
Versions are explicit. Documents and standards change. A finding is recorded against a specific version, and the system must be able to say which one. "Revision" and "version" usually mean different things to the people who use them, and the data model has to respect that.
Attachments are part of the record. Photos, scans and measurements are linked to the finding they support, with their own provenance. An orphaned photo proves nothing.
The chain of custody is visible. Who had the record, who approved it, who signed it off. Signatures and approvals are events in the history, not flags on the current state.
Automation must respect the same rules
When automated monitoring or AI assistance is added — detecting issues from images, flagging anomalies, drafting findings — it has to live by the same rules as a human inspector. Its output needs an author (the model and its version), a time, and a clear distinction between proposed by the system and confirmed by a person.
Otherwise the automation becomes the weakest link in exactly the chain it was meant to strengthen.
The takeaway
When designing any system whose output might be relied on later, imagine the adversarial reader. Someone suspicious, months from now, asking how you know. Build the record that answers them, and the everyday users benefit too: a system that can prove what happened is a system people trust while it is happening.