Preparing for audits after an asset failure
When an asset fails and someone will ask about it later, the value of your record depends almost entirely on one decision: when you reported it.
Requirements
- Available on: Orbit, Odyssey, Cosmos
- Roles: Owner, Admin, Manager, Employee can report incidents
The one rule: report early
Report the incident before the asset is repaired, reassigned, or tidied up.
At the moment an incident is reported, the asset's complete state — condition, assignment, maintenance history, document status — is captured into the incident and locked. It cannot be edited afterwards, by anyone.
Report it two weeks later and the snapshot faithfully records the repaired, reassigned, re-certified version. The evidence you needed is gone, and there is no way to reconstruct it.
Right: failure happens → report the incident → then repair.
Wrong: failure happens → repair it → report the incident once the paperwork starts.
Why the snapshot matters
Most systems let you look up an asset's current state. That is not evidence.
Six months after a forklift injures someone, the questions are about the forklift as it was that day — who was responsible for it, when it was last serviced, whether its inspection certificate was current. By then it has been repaired, reassigned, and re-certified.
The snapshot is why those questions stay answerable. See Immutable incident snapshots.
Building the record
1. Report immediately, with severity and a factual description of what was observed — not what you think caused it.
2. Add threaded notes as the investigation progresses. Notes accumulate over time and are preserved: findings, decisions, who was consulted, what was ruled out.
3. Raise a corrective work order for the physical repair. The incident records what happened; the work order gets it fixed and captures labour, materials, time, and cost.
4. Move the status through Open → Investigating → Resolved → Closed as the investigation develops.
5. Attach supporting documents to the asset — inspection certificates, photographs, vendor reports.
What you can produce afterwards
| Question | Where it is answered |
|---|---|
| "Show me the asset's maintenance history before the failure." | The incident snapshot, plus service records |
| "Was its certification valid at the time?" | The snapshot's document status |
| "Who was responsible for it?" | The snapshot's assignment |
| "Who had it that day?" | Checkout history |
| "When was the incident reported, and by whom?" | The incident record |
| "How do we know this was not changed afterwards?" | It cannot be — snapshots and timelines are append-only |
That last row is the one that carries weight. The record is not trustworthy because you say so; it is trustworthy because the system does not permit it to be rewritten.
For different audiences
Regulators want the timeline and the certification status at the time. The snapshot gives both.
Insurers want evidence the asset was maintained and the failure was not neglect. The service history plus the snapshot's maintenance record answers it.
Internal reviews want the causal chain. The asset timeline plus the incident notes give it in order.
Common mistakes
Reporting late. The only mistake that cannot be corrected afterwards.
Recording conclusions instead of observations. Write what was seen. Conclusions belong in the notes as the investigation develops.
Skipping the incident because a work order was raised. A work order records the repair, not the circumstances. Serious failures need both.
Trying to correct the snapshot. You cannot. Add a note to the incident explaining the correction; the original stays.
Using severity as a priority field. Severity describes the consequence of what happened. How fast you respond belongs on the work order.
Related articles
Need Help?
If you have questions not covered in this article, our support team is here to help.
Contact Support