An incident is a record, not a text box.
A free-text ticket tells you something broke. A structured record tells you what kind of failure it was, where it was caught, and what you did about it — before anyone starts arguing about cause.
Typed by how it failed, from the first field
Every incident is one of three kinds — equipment, quality or safety — chosen before anything else you enter. That first choice shapes the entire record instead of leaving it a shapeless note.
The right fields for the failure in front of you
An equipment failure asks for its failure mode; a quality escape for its detection point and affected units; a safety event for its category and location. You are never handed a blank box and left to guess what matters.
Containment status is derived, not opinioned
Whether a defect was contained in-house or escaped to the customer is read from where it was caught — not typed in by whoever happens to be filing. The record cannot quietly flatter itself.
Actions logged before a cause exists
The immediate steps you took to contain the failure are captured at intake, in their own place — recorded while they are fresh, long before any investigation settles on a root cause.
The method is recommended. The engineer chooses.
Open an incident and the platform suggests how to investigate it — and says, in one line, why. It is a recommendation that speeds the decision, not a decision taken out of your hands.
A recommendation with its reason attached
Every suggestion comes with the plain-English reason behind it, so an engineer can agree or overrule it on the merits. It is guidance you can argue with, never a black-box verdict handed down.
No model call to produce it
The recommendation is computed straight from what you already entered. It costs nothing, returns instantly, and gives the same answer every time — there is no AI in the loop to second-guess or hallucinate.
The engineer still makes the call
The platform hands over a recommendation and the full list of methodologies alongside it. Choosing which one to run stays an explicit, human decision — the recommendation never quietly selects itself.
Reported twice is not failed twice.
A recurrence number that counts every duplicate as a fresh failure is worse than no number at all. The platform tells a genuine repeat apart from the same event entered twice — and never inflates the count on its own.
A double-entry is flagged, never merged
Two people filing the same event at the same instant surfaces as an advisory at intake — a heads-up, not an automatic merge. Nothing is folded together behind your back on a guess.
A genuine repeat is linked and counted
When the same failure comes back for real, the new incident is linked to the one it recurs — so your recurrence count is measured from linked evidence, not inferred from a title that looks familiar.
Merging takes a named human, and never deletes
Collapsing two records requires an approver named on the record. The duplicate is quarantined, not erased: it stays queryable, keeps its analyses, and points at the record it was merged into.
Nothing you log can be quietly destroyed.
Organizational memory is only worth building if it cannot be quietly erased. Some records simply refuse to be deleted — and even a removal leaves the analysis behind it intact.
Closed incidents cannot be deleted
Once an incident is closed it is part of the audit trail, and the delete is refused outright. A finished record is not something anyone gets to make disappear.
A completed analysis is protected
An incident whose investigation is finished cannot be deleted either. The analysis is organizational memory — it is never erased, and never orphaned from the failure it explains.
Removal is soft, never destructive
When an incident is removed it is marked, not erased. Its investigations, findings and corrective actions survive intact rather than cascading into oblivion with it.
Every create, update and delete is on the record
Each of those events writes an audit row of its own. Who did what to which incident, and when, is always a question the system can answer.
Import ten years of history — without inventing ten years of recurrence.
Bringing your back-catalogue in should not manufacture a decade of false repeats every time the sync runs. Re-importing the same record recognises it and moves on, rather than counting it again.
Re-sync recognises and skips
An incident that was already imported is recognised on the next sync and left exactly as it is. Pulling your whole back-catalogue again does not quietly duplicate a single record.
A skip never re-counts recurrence
Recurrence is worked out once, when a record first arrives — never re-run on a skip. That is precisely what stops a nightly full-pull from manufacturing a decade of repeats you never actually had.
Upstream corrections update in place
If the source record genuinely changed, the existing incident is updated where it stands. A correction edits history honestly instead of stacking a second copy on top of it.
A signal becomes an incident only when a person says so.
When statistical monitoring spots something worth investigating, it proposes — it does not file. The proposal waits for a human to confirm before an incident exists at all.
The output is a proposal, not an incident
A qualifying signal produces a proposal you can read and weigh — nothing more. Confirming it is what creates the incident, through the same intake path as any other. The engine never files on your behalf.
Honest states suppress the trigger
If the underlying evidence is incomplete or degraded, the signal is suppressed entirely. An engine that is unsure of its own numbers is barred from manufacturing urgency out of them.
Suppression is disclosed, never silent
When a real finding is held back, the run says so on the record. You never get a quiet nothing that was actually a something the platform chose not to mention.
Signals proposing an investigation are an opt-in, flag-gated rollout — off by default, enabled per workspace by an admin, and a person always decides whether a signal becomes an incident.
The numbers a plant manager reports upward.
Every incident you capture rolls up into the reliability picture your site reports each month — a failure Pareto, mean time between failures per asset, and how much of your load is the same failures coming back.
- Press CP-12
- 412 h
- Capper FF-3
- 867 h
- Filler L7
- 1,204 h
Illustrative data · your figures are computed from your own incidents
Failure Pareto
The short list of failure modes — or the pieces of equipment — driving most of your incidents, ordered so the vital few sort themselves to the front. The month starts here.
MTBF per equipment
Mean time between failures for each asset across your window, so the machines quietly eating your uptime rank themselves instead of hiding in an average.
Recurrence rollup
How much of your failure load is the same problems coming back — the single figure that tells you, and your leadership, whether the fixes are actually holding.