THE CORE AIM OF VOCABULARY MASTERY · AI INCIDENT REPORTING · OBSERVE → RECORD → CLASSIFY → DISCLOSE → IMPROVE
AI incident reporting vocabulary is the language used to describe how organisations document and communicate events involving unexpected, harmful or potentially harmful artificial intelligence behaviour. Terms such as incident, near miss, severity, affected parties, incident timeline, initial report, root cause, notification, corrective action and lessons learned matter because a good report helps others understand what happened without confusing confirmed facts with speculation.
The core aim of vocabulary mastery for AI incident reporting is trustworthy communication. Learners should be able to prepare a clear, appropriately scoped record that identifies the event, its consequences, the relevant AI system, what evidence supports the account, what remains uncertain, who must respond and how the incident will be followed through. Reporting is not the same as repairing the system, but effective repair and accountability depend on accurate reporting.
This guide belongs to the eduKateSG Vocabulary Hub. For the operational response itself, use AI Incident Response Vocabulary. For evidentiary records, use AI Audit Trail Vocabulary. For evaluating consequence and urgency, use AI Risk Assessment Vocabulary.
Central proposition: The strongest AI incident report makes an event legible to people who were not there, while being precise about what is known, what is uncertain and what happens next.
The 60-second incident reporting vocabulary router
- Event: incident, hazard, near miss, observation.
- Impact: affected parties, scope, duration, severity.
- Evidence: timestamp, model version, source record, trace.
- Interpretation: hypothesis, contributing factor, root cause, confidence.
- Communication: notification, disclosure, confidentiality, reporting threshold.
- Improvement: containment, corrective action, owner, closure verification.
The incident reporting vocabulary architecture
| Term | Practical meaning | What must be made clear? |
|---|---|---|
| Incident | An occurrence that meets defined criteria for formal response or reporting. | What actually happened? |
| Near miss | An occurrence that could have resulted in harm but did not in the observed case. | What prevented consequences? |
| Initial report | Early account based on information currently known. | Which facts are confirmed, and which provisional? |
| Affected parties | People, organisations or systems experiencing or potentially exposed to consequences. | Who or what was involved? |
| Severity | Assessment of consequence under a defined scheme. | How serious is the event? |
| Timeline | Time-ordered sequence of material observations and actions. | What happened in which order? |
| Root cause | A contributing causal mechanism identified through investigation. | What explains the failure, if established? |
| Notification | Communication to a person, authority or group about an event. | Who must be told, why and when? |
| Corrective action | A measure taken to address an identified weakness. | What changes as a result? |
| Closure | Formal determination that specified response and follow-up obligations are satisfied. | What evidence supports completion? |
An AI incident is not always a conventional software outage
Traditional software incident reporting often focuses on downtime, data loss, broken transactions or unauthorised access. AI introduces additional cases: a model may generate a convincing but unsupported claim, a classifier may behave poorly for a particular population, or an agent may propose actions inconsistent with user authority. The application can remain technically available while causing real problems. Reporting language should identify the relevant failure mode rather than compress all incidents into ‘AI bug.’
A worked example: an incorrect school admissions explanation
Imagine an educational information assistant answers a parent’s question about entry requirements. The response states an outdated eligibility rule and attributes it to a source that does not support the statement. A member of staff discovers the issue after the parent asks for clarification. The team checks logs and finds the same erroneous wording may have appeared in other sessions.
A clear incident report distinguishes the confirmed incorrect statement from hypotheses about the cause. It records the model or service version, the authoritative rule available at the time, the observed retrieval and response evidence where legitimately retained, the timeline of detection and the action taken to prevent additional incorrect advice. It also records what the team has not yet determined—for example, how many readers relied on the response.
Initial report versus final postmortem
The initial report
An initial report prioritises timely, usable information: the event type, current scope, urgency, containment action and uncertainty. It may be amended as facts emerge. An initial report should not present an untested theory as an established cause.
The final report
A final or post-incident report aims for a stable timeline, evidence-based causal analysis, assessed impact, actions completed, remaining limitations and further work. The report can be concise but should make the chain between observed failure and corrective response visible.
| Initial report | Final report |
|---|---|
| What has happened so far? | What happened over the full event period? |
| Which people or systems may be affected? | What impact can be established? |
| What containment is underway? | Which mitigations succeeded or failed? |
| What remains unknown? | What is known, unresolved or unknowable? |
| Who owns the immediate response? | Who owns long-term corrective actions? |
Near miss, incident and hazard: why precise naming matters
A hazard is a potential source of harm. A near miss is an event in which harm was narrowly avoided or did not materialise under observed conditions. An incident is an occurrence that meets the organisation’s defined reporting or response threshold. These distinctions matter because a useful reporting process should learn from near misses before severe outcomes occur, without declaring that every risky possibility was a realised incident.
Scope, impact and severity are not interchangeable
Scope describes which systems, users or workflows are affected. Impact concerns the actual or plausible consequences. Severity is an assessment made under a specified scale. A system may affect many low-stakes interactions or one highly consequential decision. The same number of affected sessions does not always imply the same severity.
The essential incident report fields
| Field | Recommended content | Why it matters |
|---|---|---|
| Report ID | A stable identifier. | Links updates and follow-ups. |
| Time information | Occurrence, detection and report timestamps, with timezone or reference. | Supports a reliable timeline. |
| System identity | Service, model version and affected workflow. | Identifies what requires investigation. |
| Event description | Neutral account of the observed behaviour. | Separates fact from conclusion. |
| Affected scope | Known users, processes or outputs affected, using privacy-minimising categories. | Clarifies consequence. |
| Evidence | Relevant logs, source references or test records. | Supports reproducible review. |
| Containment | Actions completed or in progress. | Shows how exposure is being reduced. |
| Uncertainty | Unknown facts or unverified hypotheses. | Avoids false certainty. |
| Owner and status | Responsible responder, next checkpoint and current state. | Enables follow-through. |
Preserve evidence without spreading sensitive information
A report may need enough technical detail to explain what failed, but it should not automatically reproduce confidential prompts, passwords, pupil records or identifying conversations. A safer approach is to keep a minimised incident summary for broader coordination and a controlled evidence location for properly authorised investigators. Evidence preservation and privacy should be designed together.
Causation requires investigation
Suppose the first report says, ‘The AI hallucinated because its source was outdated.’ That may be one hypothesis, but it could be wrong. Perhaps the source was current and the model misinterpreted it, or perhaps a stale index selected an obsolete document. Precise reporting uses terms such as observed condition, hypothesis, verified finding and contributing factor to reflect the actual evidence.
Why reporting quality supports cross-organisation learning
In February 2025, the OECD published Towards a Common Reporting Framework for AI Incidents. It presents a framework intended to support comparable reporting across contexts while allowing adaptation to domestic policy and law. It outlines 29 criteria to help understand incidents and their impacts. This is a proposed common reporting approach, not a claim that all organisations everywhere face the same legal notification duties.
That distinction matters. A useful global vocabulary can improve communication, while mandatory reporting rules, deadlines and competent authorities depend on the jurisdiction, sector and actual event. Organisations should verify relevant obligations instead of assuming one universal clock or form applies.
Human impact belongs beside technical diagnosis
An incident report should not focus so narrowly on servers, prompts and logs that it forgets the people affected. Where appropriate, record whether users received incorrect advice, lost access to important services, encountered discriminatory effects or had their information exposed. Describe both known and potential consequences, distinguishing them carefully.
Notification, disclosure and publication
Internal notification brings responsible teams into the response. External notification may inform affected users, partners or authorities where appropriate or required. Public disclosure may serve accountability but must be balanced with privacy, security, verified facts and applicable requirements. These are different communication acts; reporting vocabulary should not collapse them into one.
A useful educational practice exercise
- Invent a harmless AI incident involving a fictional document assistant.
- Write an objective two-sentence event description.
- List facts confirmed by the hypothetical evidence and hypotheses still under investigation.
- Create a timeline with the occurrence, detection and containment time.
- Identify the users or workflows potentially affected without using real personal details.
- Describe what should be communicated to responsible reviewers.
- Add a corrective action, owner and means of verifying the correction.
Common AI incident reporting mistakes
- Calling a hypothesis a fact: label uncertainty clearly.
- Recording only a severity label: describe the actual consequences and context.
- Using a technical log as the whole report: add audience, effect, decisions and status.
- Exposing sensitive evidence too broadly: apply access control and minimisation.
- Assuming all reporting laws are identical: verify the relevant jurisdictional requirements.
- Closing the record at restoration: track corrective actions and lessons learned.
Frequently asked questions
What is AI incident reporting?
It is the structured recording and communication of events involving AI-related failures or harms, including impact, evidence, response and follow-up.
What is the difference between an incident report and a postmortem?
An incident report may start during an event and evolve; a postmortem documents the completed investigation and lessons.
What is a near miss?
It is an event that could have caused harm under plausible conditions but did not produce that harm in the observed case.
Does every AI error require regulatory reporting?
No universal rule makes every AI error reportable. Obligations depend on the event, applicable law, sector and jurisdiction.
Why is a timestamp important?
It supports event ordering, comparison with deployed versions and reliable reconstruction of decisions and responses.
Continue through the eduKateSG ecosystem
- Vocabulary Hub
- AI Incident Response Vocabulary
- AI Audit Trail Vocabulary
- AI Risk Assessment Vocabulary
- AI Accountability Vocabulary
The AI incident reporting vocabulary standard
A learner reaches mastery when they can write a report that clearly identifies the event, separates evidence from interpretation, describes human impact, protects sensitive information and assigns an accountable route toward correction. A good incident report gives others the chance to learn from what happened, rather than having to discover the same failure again.