The Premise
Every incident report has a box near the bottom where somebody names the cause. The named cause is usually the one nearest the incident — participant error, failure to follow protocol, poor judgment. That answer isn't wrong. It's just where the incident analysis stopped instead of where it should start.
The Two Questions
Not the last thing that went wrong, but the conditions behind it, the supervision, procedures, resourcing, and decisions made months before anyone arrived on site.
The adaptations, the controls, the judgment calls nobody writes down because they worked. Most days go right for reasons no one records, and those reasons are what you're relying on to keep your programs safe.
Contributing and Mitigating Factor taxonomies are built into the data model itself. We let you identify the contributing factors on one side and the mitigating factors on the other, so you can trend both across thousands of incidents and near misses.
Why It Matters
The usual system is a form and a folder. A template someone built in 2015, a shared drive, a spreadsheet where the serious ones get logged. It works, which is what makes it hard to argue with. Here's where it stops working.
A graduate student takes a chemical splash to the face in a lab. Treated at student health, back at the bench the next morning. Two people write up an incident report.
The lab supervisor, that evening: student was not wearing eye protection.
The department safety officer, the following week, after talking to three people: goggle cabinet had been empty since the reorder stalled in purchasing, the protocol was revised in August without retraining, and the nearest eyewash was tagged out of service.
Both accounts are accurate. Both were written by someone competent and paying attention. They name different causes, in different words, and once they land in the folder nothing reconciles them.
At a dozen incidents a year this is survivable, because the person who wrote them remembers them. At three hundred, across nine departments, over four years, with two of the writers gone and the template revised twice, the folder holds everything and answers nothing.
Then comes the harder version. Your insurer's renewal questionnaire asks how many lab exposures you had last year and whether the rate moved. An attorney, three years on, asks what you knew and when. Had this happened before? How many times? What changed after the last one?
Those are fair questions with real answers, and getting to them from prose means reading four years of documents and building the count by hand. You never fully trust the number, because the supervisor's write-ups and the safety officer's write-ups were never coded the same way. The total depends on who did the reading.
Nobody in that story was careless. The record came out this way because every incident was written to describe itself, and no one was asked, at the moment of writing, to put the description into a form that could later be added up.
Systems Thinking
A root is a single thing. Find it, fix it, close the incident report, but that's not how incidents really happen. Root cause analysis is a place to start, but it's the analytical ceiling of most incident software. The trouble is the root typically lands on something like 'the person didn't implement the policy', so the solution is retraining. But what is missed is that the department manager didn't allocate enough time in staff training on policies and the budget didn't allow it. That's not the person's fault; those are the results of failures higher up in the system.
Systems Thinking comes out of three decades of safety science research. It treats an incident as the product of an entire operating system; everything from the conditions people worked in, the supervision, the procedures, the resourcing, and the decisions made long before anyone arrived on site as well as the individual piece of equipment that failed.
Modern safety frameworks like the ones below ask a wider question: what were the conditions that made this the likely outcome?
HFACS
The Human Factors Analysis and Classification System (HFACS), developed in aviation, traces an incident up through the layers above the person at the sharp end — the conditions they worked in, the supervision, and the organizational decisions that made it likely.
ICAM
The Incident Cause Analysis Method (ICAM) separates what people did from the conditions they worked in and the safeguards that should have caught the problem — so corrective actions fix the system, not just the individual.
STAMP
STAMP (Systems-Theoretic Accident Model and Processes) developed by Nancy Leveson at MIT treats safety as a control problem: an accident happens when the controls meant to keep a system in a safe state stop doing their job.
AcciMap
The AcciMap developed by Jens Rasmussen is a diagram that plots contributing factors and their interrelationships across every level of the system. Visualizing the hierarchy shows you where interventions can change outcomes.
IncidentAnalytix gives your team the freedom to choose the framework that fits your domain and apply these methods consistently across all incident events. It gives you an analytical framework that doesn't replace investigator judgment. The underlying database schema holds the classification layer. What you see and report, it structures, stores, and analyzes.
Safety-I & Safety-II
Traditional safety management studies failure. You count incidents, trace each one back, and drive the number toward zero. Resilience-engineering researchers call this Safety-I, and it's necessary when things go wrong to analyze the contributing factors that led to the incident.
But Safety-I has a blind spot. On most days, most programs go right. Not because nothing risky happened, but because a staff member adapted, caught a problem early, or made a judgment call that never got written down anywhere. Safety-II studies that: the capacity of an organization to adapt under pressure. Learning from a near miss that stayed a near miss is worth as much as learning from the one that didn't.
IncidentAnalytix combines Safety-I and Safety-II so you learn from your successes, not just from your failures.
Action Intent
Every action is typed by purpose — corrective, reinforcement, or learning — so the record distinguishes fixing what broke from strengthening what held.
Execution Mode
When a control worked, the record captures whether it worked the way it was written or because someone adapted in the moment. That difference is the gap between work-as-imagined and work-as-done, and it's captured as data you can trend.
We haven't found another incident management system that records what prevented harm with the same detail it uses to record what caused it.
In the Data Model
Most systems vendors ship a fixed list of causes and every incident you record for the next decade gets sorted into their list. You are locked into their world view of incident causation.
We see things differently. IncidentAnalytix uses self-referencing hierarchical lookup tables to store the contributing and mitigating factor taxonomies. You decide which framework based on your sector, your regulator, and how far along you are.
Extend without re-tagging history
Factors are stored at the leaf with ancestry inferred, so you can deepen the taxonomy in year three without recoding year one.
Guided, not free-text
Top-level nodes aren't selectable, so reporters land on a specific factor rather than a vague bucket.
One taxonomy across every department
Factors are shared lookups across your whole tenant, so residence life, athletics, and the labs code the same event the same way without coordinating.
Factors related to factors
AcciMaps and Preventimaps record how conditions connect, rather than collapsing an incident to a single line.
A program that triples its participant-days will report more incidents while being materially safer. Every risk manager knows this. Very few incident systems do anything about it.
IncidentAnalytix captures the denominator alongside the incidents — program days and hours, participants, staff, volunteers, by period and activity. So you report rates, and a comparison between two sites, two seasons, or two departments means something.
Who Needs IncidentAnalytix
Select your domain to see the standards you answer to and what IncidentAnalytix delivers for you.
Answers to · DICIPLine Standards & Title IX
Incident reporting is scattered across residence life, athletics, labs, and campus security — so patterns stay invisible.
Consolidate every campus incident
Residence life, athletics, labs, and security report into one structured system.
Confidential case handling
Role-based and column-level security for Title IX-adjacent and sensitive matters.
See patterns across departments
Trend contributing factors to surface systemic risk before it repeats.
The Product
IncidentAnalytix runs inside your own Microsoft tenant, on infrastructure your IT team already governs.
