The method
The decision loop
What was actually supplied, and where it came from.
What repeats across a named population, with the evidence kept close.
What a responsible person accepts, rejects, or chooses to test.
What later evidence says after the organization acts.
The vocabulary
A condition is anything that was true around the person at the time. Every condition chatIR extracts is assigned to exactly one of five dimensions, each with its own set of subcategories, adapted from the structured frameworks used in aviation and other high-reliability industries.
Assigning each condition to one dimension is what makes coverage measurable. It is how a report can say which dimensions your reporting reaches at all and which it never touches — and it is why a form that asks only what happened tends to reach very few of them, however carefully it is filled in.
One condition, one dimension. A crew on their eleventh hour using a stretcher that would not lock is not one finding — it is fatigue in Scene and a mechanical failure in Equipment & Load, and each may repeat with a completely different set of incidents.
Listed here in canonical order — System first, Scene last — which is deliberate. Starting at the organizational end keeps an investigation from beginning and ending with the person closest to the incident.
Organizational decisions — staffing, scheduling, culture, resource allocation, leadership
Conditions no individual chose. A finding here is an organizational question, not a crew conversation.
Training gaps, protocol design flaws, enforcement failures, ambiguous or unenforceable rules
Includes the case where a rule is operationally impossible to follow — which is a policy problem, not a compliance one.
Equipment condition, vehicle state, patient weight, tool readiness and maintenance state
Load belongs here: patient weight is a load condition, not crew performance.
Individual and crew actions, decisions, and behaviors at the moment of the incident
The narrowest dimension on purpose. It covers what was done — not who the person is, and not the conditions that made the action reasonable at the time.
Environmental conditions, fatigue, patient state, location hazards that made the incident more likely
Fatigue and time pressure live here, not in Crew. Being on your eleventh hour is a condition you were placed in, not a decision you made.
Eight working rules
The original account stays distinct from the structure built around it. Vocabulary can improve. The source should not be rewritten to make a later analysis look cleaner.
When AI extracts a condition from narrative text, that condition must stay grounded in language from the record. An extraction the model cannot tie to a verbatim span in the source is flagged, and flagged extractions are excluded from pattern scoring.
A report, an account, and an event are not always the same thing. The unit of analysis is named so activity does not quietly become evidence.
Conditions that appear together deserve examination. Co-occurrence alone does not establish that one condition caused another.
Counts are reported with the population they came from. A number without its denominator can make a thin pattern look far stronger than it is.
A rare, severe condition can matter while the evidence stays thin. Importance affects attention. Confidence affects how strongly the finding can be stated.
Missing fields, conflicting accounts, sparse narratives and inconsistent categories say something about the reporting instrument. They are not details to bury.
chatIR can surface candidate controls and the questions needed to evaluate them. Operational leaders decide what fits, what gets tested, and what happens next.
How chatIR uses AI
Incident narratives do not arrive in a clean, shared vocabulary. AI is good at recognizing language, asking focused follow-up questions, and proposing structure. It should not get to turn a plausible sentence into an untraceable fact.
The model proposes. The system checks. A person decides.
AI-extracted conditions must point back to supporting language in the record used for that extraction.
Code enforces the allowed shape, checks the grounding, and prevents unsupported material from quietly entering pattern analysis.
chatIR can organize evidence and expose a question. It does not know your organization well enough to own the answer.
Evidence limits
A retrospective incident record is a partial account of work that already happened. Its limits belong in the finding, not in fine print after it.
A relationship in the record is a reason to look closer, not permission to declare a cause.
A condition missing from the record may be absent from the work — or it may never have been asked about.
Low incident counts can reflect good performance, low exposure, incomplete reporting, or chance. The record alone cannot settle that question.
A control still has to be selected, made available, used in real work, and observed over time.
Follow-through
The diagnostic opens this loop with the history you already have. The platform keeps it alive as new reports, investigations, controls and evidence arrive.
Check the finding against the source and the operating context.
Accept it, reject it, or choose a control worth testing.
Define what should be visible if that control is available and used.
Bring later evidence back to the same question and compare honestly.
Next
The sample report shows the condition map, the scored patterns, the populations behind them, and where the evidence ran thin.
Or
The diagnostic applies this method to one approved, deidentified historical export. Fixed scope, no platform commitment.