> ## Documentation Index > Fetch the complete documentation index at: https://docs.swarmd.ai/llms.txt > Use this file to discover all available pages before exploring further. # Incidents, the register and evidence > Recording serious incidents and their Art. 73 reporting clocks, reading the AI register, exporting evidence for an auditor, and keeping track of governance gaps. # Incidents, the register and evidence This page covers the tenant-wide side of governance: serious incidents (Art. 73), the AI register, the files you hand to an auditor, and how to keep an eye on gaps such as overdue reviews and unowned systems. *** ## Serious incidents A serious incident (Art. 3(49)) is recorded against one agent, MCP server or LLM gateway. The platform keeps the Art. 73 reporting clock, the evidence and your filing reference. It does **not** report anything to an authority: you file the report through the authority's own channel and record the reference here. ### Categories and deadlines The category sets the clock: the report is due a fixed number of days after the **awareness date**. | Category | Shown as | Report within | Legal basis | | - | - | - | - | | `DEATH` | Death of a person | 10 days | Art. 3(49)(a); Art. 73(4) | | `SERIOUS_HARM_TO_HEALTH` | Serious harm to a person's health | 15 days | Art. 3(49)(a); Art. 73(2) | | `CRITICAL_INFRASTRUCTURE_DISRUPTION` | Serious and irreversible disruption of critical infrastructure | 2 days | Art. 3(49)(b); Art. 73(3) | | `FUNDAMENTAL_RIGHTS_INFRINGEMENT` | Infringement of fundamental-rights obligations | 15 days | Art. 3(49)(c); Art. 73(2) | | `WIDESPREAD_INFRINGEMENT` | Widespread infringement | 2 days | Art. 3(49)(c); Art. 3(61); Art. 73(3) | | `PROPERTY_OR_ENVIRONMENT_HARM` | Serious harm to property or the environment | 15 days | Art. 3(49)(d); Art. 73(2) | The Act asks for some reports "immediately"; the day counts above are the outer limits. ### Statuses and the clock | Status | Meaning | Clock | | - | - | - | | **Draft** | Raised but not yet confirmed as serious — typically from a monitor alert | None | | **Open** | Confirmed. Shown as *Report due in N days*, *Report due today* or *Overdue by N days* | Running: due = awareness date + category days | | **Reported** | The report reached the authority; its reference and date are recorded | Stopped | | **Closed** | Done, or dismissed as not serious after all | Stopped | * **Confirming** a draft starts the clock from its awareness date, or from the moment of confirmation if no awareness date was entered. * Editing the **category** or the **awareness date** of an open incident recomputes the deadline. * **Recording the report** is only possible on an Open incident. Enter the authority's reference and when it was filed (now by default). A report filed after the deadline is accepted and noted as late on the governance timeline. * **Closing** needs a reason. You can close a draft (not serious after all), an open incident (closed without a report, which the timeline says), or a reported one. * Every change is a governance event on the audit chain, so the record can be edited while live and still be shown to be unaltered. Opening or confirming an incident **does not suspend the system and does not notify anyone**. If the system must stop, suspend it on its lifecycle page (reason *Serious incident*) or freeze it. If people must be told, tell them — the platform only records that the incident exists. ### Opening an incident | Where | How | | - | - | | **Govern › Incidents** | **Report an incident**: choose the system, category, title, description and awareness date; confirm it now or keep it as a draft. | | A system's **Governance › Governance lifecycle** | **Report incident…** opens the same form for that system. | | **Observe › Alerts**, on an alert about an agent, MCP server or LLM gateway | **Open incident…** creates an incident with the alert attached as evidence (alert id, detector, severity, detection time, summary and the alert's own evidence). | An incident opened from an alert: * is a **Draft** unless you tick *Confirmed serious incident*, in which case it opens with the clock running from the alert's **detection time**; * links back to the alert (*Raised from: Monitor alert*); * can be opened only **once per alert**; * needs **Audit · Write** (the other routes need Registry · Write). Through the API: `POST /registry/v1/governance/incidents` to open one, or `POST /audit/v1/monitors/alerts/{alertId}/incident` with `{"category": "SERIOUS_HARM_TO_HEALTH", "confirmed": false}` to open one from an alert. ### The Incidents page **Govern › Incidents** lists every incident with the most urgent first: overdue, due within three days, running, drafts, then closed. Tiles across the top show *Overdue*, *Due in 7 days*, *Awaiting confirmation*, *Open in total* and *Reported this quarter*. Filter by status, category, system type and deadline (*Overdue or due today*, *Due within 2 / 7 / 15 days*), or search by title. *** ## The AI register **Govern › AI register** lists every agent, MCP server and LLM gateway in the tenant. It doubles as an AI asset inventory. | Column | Shows | | - | - | | System | Name and type | | Risk classification | The effective tier, marked when a second signature is pending or when the tier is inherited from agents, and the own tier where it differs | | Governance lifecycle | Draft, Assessed, In service, Suspended, Retiring or Retired | | Incidents | Live incidents (draft or open) and the nearest report deadline | | Role | Provider, Deployer or Both, from the latest classification | | Accountable owner | The owner, marked *Unconfirmed* when inferred from the creator | | Classified | When the latest classification was signed, or *Never* | | Review due | The review date, marked *overdue* or *brought forward (Art. 25)* | | Retention holds | Shown when any listed row is retired: logs and documentation kept until | Filters: system type, one or more tiers, lifecycle state, incidents (*Open incidents*, *Report due within 2 / 7 / 15 days*), *Reassessment pending*, *Unclassified only*, and a name search. The tier filter matches the effective tier; *Unclassified only* matches the system's own tier. The seven tiles count the whole tenant, regardless of filters and paging: | Tile | Counts | | - | - | | Systems | Every agent, MCP server and LLM gateway | | High-risk or above | Systems whose effective tier is High-risk (exempt), High-risk or Prohibited | | Unclassified | Systems with no classification of their own | | Pending approval | Systems whose latest classification is waiting for its second signature | | Review overdue | Systems whose review date has passed, including brought-forward reviews | | Owner unconfirmed | Systems without an assigned owner (inferred or missing) | | Open incidents | **Systems** with at least one draft or open incident — not the number of incidents | The same data is available as `GET /registry/v1/governance/register` (with the filters as query parameters, plus `ownerUserId` and `reviewDueBefore`) and `GET /registry/v1/governance/register/stats`. *** ## Exporting evidence Evidence exports are on **Govern › Compliance reports**, in the **EU AI Act evidence** card. They need **Audit · Read**, and they read what the registry holds now — the date range at the top of the Compliance reports page does not apply to them. | Export | Format | Contents | Filter | | - | - | - | - | | AI register | CSV or JSON | One row per system: type, id, name, operational status, own and effective tier, role, approval pending, owner user id and whether confirmed, classified and review dates, inherited-from count, oversight count, oldest literacy attestation, review trigger, lifecycle state and retention holds | All systems, In service, Suspended or Retired | | Serious incidents | CSV or JSON (the format chosen for the register) | Every incident with its category, awareness date, deadline, filing reference and outcome, soonest deadline first | All, Open, Awaiting confirmation, Reported or Closed | | Evidence pack | JSON | Everything about one system — see below | Choose the system | | Annex VIII extract | JSON | The EU database registration fields for one system — see below | Choose the system; not available for LLM gateways in the UI | API equivalents: `GET /registry/v1/governance/register/export?format=csv`, `GET /registry/v1/governance/incidents/export?format=json`, `GET /registry/v1/agents/{agentId}/governance/evidence-pack` and `GET /registry/v1/agents/{agentId}/governance/annex-viii` (or the `mcp-servers` / `llm-gateways` equivalents). ### The evidence pack One JSON document per system, holding what an auditor usually asks for: * the summary (tiers, owner, review date, lifecycle state) and the current state with any pending approval; * every classification, with its answers, legal basis, assessor and approver; * the current accountability assignments; * the linked documents with their status and SHA-256; * attestations; * readiness at the time of export, and the readiness recorded at each state change; * the governance state log; * the retirement case, if any; * every serious incident the system has had; * the Annex VIII Section A fields as far as the record holds them. For a **live** system the pack is built from current data and carries `generatedAt`. For a **retired** system it is read from the immutable snapshot taken at retirement and carries `sealedAt` and the `checkpointId` of the audit integrity checkpoint that seals it, which you can verify under **Govern › Immutable proof**. ### The Annex VIII extract The Annex VIII extract (Art. 49) fills the sections that apply from the record and lists what is still missing for submission to the EU database: | Section | Applies when | | - | - | | A — provider of a high-risk system | Your role is Provider or Provider and deployer, and the effective tier is High-risk | | B — provider of an Art. 6(3) exempt system | Your role is Provider or Provider and deployer, and the effective tier is High-risk (exempt) | | C — deployer | Your role is Deployer or Provider and deployer, and the effective tier is High-risk or High-risk (exempt) | Each field says where its value came from (the classification, an assignment, a document, the lifecycle). Values the platform does not model — the Member States concerned, a notified body's certificate number — are reported as missing, never guessed. The status fields follow the governance state and, once retired, the market action. The extract is a preparation aid; you still submit the registration yourself. *** ## Governance checks The platform includes five governance checks, each a monitor template in audit-service that reads the AI register: | Check | Looks for | Alerting behaviour | | - | - | - | | EU AI Act review due | A classification review due within the window (Low 7 days, Medium 30, High 90) or overdue | Once per due date | | EU AI Act orphaned owner | An active system with no owner at all; at High sensitivity, also one whose owner is only inferred | At most once a day per system until fixed | | EU AI Act unclassified agent | An active agent with no classification | At most once a day per agent until fixed | | EU AI Act stale literacy attestation | A high-risk system whose owner, deputy or oversight persons lack an AI literacy attestation younger than 12 months | At most once a day per system until fixed | | EU AI Act incident report due | A confirmed incident's report due soon (Low: 1 day before; Medium: 5 and 1; High: 10, 5 and 1) or overdue | Once per reminder; daily once overdue | **In this release these templates cannot be enabled.** The Monitors page creates Threshold, Change and Outlier monitors only, and template monitors are not created automatically for a tenant. Until they can be, use the views below for the same conditions, and check them on a schedule — nothing will remind you. | Condition | Where to see it today | | - | - | | Reviews due or overdue | AI register: *Review due* column and *Review overdue* tile; tier and *Reassessment pending* filters | | Missing or unconfirmed owners | AI register: *Owner unconfirmed* tile and *Accountable owner* column | | Unclassified agents | AI register: *Unclassified only* with the type set to *Agents* | | Lapsed literacy attestations | Each system's Accountability page; the readiness item *Oversight by persons with competence, training and authority* | | Incident reports due | Govern › Incidents: *Overdue* and *Due in 7 days* tiles, and the deadline filter | Monitors you create yourself still matter for governance: a high-risk agent's *Post-market monitoring in place* obligation is satisfied by any **enabled** monitor whose filter names that agent, and alerts from such monitors can be turned into incidents. ### Notifications Two kinds of message leave the platform for governance, and both go through **notification-service**: * **Monitor alerts** are delivered to the notification channels selected on each monitor (configured under **Manage › Notifications**) by e-mail, Slack or Microsoft Teams. A *Webhook* destination can be saved but is not delivered in this release. A monitor with no channels selected only shows its alerts under **Observe › Alerts**. Monitors are only evaluated when ClickHouse is enabled. * **Governance notices** — a corrective retirement being opened, and every retirement completing — are e-mailed to the people affected, which needs **SMTP**. On a self-hosted install, keep `notification` enabled in your values file and configure SMTP. With notification-service off, these messages are retried and then dropped without any visible failure; with SMTP off, e-mail is logged and dropped. The governance record still shows who should have been told. See [Turning services off](/self-hosting/configuration#turning-services-off) and [SMTP](/self-hosting/configuration#smtp). *** ## Next Where things live, day one after upgrading, permissions. Risk tiers, the wizard, second signatures and inherited tiers. Owners, oversight, documents, readiness and Art. 50 transparency. States, suspension, retirement and the tenant governance policy. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.