Control gap classification

What it classifies

The classification is concerned with what allowed an action to take effect once a system had decided to act. Models make mistakes, and the controls around a model determine whether a mistake causes damage.

Each entry in the record is one incident: something an automated system did, or kept doing, that had an effect outside the system. The record marks each gap the sources support. Why the system acted is recorded separately, with the outcome and the kind of harm, so that the same gap can be counted across different causes.

The approach follows one used in aviation safety. In 2000, Scott Shappell and Douglas Wiegmann described the Human Factors Analysis and Classification System (HFACS) in a report for the FAA’s Office of Aviation Medicine. HFACS sorts the human causes of accidents into four levels, from the unsafe acts of the people involved to the organizational influences behind them, so that many accidents can be compared and prevention directed to the failures that recur. This classification does the same for the controls around an AI action. Each gap describes what the sources show was missing, independent of which control might remedy it. The editor wrote the gaps alongside the architecture page on this site, and reviewers from outside G-14 will examine them before version 1.0.

The 13 gaps

The table lists the gaps by group. The last column counts the incidents in record version 0.3 that had each one.

Matching controls in existing frameworks

For each gap, the table gives the controls most closely aimed at it in the frameworks mapped on the frameworks page. “None” means the editor found no control in that framework aimed squarely at the gap. For G3, statements an organization can be held to, the only partial match is the misinformation risk in the OWASP LLM Top 10 (LLM07:2026), which is why contract clause C-1 lists such statements among the actions to be registered. The mappings are the editor’s own.

Coverage in runtime specifications

The table compares the gaps with two published specifications and one open-source runtime that check an agent’s actions as it runs. The specifications page describes what each one provides for each gap. The comparison is the editor’s own.

• Addressed The document requires or provides a control aimed squarely at the gap.
• Partly The document covers part of the gap, makes the control optional, or leaves a named part of it open.
• Not addressed The editor found nothing in the document aimed at the gap.

Other fields in each entry

Why the system acted

The trigger records what started the incident. It is kept apart from the gaps so that the same gap can be counted across different causes.

Model error

The model or perception system produced a wrong output, or took an action its developer did not intend, from ordinary input.

Manipulated input

A user or third party steered the system with crafted input.

Faulty or malicious change

A change to code, a prompt, a package, or a configuration introduced the behavior.

Conventional fault

A defect in conventional software or hardware, or a faulty sensor.

Working as designed

The system did what it was built to do, and the design was wrong or unlawful.

Outcome

Harm

The action caused harm: death or injury, financial loss, loss or exposure of data, a denial of rights or benefits, or a statement the organization was held to. This follows the OECD definition of an AI incident.

Near miss

An action that would have caused harm was set in motion, and the harm was avoided by chance or late intervention.

Hazard

The action happened and could plausibly have caused harm, but no harm was reported. This follows the OECD definition of an AI hazard.

Kind of system

Agent with tools

An AI system that acts through tools, credentials, or a computer.

Conversational assistant

A chatbot or automated account that talks to customers or the public.

Generative model in a workflow

A model whose output people put into records, filings, or reports.

Perception and control

A system that senses the road and controls a vehicle.

Predictive or matching model

A model whose scores, matches, or valuations drive decisions.

Conventional automation

Rule-based or conventional software, included as a precedent.

Kind of evidence behind each gap

Each gap marked in the record has a label for the strongest kind of evidence that shows it.

Finding

Determined by an investigator, court, tribunal, regulator, or public inquiry.

Admission

Stated by the organization itself, including in a filing, a statement, or an agreement.

Allegation

Claimed in a complaint or lawsuit and not determined. A court’s summary of the claims, and a settlement without admission, leave it an allegation.

First-hand account

Stated by a person directly involved.

Reporting

Established by a news organization’s own reporting or by independent research.

Confidence

Each entry carries one rating, set by the weakest evidence behind any of its gaps.

High

Each gap marked is stated in an official finding, in a statement or filing by the organization itself, whether it published the document or an authority released it, or in an independent technical analysis of the system’s code or records.

Medium

At least one gap rests on an allegation not yet decided, on news reporting, on the organization’s statements as relayed by others, or on accounts by people involved that other sources corroborate, or is inferred from what the sources state.

Low

At least one gap rests on a single account that no other source confirms.

Harm and sector

Harm types: Death or injury; Money; Data and records; Rights and liberty; Public statements. Sectors: Software and IT; Consumer and retail; Transportation; Government services; Healthcare; Finance and real estate; Policing and courts; Media and platforms.

Rules for applying the gaps

1. One incident per entry. An entry covers one action that had effects outside the system, or a run of the same action by the same system.
2. All supported gaps are marked. Most incidents have more than one gap, and each is marked.
3. Only what the sources support. A control the sources do not mention is not assumed to have been missing. Where gaps were considered and left out, the entry lists them with the reason.
4. Causes are recorded separately. Why the system attempted the action is recorded as the trigger. A model’s mistake, a misclassification, or a bad forecast is never a gap by itself.
5. Each gap shows its evidence. For each gap, the entry quotes or summarizes the supporting passage, names the source, and states what kind of evidence it is: a finding, an admission, an allegation, a first-hand account, or reporting.
6. G6 and G7 often go together. G6 records that independent evidence was missing, and G7 records that the person approving could not make up for it. Both are marked when the sources support both.
7. Near misses are included. When harm was avoided by chance or by late intervention, the gaps marked are those that would have let the action through if it had run its course.
8. Older automation is treated the same way. Incidents involving conventional automation are included when the controls that failed are of the same kind. They are marked as precedents and counted separately.
9. Checked from outside before version 1.0. No one outside G-14 has checked the entries in this release. Before version 1.0, at least two reviewers outside G-14 will mark the gaps in each entry from its sources, without seeing the record’s answers or each other’s. Their agreement with each other and with the record will be published, and each disagreement will be settled against the sources.
10. Numbers do not change. Gap numbers and entry numbers are never reused. If a gap is retired, the entries that had it keep it, with a note.

What goes into the record

• An automated system took an action, or people acted on its output, with an effect outside the system: on records, money, messages, vehicles, legal standing, or statements made in an organization’s name.
• It happened during ordinary use of the system, or in a test, evaluation, or training run whose actions reached systems or people outside it. Studies and red-team exercises whose effects stayed inside the test are left out.
• The sources describe how the system’s output led to the effect clearly enough to tell whether each control was present.
• At least one primary source exists: an official record, a court or regulator document, a company statement, or a first-hand account. Where the only primary source is a party to the incident, independent reporting is also required.
• The system is an AI system in the OECD’s sense, one that infers from its inputs how to produce outputs such as predictions, content, recommendations, or decisions. Conventional automation qualifies as a precedent.

Outcomes follow the OECD’s definitions. An AI incident is an event in which an AI system leads to harm, and an AI hazard is one that could plausibly lead to harm. The OECD counts near misses as AI hazards. The record lists them separately as near misses, meaning actions that were already under way and would have caused harm if luck or a last-minute intervention had not stopped them.

Relation to other work

Several other groups collect and classify AI incidents, and this classification is meant to be used alongside their work.

AI Incident Database

Collects reports of AI incidents and sorts them with three classifications: the Center for Security and Emerging Technology’s AI Harm Taxonomy, which describes incidents and their harms for public policy; the Goals, Methods, and Failures taxonomy, which covers the technical and process factors behind an incident; and the MIT AI Risk Repository’s taxonomies. Entries in this record link to the database where an incident number is confirmed.

MIT AI Incident Tracker

Classifies incidents from the AI Incident Database by harm severity, EU AI Act risk level, cause, and risk domain. The tracker uses language models for this and measures how well they agree with human reviewers.

OECD AI Incidents and Hazards Monitor

Tracks AI incidents and hazards reported in the news, using the same OECD definitions as this record.

Loss of Control Observatory

Run by the Centre for Long-Term Resilience, it collects posts on X that report AI systems acting against their users’ intentions, such as ignoring instructions or getting around safeguards. A language model scores each report out of 9 for the credibility of its evidence, and reports scoring 5 or more are counted as incidents.

MITRE ATLAS

Catalogs the tactics and techniques of attacks on AI systems, with case studies.

Research taxonomies

Some classify what goes wrong inside agents, such as AgentRx for failed agent runs and Shah and colleagues for faults in agentic software. Others, such as Popchanovska and colleagues, classify the responses reported after an incident by the organizations involved and by regulators.

Agent incident mappings

Two recent efforts are the closest to this one. The Cloud Security Alliance’s analysis of 10 agent incidents (March 2026), a companion to its Agentic AI Autonomy Levels and Control Framework, lists the controls each incident was missing, such as per-action approval, boundary enforcement, and an independent kill switch. The Agent Incident Registry (Kumar and colleagues, September 2026) catalogs 487 agent-related events and records which guardrails the sources describe. Both cover agents only, and neither publishes rules for checking incidents against a fixed set of gaps.

Safety engineering has a longer tradition of analyzing accidents against the controls or barriers that should have stopped them, and this classification borrows from it.

STAMP and CAST

Nancy Leveson’s systems-theoretic accident model, described in Engineering a Safer World (MIT Press, 2012), treats an accident as a failure to enforce safety constraints on a system’s behavior rather than as a chain of component failures, and CAST applies the model to incident investigation. Its premise that a controller outside the process must enforce the constraint is close to the premise of this classification, which differs in fixing 13 gaps in advance so that many incidents can be marked the same way and compared.

MORT

The Management Oversight and Risk Tree, developed for the US Atomic Energy Commission in the 1970s, analyzes an accident against a fixed tree of barriers and management controls and judges each one “less than adequate” where it failed. It is the closest precedent for checking incidents against a fixed list of controls, although it was designed for industrial operations. MORT is described in the NRI MORT User’s Manual.

Barrier-based analysis

Bow-tie diagrams and barrier-based investigation methods trace an incident to the barriers that were missing or failed, as in Pitblado and colleagues’ method for barrier-based incident investigation (2015). Each gap in this classification names a barrier, fixed in advance, that an AI system’s action got past.

The Swiss cheese model

James Reason’s model of layered defenses treats each defense as a layer with holes, which can line up to let a hazard through. The classification names the holes an AI system’s action passed through.

The editor knows of no other public classification that checks incidents against a fixed set of barriers at the point where the action takes effect, across all kinds of automated systems from agents and chatbots to conventional automation. We will cite any that readers send us, with an explanation of how the two relate.

Practice and proposals

The practice tool presents an incident from the record, asks which gaps the facts support, and compares the answer with the record gap by gap.

The classification will change as the record grows. Proposals for a new gap, a clearer definition, or a different gap for an entry should include the incidents that support them. We answer each proposal in writing and publish the answer with the next version.

Versions

1. 3 October 2026Version 0.2, the first public release. A test, evaluation, or training run now qualifies for the record when its actions reached systems or people outside it. The rule in the 0.1 pilot left out all tests, including evaluations in which agents broke into other companies. No gap or definition changed.
2. PilotVersion 0.1, an internal pilot that was not released: 13 gaps in four groups, applied to 25 incidents. In marking those incidents, the editor separated accounts given after an action from evidence recorded at the time of the action, and G13 came from that distinction.