Editorial and Research Guide for the AI Incident Database

Editorial standards and research guidance

Version 2 · October 1, 2026 · Daniel Atherton and Sean McGregor · Operational working guide

Governing principle. The database records publicly documented allegations of harm or near harm. It does not independently adjudicate every factual claim. Editorial language should preserve that distinction while stating clearly what sources establish.

Quick access: Definitions · Start Here · How to Cite This Guide

Quick Definitions

The core terms used throughout the guide. Section 2 provides fuller boundary guidance and examples.

Fast boundary rule. A report is evidence; an incident ID is the database’s normalized account of an event. A later source about the same underlying event is usually an additional report, not a new incident.

START HERE | The Two-Pass Editor Workflow

Use these two pages for ordinary submissions. The rest of the guide explains difficult boundaries, exceptions, tagging choices, and maintenance work.

1. Decide What You Have

2. Fill Out “Submit a Full Report”

START HERE | Build the Incident ID

Use Add more info or the editor review interface to supply the AIID-written fields. Keep them short, cautious, and retrievable.

3. Complete the Incident Fields

4. Run the 60-Second Check

• The report title, author, publication date, URL, and text match the source.
• The incident ID is a specific event, AI passes the but-for test, and the harm is more than ordinary friction.
• The title is cautious and distinguishable; the description states the event, AI role, and harm without a list of every detail.
• A later article, lawsuit, correction, or response has not been mistaken for a new event.
• Entities use canonical names; named actors are paired with useful classes; products and models are in Implicated Systems; routine Unknown tags are absent.
• Any uncertainty another editor could not reconstruct is recorded briefly in editor notes.

• Cold-reader check: the title and opening description identify unfamiliar locations, institutions, and people well enough that the incident can be understood without prior knowledge of the source.

About Version 2

Version 2 expands the original public guide into a more complete operational standard for current AIID work. It retains the guide's core distinctions among incidents, issues, variants, reports, and responses while incorporating sustained editorial practice developed through ongoing incident review, source ingestion, entity maintenance, and database research. Major additions include clearer cold-reader standards, campaign and constituent-event boundaries, source-text fidelity, expanded system and synthetic-media vocabulary, harmed-interest entities, legacy-system cleanup rules, and more explicit guidance for optional chronology notes and editorial reasoning.

Rules in this guide are defaults. Editors may depart from them when strict application would make a record less accurate, less legible, or less fair to the evidence. Departures should be narrow and, when they affect the incident ID date, record boundary, attribution, naming of a harmed person, or entity merge, briefly preserved in editor notes.

What Is New or Clarified

• A cold-reader rule for titles and descriptions: local geography, unfamiliar people, institutions, and systems should be contextualized so the incident remains legible outside the source's immediate news context.
• Campaign-level incidents and separately retrievable constituent incidents may coexist when both boundaries are independently useful and supported.
• Timeline and clarification notes are explicitly optional. When useful, they are entered in the Editor's note field to explain a meaningful gap between when an incident occurred and when it was ingested, or to mark later developments an editor wants to preserve.
• Source ingestion is explicitly a preservation task: converting HTML, PDF, or other source material to Markdown or clean text must not silently rewrite substantive story content.
• Controlled vocabulary has been expanded for AI agent systems, enterprise AI systems, AI coding assistants, synthetic-media modalities and creators, user classes, and harmed interests including Privacy, Environmental quality, Epistemic integrity, and Information integrity.
• Legacy records may be edited without compulsory retrospective Implicated Systems research; backfilling should occur when readily supported or through a scoped audit.
• The existing preferences for the earliest reliable non-paywalled baseline source, approximately 500-character descriptions, specific-plus-class tagging, and cautious attribution remain in force.

How to Use the Guide

Use Quick Definitions above for the core vocabulary. For ordinary editing, begin with the two Start Here sections. Consult Sections 1 through 4 for data-model, scope, and record-boundary questions; Sections 5 through 7 for source research, incident construction, and entity work; and the remaining sections when a recurring case type, maintenance problem, automated workflow, or research question requires more detail.

0 Editorial Standard at a Glance

The shortest usable statement of the AIID editorial method.

An AIID incident is a specific event or traceable episode in which an AI system played a meaningful causal role in alleged harm or near harm. The record should be anchored to evidence, written with proportionate caution, and structured so that later users can understand the event without reproducing the source’s rhetoric or the editor’s assumptions.

1 Data Model and Editor Interfaces

How evidence, editorial records, entity vocabulary, and public views fit together.

The AIID is both an evidentiary archive and a normalization system. Reports preserve public sources; incident IDs define editorially bounded events; entity records make actors, harmed groups, and systems retrievable across incidents. Editors should understand these layers before changing a record because an apparently local edit can alter public aggregation elsewhere in the database.

1.1 Core Record Types

1.2 Reports and Incident IDs

A report is evidence; an incident ID is an editorial synthesis. Report titles, publication dates, authors, URLs, and source text should normally reflect the source. The incident ID title, description, date, entities, systems, and notes are AIID-written or AIID-normalized fields. Editors should never allow a source’s headline or rhetoric to determine the incident boundary without independent review.

The numeric incident list is the fastest archive-level check for existing records and report assignments. The Discover interface is better for thematic exploration. Before creating an incident ID, search the incident list, likely entity pages, system names, alternate spellings, case names, locations, and distinctive phrases from the source.

1.3 The Shared Entity Registry

All four role and system fields draw from a shared entity registry. The registry is therefore broader than a conventional directory of named persons and organizations. A model such as ChatGPT, a class such as Chatbots, a court, a harmed group, and a named company can all be entity records, but they should appear in different fields according to their function in the incident.

1.4 Public Views and Editor Tools

1.5 Related Entities, Explicit Relationships, and Co-occurrence

Entity pages display other entities connected through shared incidents. This is analytically useful, but it can produce hundreds of associations for a frequently tagged organization. Editors and researchers must distinguish this automatic co-occurrence network from the much smaller set of explicit entity relationships created in the database.

1.6 Live Data and Point-in-Time Snapshots

The live site can change after an export is created. New incident IDs, reports, entities, and merges may appear while a backup remains fixed. When an audit uses a backup, record the snapshot date and verify any consequential finding against the live incident or entity page before editing.

2 Definitions and Foundations

The concepts that define the database’s scope and the evidentiary posture of its records.

2.1 Core Definitions

2.2 What Counts as an AI System

For AIID purposes, artificial intelligence includes machine capabilities commonly associated with human intelligence, such as prediction, classification, perception, pattern recognition, reasoning, and natural-language generation or understanding. An AI system is the technical or sociotechnical arrangement in which those capabilities play a meaningful role. It may include interfaces, sensors, rules, databases, mechanical components, human operators, and organizational workflows.

The relevant object is therefore not always a model in isolation. A legal-research assistant connected to a drafting workflow, an automated driving stack installed in a vehicle, or a chatbot authorized to alter account credentials may each be treated as an AI system even though the harmful event also depends on non-AI components.

2.3 Implication and Causality

An AI system is implicated when it played an important role in the chain of events that produced the alleged harm. It need not be the sole or dominant cause. A practical but-for question is usually sufficient: without the system’s action, output, omission, or delegated authority, would this specific harm probably have occurred in substantially the same way?

Implication can arise through an erroneous output, a failed detection, a harmful ranking or recommendation, the automation of a consequential decision, or the system’s ability to execute an action. It can also arise in malicious use, where a person intentionally employs AI to impersonate, deceive, surveil, exploit, or generate harmful material.

2.4 Harm and Near Harm

Real-world harm includes physical danger, injury, psychological harm, financial loss, damage to tangible or intangible property, reputational injury, interference with civil liberties, institutional or political harm, and environmental damage. Harm may affect an individual, a bounded group, an organization, a public institution, or a social system.

A near-harm event exists when the system helped create a chain of events that could readily have produced harm but an external factor prevented the outcome. The external factor must be independent of the system and should not simply be a built-in safeguard functioning as designed.

2.5 Misuse, Failure, and Security as Analytical Lenses

The database includes intentional misuse and unintentional failure. Editors may also find it useful to distinguish security incidents in which an AI system is exploited, bypassed, or granted unsafe authority. These categories are analytical aids rather than mutually exclusive record types.

3 The Inclusion Decision

A disciplined method for separating incidents from issues, ordinary failures, and AI-adjacent stories.

3.1 The Five-Question Test

3.2 Incident, Issue, or Outside Scope

3.3 Presumptive Exclusions

• Thought experiments, forecasts, and speculative scenarios without an event.
• General criticism of a product or technology class without identified harm.
• Benchmark failures, model errors, or hallucinations that remain inside testing or private drafting and have no consequential use.
• Proof-of-concept security demonstrations without exploitation-related harm or credible external near harm.
• Routine downtime, degraded performance, or ordinary customer inconvenience without evidence of meaningful downstream effects.
• Stories in which AI is only a funding goal, training-data destination, corporate affiliation, or rhetorical label.
• Aggregate claims that cannot be resolved into identifiable events and do not themselves describe a bounded episode.

These are presumptions rather than absolute prohibitions. A source in one of these categories may still qualify if it documents a concrete event that satisfies the causal and harm tests.

3.4 Severity and the Working Harm Threshold

The AIID does not require catastrophic harm. A corrected filing, an unjustified account suspension, a short-lived reputational injury, or a narrowly avoided collision may qualify. The database should nevertheless distinguish harm from ordinary friction. The fact that a user was annoyed, a product failed to answer, or a service went offline does not by itself establish the sort of event-level harm the incident collection is meant to preserve.

4 Mapping Reports to Records

How to decide whether a new source belongs with an existing incident, a variant, or a new record.

4.1 Decision Sequence

1. Search the incident summaries, relevant entity pages, and likely synonyms before creating a record.
2. If the source mainly adds information about the same underlying event, attach it to the existing incident.
3. If the source concerns a distinct event involving the same system, substantially similar causative factors, and similar harm, consider a variant.
4. If the event is meaningfully different in actors, system, mechanism, setting, or harm, create a new incident and add a related-incident relationship when useful.
5. If no qualifying event can be identified, classify the material as an issue or leave it outside current scope.

4.2 Same Incident

Reports belong to the same incident when they describe the same event, even if later sources add victims, corrected figures, legal consequences, regulatory findings, or a response. A lawsuit, recall, sanction, or apology does not automatically create a new incident when it is a later stage of the original event.

4.3 Variants

A variant is a distinct event, not merely another report. It should normally satisfy all three inherited criteria: the same intelligent system, similar causative factors, and similar harms. If the system is unknown in either event, or if the mechanism differs substantially, a related-incident link is usually safer than a variant classification.

Editors may create a new incident rather than a variant when collapsing repeated events would obscure distinct actors, locations, institutional responses, or historical significance. Use editor notes when departing from the default.

4.4 Related Incidents and Similarity

4.5 Campaigns, Series, and Aggregated Harms

A coordinated campaign may be one incident when the source presents it as a bounded operation involving the same actors, tools, targets, and objective. Separate incidents are usually preferable when distinct victims, dates, countries, or mechanisms are independently documented and useful for retrieval. Aggregate studies belong as issues when they report a pattern but do not identify event-level cases.

Campaign and constituent-event rule. A campaign-level incident and a separately retrievable constituent incident may both be appropriate. Use both when the broader operation is itself a bounded episode, while one constituent event has an independently useful date, victim, location, mechanism, consequence, or response. The same report may support both records. Make the boundaries explicit and link the records as related incidents rather than treating one as a duplicate of the other.

Do not create constituent incidents merely to multiply records for every post, image, transaction, or target in a campaign. The smaller event should be independently documentable and useful for retrieval.

5 Source Research and Report Ingestion

How to build an evidentiary base that is useful, reproducible, and publicly accessible.

5.1 Selecting the Baseline Report

The baseline report is the first source used to establish a new incident record. It need not be the first article chronologically. It should be the best publicly accessible source from which an editor can reliably identify the event, the AI role, the harmed parties, and a defensible incident date.

5.2 Source Evaluation

Evaluate each source for independence, proximity to the event, transparency of sourcing, factual specificity, stability, and accessibility. Primary sources can be authoritative about what an institution said or did while remaining self-protective about responsibility. Journalism can provide independence while relying on partial access or anonymous sources. The strongest record often combines both.

5.3 Report Metadata

Source-text fidelity. Treat report ingestion as evidence preservation. Converting a webpage, saved HTML file, PDF, filing, or other source into clean text or Markdown is a formatting transformation, not an editorial rewrite. Preserve the source's substantive wording, headings, quotations, and meaningful links. Remove paratext such as navigation, advertising, cookie notices, unrelated recommendations, duplicate captions, and interface clutter. Do not silently paraphrase, normalize, summarize, or “improve” the story itself.

When a transformation is unusually aggressive because the source is malformed or difficult to preserve, retain the original file or saved HTML when possible so another editor can verify the conversion.

5.4 URL Hygiene and Public Documents

A question mark begins a URL query string. Many query parameters are used for analytics or traffic attribution rather than access. Strip those tracking parameters before saving a URL. Preserve parameters that identify the document, select a required language, or are necessary to retrieve the content.

When an incident has a particularly important public document, such as a court order, disclosure letter, regulator report, recall notice, or technical postmortem, include the most useful stable URL in the incident record or, when helpful, in an optional clarification note in the Editor's note field. Prefer the document that directly establishes the disputed fact, date, or response.

5.5 Preserving Evidence and Handling Paywalls

Do not rely on a search-result snippet as the report. Open the source, verify the text, and save enough metadata to recover it later. When the strongest report is paywalled, seek a primary document, a licensed republication, or a reliable non-paywalled source. A paywalled report may still be added when it contributes unique information, but the record should not depend exclusively on inaccessible evidence when an alternative exists.

6 Writing and Dating the Incident Record

Standards for the AIID-written fields that determine how an incident is understood and retrieved.

6.1 Selecting the Incident ID Date

The Incident Date field stores the incident ID date: the date assigned to the incident ID as its principal chronological anchor. This may be the date of a discrete harmful event, the first documented harm in an ongoing episode, or a justified fallback date when the underlying event cannot be established. It is distinct from the date an editor learned of the event, the publication date of a later report, and the date the incident ID was created.

6.2 Incident Titles

A title should identify the event in a form that remains legible after the news cycle passes. It should be concise, written in title case and past tense, understandable without specialized knowledge, and distinguishable from neighboring records.

• Include the implicated system, developer, or deployer when the evidence supports it.
• State the harm or failure in concrete terms.
• Use cautious language when facts remain alleged, disputed, or source-dependent.
• Include a location, date, case name, or target only when it materially improves distinguishability.
• Avoid outlet names, rhetorical framing, clickbait, unexplained acronyms, and conclusions that exceed the sources.
• Prefer stable wording that will not require replacement whenever a response or lawsuit develops.

Cold-reader rule. A title should remain understandable to a reader who has not seen the source and does not already know the local geography, organization, case, or person involved. Supply compact context when a proper name alone would force the reader to guess. For local U.S. incidents, prefer the state name when a city or county is material and not globally self-explanatory. For non-U.S. incidents, include the country when the locality or institution would otherwise be ambiguous. Identify an unfamiliar person by role when that role is material to understanding the incident.

Cold-reader context is not license to overload the title. Put secondary context in the opening sentence of the description when it would make the title unwieldy.

6.3 Incident Descriptions

The description should usually be one paragraph of approximately 500 characters, though clarity takes priority over a rigid limit. It should state what happened, how AI was implicated, who or what was harmed, and the most important immediate response when that response helps close the event.

Avoid turning the description into a catalogue of every allegation, target, medium, or source. Combine related details into descriptive phrases. Do not repeat the title verbatim. Do not include analysis, moral judgment, speculative motives, or technical claims that the sources do not establish.

Cold-reader description standard. The description should stand on its own. On first reference, give enough context to identify an unfamiliar person, organization, locality, or institution when its role is not evident from the name. A cold reader should not have to open the report to learn what town is being discussed, what country an institution belongs to, or why a named person matters to the event.

Prefer concrete signifieds over taxonomy language. Use the ontology to make the record retrievable, but write the description for a general reader.

6.4 Optional Timeline and Clarification Notes

Timeline and clarification notes are always optional. When they are useful, place them in the Editor's note field of the incident ID. There is no requirement to add one simply because time has passed, because a record was ingested later than the event, or because a later update exists.

Use an optional note when the chronology would otherwise be confusing or when preserving a later development would materially help a future editor or reader. One common use is to explain a meaningful gap between when the incident occurred and when it was ingested into the AIID. Another is to mark an investigation, correction, adjudication, remediation, disclosure, or other later development when recording it is useful or desired.

Keep these notes brief and date-centered. They should clarify chronology rather than repeat the incident description. Editorial reasoning about classification, naming, attribution, or record boundaries may also belong in the Editor's note field, but should be stated as reasoning rather than disguised as timeline chronology.

OPTIONAL INGESTION-GAP CLARIFICATION

The incident ID date is [date], based on [the evidentiary basis]. The incident ID was created on [date]. [Add one brief sentence about the intervening public record only if it helps explain the gap.]

OPTIONAL LATER-DEVELOPMENT NOTE

[MM/DD/YYYY]: [Actor] [investigated, corrected, disclosed, sanctioned, compensated, suspended, restored, or otherwise responded to] [the incident], [brief material consequence].

6.5 Editor Notes and Uncertainty

Use the Editor's note field sparingly and only when clarification is useful. Appropriate subjects include a non-obvious date selection, disputed AI involvement, incident-versus-variant reasoning, the choice to create both a campaign record and a constituent incident, the decision to name a harmed person, an unusual entity placement, or a controlled departure from the tagging rules.

The same field may also contain the optional timeline and clarification notes described above. Distinguish chronology from editorial reasoning, keep both concise, and do not treat either kind of note as mandatory. The public title and description should remain clear without depending on a private essay in the notes field.

7 Entity and System Tagging

A layered ontology that preserves incident specificity while supporting comparison across the database.

7.1 The Four Core Fields

7.2 Pair Specific Entities with Reusable Classes

Specific and broad tags are complementary. A named company makes the record precise; a reusable class makes it comparable. Add both when the source supports the role and the broader tag is useful for retrieval.

7.3 Named People and Harmed Classes

Tag harmed parties first as an impacted class and secondarily as named individuals when naming materially improves the record. Editorial discretion should favor anonymity when a person is identified only incidentally and their name is unnecessary to understand the harm. Naming is more appropriate when the person is central to the event or deliberately acts as a public-facing plaintiff, complainant, whistleblower, advocate, or warning voice.

7.4 Canonical Names and Aliases

• Use one canonical tag for each real-world entity. Treat abbreviations, punctuation differences, legal suffixes, and translation variants as aliases.
• Use proper names for people and organizations. Use plural noun phrases for classes.
• Do not use forms such as “teacher(s),” “consumer(s),” or “Unknown Actor.”
• Do not merge a company with its product, a parent with a subsidiary, a person with an office, or an individual with a class.
• Before creating a tag, search likely abbreviations, former names, translations, and spelling variants.

User-class naming. Prefer concise noun phrases of the form “x users” rather than “Users of x.” Examples include “AI coding assistant users,” “chatbot users,” and “AI agent system users.” Apply the same construction consistently when creating or canonicalizing comparable user classes.

7.5 Controlled Fallbacks When a Name Is Unknown

An unknown proper name does not require an “Unknown” entity. Use a supported role or class when it conveys real information. Examples include scammers, social media users, generative AI developers, chatbot developers, or automated driving system developers. Leave the field without a specific named entity when even the role is uncertain.

7.6 Products and Models Belong in Implicated Systems

A product, model, or system name generally belongs in Implicated Systems rather than as an entity tag. The developer field identifies who built the system; the system field identifies what technology or workflow was involved. Pair a specific system with a broader system class when both are supported.

Enterprise AI systems. Use this reusable system class when the incident materially depends on an AI system deployed inside an organizational or production workflow and the enterprise context is analytically useful. Do not apply it merely because a company happened to use AI. Pair it with the specific product or model and the more technical system class when known.

AI coding assistants. Use this system class for tools that generate, transform, review, or execute code as part of a software-development workflow. When the harmed or exposed population is the people relying on those systems, prefer the class “AI coding assistant users.”

7.7 Government Bodies and Public Institutions

Government tags should be canonical, jurisdictionally legible, and consistent across countries. Prefer the institution’s established English name when one exists. Add the jurisdiction in a form that reads naturally and helps users retrieve related bodies.

• Use a country or jurisdictional prefix when it is part of the conventional name or provides clear hierarchy, such as “United States Department of Justice,” “California Department of Motor Vehicles,” or “New York City Police Department.”
• Use a parenthetical jurisdiction only when it is needed to disambiguate an otherwise generic translated title and a prefixed form would distort the institution’s name, such as “Ministry of Education (Singapore).”
• Do not alternate casually between country nouns, demonyms, abbreviations, and parentheticals. Choose a canonical form and store the others as aliases.
• Preserve a widely recognized acronym as an alias unless the acronym is itself the institution’s dominant public name.
• Distinguish a ministry, department, regulator, court, officeholder, and government as separate entities.

7.8 Courts, Cases, and Bounded Collective Tags

A case caption is a proper title; “parties in” that case is a descriptive collective tag. Such a tag can be useful when the sources establish that the proceeding’s participants were burdened but do not identify every party separately. The tag should use the formal or accepted short caption and be paired with a reusable class.

Do not treat a defined legal phrase such as “Joint Provisional Liquidators” as an organization merely because a filing capitalizes it. Legal documents frequently capitalize defined roles. Use a role class such as court-appointed liquidators or insolvency practitioners unless the individual officeholders or a formal organization are identified and materially relevant.

7.9 Merge Discipline

7.10 How the Entity Merge Tool Works

The editor-only merge page supports two paths. Editors may select any two entity records manually, identifying a primary record to keep and a secondary record to delete. The page also presents potential duplicate pairs generated from name similarity, with an adjustable matching threshold. Suggested pairs are a review queue, not a judgment that the records are identical.

7.11 Choosing the Canonical Record

Choose the canonical record that will be most legible and durable for future editors and researchers. The decision is about the object’s best public representation, not simply which record was created first or appears in more incidents.

• Prefer the entity’s established current English name when one exists, while retaining a dominant public acronym when the acronym is the name users will actually search.
• Preserve distinctive capitalization, punctuation, diacritics, and jurisdictional identifiers that are part of the recognized name.
• Prefer a name broad enough to cover the same real-world object across incidents but not so broad that it collapses products, offices, subsidiaries, individuals, or role classes.
• Treat legal suffixes, former names, abbreviations, and translation variants as aliases when the sources establish identity.
• Do not choose solely by shorter slug, older creation date, incident count, or the order in which a similarity pair is displayed.

7.12 Post-Merge Verification and Alias Chains

1. Open the surviving entity page and confirm that its name and role-specific incident lists are correct.
2. Open the retired entity URL and confirm that it points users toward the surviving record.
3. Review several affected incidents, especially records in different fields, to ensure the merge did not move a product into a developer role or collapse a class into an individual.
4. Search the entity index for additional spelling, punctuation, translation, singular/plural, or legal-suffix variants.
5. If the canonical entity was itself previously merged, ensure that retired IDs resolve to the final active record rather than an avoidable chain of retired identifiers.
6. Record any consequential merge decision or anomaly in the appropriate maintenance notes or audit log.

7.13 Legacy Cleanup and Retroactive Editing

The current guide governs new work by default, but retroactive cleanup should be organized as a reviewable project rather than performed opportunistically whenever an older label looks inelegant.

Legacy Implicated Systems rule. New incidents should include a specific implicated system and a reusable system class whenever the evidence supports them. Editing an older incident for an unrelated reason does not, by itself, require a new research project to reconstruct its Implicated Systems field. Backfill missing system tags when the evidence is already clear, when the system field is directly relevant to the edit, or as part of a scoped audit with a recoverable change record.

8 Conventions for Recurring Incident Types

Domain-specific guidance for cases that repeatedly produce classification or wording problems.

8.1 Synthetic Media, Deepfakes, and Impersonation

A synthetic-media incident requires real-world use or distribution tied to harm or near harm. The generation of a deceptive image in a laboratory demonstration is usually an issue. A video circulated to defraud investors, damage a person’s reputation, mislead voters, or coerce a victim is an incident.

• Use “synthetic media technology” as the broad umbrella when the modality is mixed or unclear.
• Use “synthetic voice/audio generation” for generated or manipulated audio.
• Use “voice cloning technology” only when the source explicitly establishes cloning or imitation of a particular voice.
• Attribute authenticity findings when contested. Detection-tool output alone may not be sufficient to state that material was AI-generated as fact.
• Exclude clearly labeled satire or parody absent evidence of deception or harm.

Political synthetic content. AI-generated political memes, attack images, troll posts, ordinary campaign creative, or other synthetic political material are not incident-level merely because they are political, misleading, or offensive. Look for a bounded deployment and a documented adverse consequence to a person, institution, political process, or epistemic environment. Diffuse recurring concern without a qualifying event may be better treated as an issue.

Ontology layering. Use the broad synthetic-media umbrella together with modality-specific system classes when both improve retrieval. Add Deepfake technology when impersonation or deceptive depiction of a real person is established; add Voice cloning technology only when a particular voice is cloned or imitated. Creator classes such as Synthetic media creators and Deepfake creators describe deployers, not developers.

8.2 Scams, Fraud, and Coercion

The incident may begin when deceptive AI-generated material is deployed against a target, not only when money changes hands. Actual financial loss is strong harm evidence, while a documented transfer attempt interrupted by an external party may qualify as near harm. Identify the AI mechanism, the impersonated person or institution, the victim class, and the delivery platform when known.

8.3 AI-Generated Legal Errors

A hallucinated citation or quotation becomes an incident when it enters a consequential legal workflow, such as a filing submitted to a court, a decision relied upon by a client, or an official document that burdens parties or the legal process. A private draft caught before use is normally a product error or issue rather than an incident.

Use the filing date as the incident date when the defective filing is the event. Tag the responsible firm or lawyer as deployer only to the extent supported by the public record. Do not infer the AI developer when the tool is undisclosed. Courts, clients, parties to proceedings, judicial integrity, or the legal system may be harmed-party tags when the evidence supports those effects.

8.4 Automated Driving and Driver Assistance

Use “Automated driving systems (ADS)” as the preferred umbrella for systems performing the dynamic driving task. Use “Driver assistance systems” when the human driver remains responsible for supervision or the source identifies an assistance feature rather than automated driving. Avoid treating marketing labels as technical conclusions.

• A collision, traffic obstruction, unsafe maneuver, emergency-response interference, or property-damage event is ordinarily incident-level.
• A recall is usually a response or later development when it addresses known events. A recall notice may also establish previously undocumented incidents.
• Tag road users, pedestrians, passengers, emergency medical services, transit systems, or residential structures when they are directly affected.
• Use “Transit systems” rather than “Public transit systems” when ownership is irrelevant or mixed.

8.5 Algorithmic Decisions in Employment, Education, Finance, and Government

A policy concern becomes an incident when an identifiable person or cohort is subjected to a consequential decision, classification, denial, ranking, investigation, or allocation. The harmed class should match the real scope. “Women job applicants” may be accurate where “women” is too broad and “women applying for engineering roles at one named company” is unnecessarily narrow.

8.6 Chatbots, Large Language Models, and AI Agents

A harmful response is not automatically an incident merely because it is false or offensive. Look for reliance, repeated harmful interaction, disclosure of private information, unauthorized action, material procedural burden, psychological injury, or a credible near-harm chain.

Use AI agent systems when the evidence shows consequential, multi-step execution through tools, permissions, delegated authority, or external systems. Tool access alone is not enough, and marketing labels such as “agent” or “agentic” should not substitute for evidence about what the system actually did. Describe the consequential authority exercised: for example, deleting files, changing an account, sending messages, modifying code, initiating transactions, or acting across connected systems.

8.7 Security Vulnerabilities and Exploits

A vulnerability report without exploitation-related harm is generally an issue. It becomes an incident when attackers use the weakness, when a real target is placed in a credible near-harm chain, or when the system’s unsafe authority produces actual unauthorized access, disclosure, manipulation, or control. Distinguish the AI system’s role from ordinary cybersecurity failures.

An attempted exploit can qualify as near harm even when the attacker does not ultimately succeed, provided a real target entered a documented chain in which harm was credible and an external intervention, failed step, or independent circumstance prevented the outcome. Do not treat every blocked probe or proof of concept as near harm.

8.8 Service Outages and Availability Failures

A service outage is not ordinarily an AI incident. Temporary unavailability, elevated error rates, or widespread failed requests do not establish harm beyond ordinary product inconvenience. Create an incident only when the outage causes a documented consequential effect, such as interruption of emergency care, loss of critical access, material financial loss, or another adverse event that satisfies the general threshold.

8.9 Ongoing and Aggregate Harms

For recurring pricing, ranking, surveillance, or discrimination claims, identify whether the source describes a bounded deployment and traceable transactions or decisions. A class action may reveal an ongoing incident, but the lawsuit filing date should not replace an earlier documented start date. If the source only presents aggregate risk or statistical disparity without identifiable events, treat it as an issue until the underlying incidents can be resolved.

8.10 Information Manipulation and Influence Operations

AI-assisted information manipulation becomes incident-level when a source documents a bounded campaign, deployment, or traceable episode in which AI materially helped create, adapt, translate, target, distribute, or operationally support deceptive content tied to reputational, political, institutional, financial, or epistemic harm. A general claim that generative AI could be used for propaganda is an issue rather than an incident.

Editors should separate the campaign actor, the AI developer, the AI system, the distribution platform, and the harmed audience or institution. The same company may occupy more than one role, but shared corporate ownership does not justify placing every product or subsidiary under the parent name.

Treat multiple content outputs as one incident when the source presents them as one bounded operation with common actors, infrastructure, objectives, and response. Create separate incidents when the campaigns have materially different operators, targets, time periods, or operational chains. Link them as related incidents when a common report or response makes the connection useful without satisfying the variant test.

9 Responses, Updates, and Record Maintenance

How records should evolve after publication without losing their evidentiary history.

9.1 What Counts as an Incident Response

An incident response is a concrete action taken because of the event. It may come from a developer, deployer, regulator, court, legislature, harmed party, insurer, platform, or other institution. A general policy announcement is not a response unless it is tied to the incident or a clearly defined cluster of incidents.

9.2 Updating an Existing Record

• Add a new report when it contributes material facts, a primary document, a formal response, or a substantially different perspective.
• Update the description only when the new information changes the essential event, harm, or AI mechanism. Avoid turning it into a rolling news digest.
• Optionally add a brief timeline or clarification note in the Editor's note field for a major response, adjudication, correction, reversal, or other later development when preserving that chronology is useful.
• Revise tags when a developer, system, victim class, or responsible actor becomes known.
• Preserve caution when a settlement or apology does not establish every allegation.
• Correct errors transparently and avoid silently changing the incident boundary without an editor note.

9.3 Conflicting or Reversed Reporting

When later reporting undermines a core premise, such as a forged forensic report or a disputed deepfake determination, pause ingestion or revise the record to reflect the uncertainty. Do not preserve a confident AI claim simply because it appeared in an earlier source. If AI involvement can no longer be supported, the record may need to be reclassified or removed from the incident collection.

9.4 Record Audit Priorities

Audits should focus on records where inconsistent naming, duplicate entities, unsupported “Unknown” tags, weak incident dates, overconfident titles, or legacy system terminology impair retrieval. Changes should follow a documented house rule rather than one-off aesthetic preference.

10 Automated Tools and Editorial Quality Control

How to use AI-assisted research without allowing automation to replace evidence or judgment.

10.1 Common Editorial Biases

10.2 Required Verification for AI-Assisted Editing

• Do not rely on an AI-generated citation, quotation, date, or URL without opening the source.
• Do not infer that a candidate is absent from the AIID until searching the incident list, relevant entities, likely aliases, and the database backup or current export when available.
• Check that the source actually says the material was AI-generated, rather than merely suspected, digitally altered, or assessed by an unreliable detector.
• Distinguish facts reported by the source from the editor’s inference. Attribute the latter or omit it.
• Verify that every named developer, deployer, harmed party, and system is placed in the correct field.
• Re-read the final title and description against the baseline report before publishing.

10.3 Final Publishing Checklist

Cold-reader pass. Before publishing, read the title and first sentence as though you know nothing about the source. If a town, county, institution, case, or person would be opaque to a reasonable general reader, add the minimum geographic or role context needed to make the record self-contained.

11 Guidance for Researchers

How to interpret the AIID as a selective, evolving public record rather than a complete census of AI harm.

11.1 What the Database Represents

The AIID is a curated archive of publicly documented incidents, issues, reports, and responses. It records what sources allege or establish and how editors organize those claims. It is not a neutral mirror of all AI harms, a comprehensive denominator for risk rates, or an independent adjudication of every event.

11.2 Coverage and Selection Effects

Coverage depends on visibility, language, press freedom, legal access, institutional disclosure, editor capacity, and the searchability of sources. Wealthy countries, prominent companies, spectacular events, and English-language reporting are likely to be overrepresented. Harms affecting marginalized groups, occurring inside private organizations, or unfolding as ordinary administration may be underrepresented.

11.3 Epistemic Status

An incident title is an editorial summary of source-supported claims, not a finding of legal liability or technical causation. Researchers should read the attached reports, attend to cautious language, and distinguish allegations, admissions, official findings, settlements, and editor inference. A lack of records is not evidence that a sector or country has no incidents.

11.4 Temporality and System Versioning

The incident date, discovery date, publication date, and response date may differ by months or years. Products can also change substantially while retaining the same brand name. Analyses should not assume that a system named in 2022 is technically identical to a system carrying the same name in 2026.

11.5 Ethical Use and Attribution

Cite the specific incident page and the underlying reports used in the analysis. Do not identify private harmed individuals merely because a source or entity record contains their names. Avoid presenting incident counts as comparative safety rates without a defensible exposure denominator and a clear account of coverage bias.

11.6 Entity Counts and Graph Interpretation

Entity pages aggregate incidents according to current field assignments. A high count may reflect a company’s broad product portfolio, the reuse of a class tag, historical overtagging, or later retrospective cleanup. It is not automatically a measure of culpability, prevalence, organizational size, or comparative safety.

The Related Entities display largely reflects incident co-occurrence. Two entities may appear together because one developed a system, another deployed it, and a third was harmed. Researchers should describe this as shared incident context unless an explicit relationship or independent source establishes something stronger.

A Quick Decision Checklist

A compact intake and publication workflow.

A.1 Intake

• What exact event or episode occurred?
• What AI system or AI-mediated workflow was involved?
• How did the system help produce the harm?
• Who or what was harmed or nearly harmed?
• What is the best date anchor?
• Is the event already in the AIID?
• Is it better treated as an issue, variant, or related incident?
• What source best establishes the event for a public reader?

A.2 Record Construction

• Ingest the baseline source with clean metadata and complete text.
• Set the incident date and preserve the supporting quotation in research notes.
• Write a stable, cautious title.
• Write a single-paragraph description of approximately 500 characters.
• Add specific and broad tags in each supported field.
• Link the most important public document.
• Add an optional timeline or clarification note in the Editor's note field only when it helps explain an ingestion gap, material later development, or other chronology that would otherwise be unclear.
• Perform the final publishing checklist in Section 10.3.

A.3 Entity Creation and Merge Review

• Search the live entity index for current name, acronym, former name, translation, punctuation, and singular/plural variants.
• Confirm whether the candidate is a person, organization, class, product, model, platform, office, institution, or system category.
• Check the role in every affected incident field before deciding that two records are duplicates.
• Select the canonical name according to public identity and long-term legibility, not simply record age or incident count.
• Treat the merge tool’s similarity score as triage only.
• Verify the surviving page, retired URL, and representative affected incidents after merging.
• Escalate a suspected mistaken merge rather than attempting an improvised reversal.

B Editorial Templates

Reusable starting points that should be adapted rather than copied mechanically.

B.1 Title Templates

B.2 Description Template

B.3 Editor Note Templates

B.4 Optional Timeline / Clarification Note Templates

Use these only when a note would add useful chronology. Both belong in the Editor's note field and neither is required.

C Controlled Vocabulary Preferences

Current house terminology through October 1, 2026. Check the live entity index before creating or merging tags. Vocabulary is a living editorial system: a preferred label should be broad enough to retrieve genuinely comparable incidents without collapsing meaningful distinctions.

VOCABULARY IS NOT STATIC

Terms should be merged or revised when the live database establishes a more authoritative canonical form. Ontological consistency matters more than preserving every historical label. Where two candidate terms overlap, prefer the one that states the incident role and object most precisely without fragmenting retrieval.

D Entity Maintenance and Merge Checklist

A durable procedure for canonicalization work that affects more than one incident.

D.1 Before Creating an Entity

• Search the exact proposed name and likely aliases in the entity index.
• Search the incident list and database export for alternate spellings or descriptive versions.
• Decide whether the record is a named entity, role class, harmed class, product, model, platform, workflow, or institutional system.
• Use a proper name for a person or organization and a plural noun phrase for a reusable class.
• Avoid a routine Unknown placeholder; use an informative supported role or omit the unsupported specific identity.

D.2 Before Merging

• Open both entity pages and compare every incident role in which they appear.
• Confirm that apparent differences do not represent company/product, parent/subsidiary, person/office, agency/officeholder, class/individual, platform/feature, or translation ambiguity.
• Check whether either record is already a retired duplicate or points through another canonical record.
• Choose the canonical record according to public identity, scope, and future retrieval value.
• Preserve the IDs, names, and a representative affected incident before confirming an unusually consequential merge.

D.3 After Merging

• Confirm the surviving entity page loads with the intended canonical name.
• Confirm the retired URL resolves toward the surviving record.
• Spot-check incidents in each affected field.
• Search for remaining aliases and avoid duplicate chains when maintenance tools allow direct mapping.
• Document anomalous or high-impact changes and stop if the merge appears to have erased a real-world distinction.

D.4 Audit Order

How to Cite This Guide

When citing this guide, use the version number and date so that readers can distinguish it from earlier public versions.

Atherton, Daniel, and Sean McGregor. “Editorial and Research Guide for the AI Incident Database.” Version 2. AI Incident Database, October 1, 2026. https://incidentdatabase.ai/editors-guide/

Suggested short form after the first citation: Atherton and McGregor, Editorial and Research Guide, Version 2.

E Credits and Version History

The authorship, public version history, and status of Version 2.

E.1 Authors

Daniel Atherton and Sean McGregor are the authors of Version 2 of the Editorial and Research Guide for the AI Incident Database. This version revises and expands the original public guide to reflect current editorial practice.

AI assistance. Generative AI tools were used during the development of Version 2 to assist with research, document organization, drafting, revision, and consistency review. The authors reviewed the resulting text and retained responsibility for the guide’s editorial judgments, terminology, and final content.

E.2 Version History

E.3 Status

Version 2 is the current working editorial standard dated October 1, 2026. It should be revised when database fields, taxonomy, legal requirements, or sustained editorial practice materially change. Use Version 2 as the default for new work. Broad historical cleanup should remain a separately scoped, reviewable project rather than a side effect of unrelated edits.