ITquette Framework Series · Framework #3

The Incident-to-Improvement
Framework™

Demonstrating safety improvement in complex autonomous systems.
June 2026 · ITquette Autonomous Lab · Framework · Risk reduction evidence

Organisations respond quickly when incidents occur. Investigations are launched, fixes are implemented, validation is completed, and the incident is closed. But one question often goes unanswered: did safety actually improve — or was a problem simply addressed?

Many organisations are effective at identifying problems. Many are effective at implementing solutions. Far fewer can confidently demonstrate that the implemented solution reduced operational risk over time.

A fix can be deployed. A test can be passed. Yet the underlying risk may remain unchanged.

For organisations operating safety-critical systems at scale, that distinction is not a technicality. It is the difference between believing safety improved and being able to prove it. This is the basis of the Incident-to-Improvement Framework™.

Six stages from incident to evidence

The framework traces a single thread from the moment something goes wrong to the point where an organisation can responsibly say the risk has been reduced — not just addressed.

The Incident-to-Improvement Framework™ — Pipeline
STAGE 01 Incident STAGE 02 Investigation STAGE 03 Corrective Action STAGE 04 Validation STAGE 05 Safety Evidence STAGE 06 Risk Reduction Awareness begins The trap lives here The goal
01
Awareness begins
Incident
A collision, near miss, disengagement, intervention, or unexpected vehicle behaviour. The organisation becomes aware of a potential problem — but awareness alone does not create understanding.
Something happened. What was it?
02
Understanding why
Investigation
The purpose isn't only to determine what happened, but why. What conditions existed, what scenario was encountered, what contributing factors were present. Without this, organisations collect incidents rather than knowledge.
Why did it happen?
03
Intended fix
Corrective Action
Software changes, model retraining, policy updates, ODD adjustments, additional safeguards. The organisation has created an intended improvement — the key word being intended. Nothing is proven yet.
What are we changing?
04
Where confidence is mistaken for evidence
Validation
Simulation, replay testing, closed-course testing, controlled deployment. A successful validation shows the fix behaves as intended. It does not yet show that operational risk has actually decreased.
Did the fix perform as expected?
05
Where it becomes measurable
Safety Evidence
Has recurrence decreased? Has exposure decreased? Are trend indicators moving in the right direction? This stage shifts the claim from "the fix works" to "the risk appears lower."
Is the risk actually changing?
06
The goal
Risk Reduction
Not "the problem is solved" — but "the likelihood of this risk causing harm has been reduced." Safety-critical systems rarely eliminate risk entirely. The goal is managing it through continuous, demonstrated improvement.
Has risk measurably gone down?

The validation trap

Many improvement efforts stop at Stage 4. The logic feels complete:

The trap
Problem found → Fix applied → Test passed

This creates confidence. But confidence is not evidence. A test may show that a specific issue was addressed — it does not show that operational risk has been reduced across the broader system.

Closing the incident here is the most common place safety improvement claims quietly become unverifiable.

Why traceability matters

The ability to connect an incident to its investigation, its corrective action, its validation activity, and its resulting safety evidence is what organisations call traceability.

Commonly assumed
Traceability is documentation — a record of what was done.
What it actually is
Traceability is the ability to explain how an improvement claim is supported by evidence.

Without it, learning becomes fragmented, improvements become difficult to verify, and regulatory confidence becomes harder to establish. Most importantly, organisations struggle to demonstrate — to anyone — that safety is actually improving.

Connecting back to the series

The thread across all three frameworks

Framework #2 explored how operational events become learning through scenario intelligence. That learning is the foundation — but learning alone doesn't prove anything changed.

Framework #1 introduced the Safety Evidence Gap — the observation that operators, regulators, insurers, and the public all evaluate safety through different evidence. But all four eventually ask the same underlying question: how do you know safety improved?

The Incident-to-Improvement Framework™ is the attempt to answer that question — not through assumptions, and not through intentions, but through evidence that holds up across all four stakeholder groups.

Questions worth holding

  1. If two organisations identify the same risk and implement the same corrective action, but only one can demonstrate reduced risk over time, have they achieved the same level of safety improvement?

  2. How many corrective actions inside your organisation are currently closed at validation — confident, but unproven?

  3. As autonomous systems scale, will the organisations that can most effectively connect incidents to measurable improvement become the ones most trusted by regulators, insurers, and the public?

The answer to that last question may ultimately separate organisations that talk about safety improvement from organisations that can prove it.

Incident management Risk reduction Traceability Safety evidence Corrective action Validation Framework series
← Previous · Framework #2
The Scenario Intelligence Framework™
Next · Framework #4 →
The Credible Safety Evidence Framework™

Follow the research on LinkedIn.

New frameworks published regularly. If something connects with a challenge you are working through, reach out.

Get in touch →