> ## 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.

# The governance record

> Accountability roles, human oversight in the relay, linked compliance documents, readiness, and the Art. 50 disclosure and marking settings for agents.

# The governance record

Beside its classification, each system's record holds who answers for it,
which documents evidence its obligations, how ready it is, and — for agents —
what the relay tells people about it. This page covers the
**Accountability** and **Compliance record** pages, the **Readiness** and
**Transparency (Art. 50)** sections of the **Classification** page, and the
one place where the record changes what happens at runtime: human review on
high-risk agents.

***

## Accountability

Open a system's **Governance › Accountability** page and use
**Accountability** to edit the roles. The whole set is saved at once with an
optional reason; every change of membership is its own event on the audit
chain, and a change of owner is recorded as an *ownership transfer*, not a
removal and an addition.

| Role | Shown as | Legal basis | Held by | How many |
| - | - | - | - | - |
| `ACCOUNTABLE_OWNER` | Accountable owner | Art. 17(1)(m) | A platform user | Exactly one — required |
| `DEPUTY_OWNER` | Deputy owner | Continuity | A platform user, not the owner | At most one |
| `OVERSIGHT_PERSON` | Oversight person | Art. 14(4), Art. 26(2) | A platform user | Any number |
| `PROVIDER_CONTACT` | Provider contact | Art. 13(3)(a) | A platform user or an external contact | At most one |
| `AUTHORISED_REPRESENTATIVE` | Authorised representative | Art. 22 | A platform user or an external contact | At most one |
| `DATA_PROTECTION_CONTACT` | Data protection contact | Art. 26(9), Art. 27(4) | A platform user or an external contact | At most one |

The rules the platform enforces:

* Every saved set must include an **accountable owner**.
* Owner, deputy and oversight persons must be **platform users**: the Act
  asks for natural persons, and the platform needs them to be auditable
  actors. The contact roles may instead be an external contact (name,
  organisation, email, address), for when you deploy someone else's system.
* The deputy must be a **different person** from the owner.
* The same person cannot hold the same role twice.

Holding a role grants nothing on the platform. Permissions still come from
groups; see [Permissions](/governance/overview#permissions).

### Owner unconfirmed

After the upgrade, every agent and MCP server shows the user who registered
it as its owner, marked **Unconfirmed**. That owner is inferred, not
assigned: it does not satisfy the *accountable owner* obligation, it does not
count for the human-oversight check below, and the register counts it under
*Owner unconfirmed*.

On the Accountability page, **Confirm owner** saves the inferred person as
the assigned owner (with a reason, defaulting to "Owner confirmed"). To name
someone else, edit the roles instead. LLM gateways have no inferred owner;
assign one.

### AI literacy attestation

For each owner, deputy and oversight person you can record the date their AI
literacy training was last attested (Art. 4) and a link to the training
record. An attestation is **current for 12 months**; after that it shows as
lapsed. A lapsed or missing date matters in two places:

* the *oversight persons* obligation of high-risk systems needs at least one
  oversight person with a current attestation;
* the register exposes the oldest attestation among owner, deputy and
  oversight persons, and reports none if any of them has no date.

The platform records the date you enter. It does not run or verify training.

***

## Human oversight in the relay

This is the one place where governance assignments change runtime behaviour.
When an agent's **effective tier** is High-risk (exempt) or stricter,
resolving its human-review holds (**Govern › Approvals**, *HITL requests*
tab) is restricted to the people named on its record.

| Situation | Who can resolve a hold on that agent |
| - | - |
| Effective tier below High-risk (exempt) | Anyone with permission to resolve holds, as before |
| High-risk, and at least one oversight person assigned | Only the assigned **oversight persons**, the assigned **accountable owner** and the **deputy owner**. Anyone else gets `403` |
| High-risk, but no oversight person assigned | Anyone, as before. The relay logs a warning and readiness reports the gap |
| The registry cannot be reached | The check is skipped and the resolution goes ahead |

* Only **assigned** roles count. An unconfirmed, inferred owner does not.
* The relay caches each agent's list of people for **30 seconds**, so a new
  assignment can take that long to apply.
* The restriction covers resolving holds. It does not route holds to those
  people or notify them.

***

## Compliance documents

The **Compliance record** page holds links to documents that live in your own
document system. Use **Link a document** to add one.

| Field | Notes |
| - | - |
| Kind | One of the 20 kinds below. The kind decides which obligation the document can satisfy. |
| Title | What reviewers see. |
| URL | Must be `https://`. |
| External reference | Optional: a DMS id, ticket or version. |
| SHA-256 of the content | Optional: 64 hex characters, of the document as it was when you linked it. |
| Issued on, Valid until, Review due | Optional dates. **Valid until** is the one the platform acts on. |

<Warning>
  **Documents are links, not uploads.** The platform never fetches the URL, so
  it cannot check that the link works, that the SHA-256 matches, or that the
  file has not changed since. The hash is evidence only because it is recorded
  on the audit chain at the moment you link the document and is sealed into the
  record at retirement; computing it, and comparing it later, is up to you.
</Warning>

### Status

| Status | How it arises | Satisfies an obligation? |
| - | - | - |
| Draft | Every new or superseding link starts here | No — a draft is progress, not evidence |
| Approved | Someone with Write presses **Approve** | **Yes**, while unexpired |
| Expired | An approved document whose *Valid until* date has passed | No |
| Superseded | A newer version was linked with **Supersede** | No |

Approving a document needs Write on the system; it can be the same person who
linked it. Superseding replaces a document with a new **draft** version, so
the obligation it satisfied is unmet again until the new version is approved.

### Document kinds

| Kind | Shown as | Legal basis |
| - | - | - |
| `RISK_ASSESSMENT` | Risk assessment | Art. 9 |
| `ART_6_3_ASSESSMENT` | Art. 6(3) derogation assessment | Art. 6(4) |
| `FRIA` | Fundamental rights impact assessment | Art. 27 |
| `DPIA` | Data protection impact assessment | Art. 26(9); GDPR Art. 35 |
| `TECHNICAL_DOCUMENTATION` | Technical documentation | Art. 11; Annex IV |
| `INSTRUCTIONS_FOR_USE` | Instructions for use | Art. 13 |
| `HUMAN_OVERSIGHT_PROCEDURE` | Human oversight procedure | Art. 14; Art. 26(1)-(2) |
| `DATA_GOVERNANCE` | Data governance | Art. 10; Art. 26(4) |
| `QMS` | Quality management system | Art. 17 |
| `CONFORMITY_ASSESSMENT` | Conformity assessment | Art. 43 |
| `EU_DECLARATION_OF_CONFORMITY` | EU declaration of conformity | Art. 47 |
| `EU_DATABASE_REGISTRATION` | EU database registration | Art. 49; Annex VIII |
| `POST_MARKET_MONITORING_PLAN` | Post-market monitoring plan | Art. 72 |
| `WORKER_NOTIFICATION` | Worker notification | Art. 26(7) |
| `AFFECTED_PERSON_NOTICE` | Affected person notice | Art. 26(11); Art. 50 |
| `SUPPLIER_AGREEMENT` | Supplier agreement | Art. 25(4) |
| `DECOMMISSIONING_PLAN` | Decommissioning plan | Art. 20; Art. 18; Art. 26(6) |
| `GPAI_MODEL_DOCUMENTATION` | GPAI model documentation | Art. 53(1)(b); Annex XII |
| `CODE_OF_CONDUCT` | Code of conduct | Art. 95 |
| `OTHER` | Other | — |

### Which documents are required

These are the platform defaults. **Mandatory** obligations count towards the
*Mandatory* readiness score and the gate; **advisory** ones only towards
*Overall*. Tiers are the system's effective tier; the role is the one
recorded on its own latest classification, so role-specific obligations
apply only once the system has been classified itself.

| Document | Required for | Default |
| - | - | - |
| Risk assessment, Technical documentation, Data governance, Quality management system, Conformity assessment, EU declaration of conformity | High-risk; provider or provider-and-deployer | Mandatory |
| Post-market monitoring plan | High-risk; provider or provider-and-deployer | Advisory |
| Instructions for use, Human oversight procedure | High-risk | Mandatory |
| EU database registration | High-risk or High-risk (exempt); provider or provider-and-deployer | Mandatory |
| Art. 6(3) derogation assessment | High-risk (exempt) | Mandatory |
| Fundamental rights impact assessment | High-risk; deployer or provider-and-deployer; Annex III 5(a)–5(d) use cases | Mandatory |
| Worker notification | High-risk or High-risk (exempt); deployer or provider-and-deployer; Annex III 4(a) or 4(b) | Mandatory |
| Affected person notice | High-risk; deployer or provider-and-deployer | Mandatory |
| Data protection impact assessment | High-risk; deployer or provider-and-deployer | Advisory |
| Supplier agreement | MCP servers at High-risk or High-risk (exempt) | Mandatory |
| GPAI model documentation, Supplier agreement | LLM gateways at High-risk or High-risk (exempt) | Mandatory |
| Decommissioning plan | Any tier from Minimal to High-risk | Advisory (mandatory to complete a retirement) |

The tenant
[governance policy](/governance/lifecycle-and-policy#tenant-governance-policy)
can make more document kinds mandatory per tier. That only promotes an
advisory obligation that already applies (for example, making the DPIA
mandatory for High-risk); it cannot create an obligation that does not apply
to a system, and it never makes a default-mandatory one optional.

***

## Readiness

The **Readiness** section on the Classification page lists every obligation
that applies to the system at its effective tier, with two rings:

* **Mandatory** — the share of mandatory obligations satisfied. This is what
  the gate checks.
* **Overall** — the share of all applicable obligations satisfied.

Each obligation is **Satisfied**, **Unmet** or **Unknown**, with a link to
where it is fixed. *Unknown* means a signal the platform needed from another
service was unavailable; it is never counted as satisfied, and the section
says so.

### What the platform checks itself

"High-risk tiers" means High-risk (exempt) and High-risk.

| Obligation (as shown) | Satisfied when | Applies to |
| - | - | - |
| Automatic event logging over the lifetime of the system | Always: relayed traffic is logged on the audit hash chain | Agents, Minimal to High-risk |
| A named, confirmed accountable owner | An owner is **assigned** (an inferred owner does not count) | Every system |
| A deputy owner distinct from the accountable owner | A deputy is assigned and differs from the owner | High-risk tiers (advisory) |
| Oversight by persons with competence, training and authority | At least one oversight person has an AI literacy attestation younger than 12 months | High-risk tiers; also MCP servers whose tools take irreversible actions or move money |
| Ability to stop the system | Always: the per-agent kill switch exists | Agents, high-risk tiers |
| Effective human oversight bound to the agent | The relay reports a policy bound at agent scope with a HITL rule or a human-review action | Agents, high-risk tiers |
| Tested against predefined metrics recently | A **passed** evaluation run targeting the agent within the evaluation validity window (default 30 days) | Agents, high-risk tiers |
| Post-market monitoring in place | At least one **enabled** monitor whose filter names this system | Agents, high-risk tiers |
| Logs kept at least six months | The **audit-service** retention floor is at least 183 days (it is 183 unless changed) | Agents, high-risk tiers |
| Impact profile declared | The MCP server has an impact profile | MCP servers, Minimal to High-risk |
| Tell people they are interacting with an AI system | Disclosure is on and has text | Agents whose classification says they interact with people |
| Machine-readable marking of synthetic content | Marking is on | Agents whose classification says they generate synthetic content |

The relay and audit signals are cached for 30 seconds, and a failed lookup is
cached as *Unknown* for the same time.

### Attestations

Some obligations cannot be observed by the platform, so a person attests
them with **Attest** on the obligation: emotion recognition or biometric
categorisation disclosure (Art. 50(3)), deepfake and public-interest text
disclosure (Art. 50(4)), and several retirement checklist items. An
attestation records the signer, an optional note and the date (today by
default), and counts for **12 months** from that date.

***

## Transparency (Art. 50)

For agents, the Classification page has a **Transparency (Art. 50)** section.
Changes are recorded on the governance timeline and applied by the relay from
the next message.

| Setting | Values | Notes |
| - | - | - |
| Tell people they are interacting with an AI system | On / off | Turning it on requires text |
| Text | Up to 1,000 characters | Suggested: *You are talking to an AI assistant. Its answers are generated automatically; a person can be asked to review any decision it takes.* |
| When | *Once, at the first reply of a conversation* (`FIRST_INTERACTION`, default) or *On every reply* (`EVERY_RESPONSE`) | |
| Channels | Every channel, or selected channels | Selecting channels limits the notice on channel traffic only; people using the agent directly on the platform always get it |
| Mark generated outputs as AI-generated | On / off | Synthetic content marking (Art. 50(2)) |

### How the disclosure is delivered

* It applies only on **person-facing legs**: replies to a channel, or to a
  person subscribed to the agent. Agent-to-agent calls never carry it, and a
  sub-agent's disclosure never reaches the person — the setting that counts
  is on the agent the person talks to.
* The notice is **not merged into the reply**. The relay adds it as a
  separate message placed before the agent's reply in the conversation
  history, flagged `metadata.ai_disclosure: true`, and puts the text in
  `metadata.ai_disclosure` on the result.
* In *once* mode it is added when the conversation has no earlier reply; in
  *every reply* mode on each turn.
* Each injection writes an audit event.

<Warning>
  **Custom channel integrations that read only the reply text will miss the
  notice.** The relay cannot draw your channel's UI. If you built a channel
  integration, it must render `metadata.ai_disclosure` (or use the channel
  client's helpers) — otherwise people never see the notice and the obligation
  is not met, even though readiness shows the control as satisfied. Point your
  integrators at [AI Disclosure Notice](/sdks/typescript/ai-disclosure).
</Warning>

### How synthetic content marking works

When marking is on, on every leg (agent-to-agent included):

* each agent-authored message and each artifact gets an `ai_generated` block
  in its metadata: `{"standard": "swarmd-provenance/1", "generator": "<agent id>", "generated_at": "…", "article": "Art. 50(2)"}`;
  each text part is flagged `ai_generated: true`;
* the result carries a `synthetic_content` manifest with the number of marked
  messages and artifacts, and which part types were marked by metadata only;
* the HTTP response carries `X-Swarmd-Synthetic-Content: ai-generated` and
  `X-Swarmd-Provenance: standard=swarmd-provenance/1; generator=…; context=…`.

What it does not do: it does not watermark text, images or audio, it does
not embed a C2PA manifest in files (files and data parts are marked by
metadata only), and the headers are not sent to streaming subscribers.

<Note>
  Both the disclosure and the marking are applied to replies of the A2A
  `message/send` method, which the channel client and the conversation API use.
  Replies delivered over the streaming method (`message/stream`) carry neither,
  so do not rely on these controls for an integration that streams replies to
  people.
</Note>

***

## API

Through the gateway, under `/registry`. Replace `agents/{agentId}` with
`mcp-servers/{mcpServerId}` or `llm-gateways/{llmGatewayId}` where the
action applies to all three.

| Method and path | Purpose |
| - | - |
| `PUT /registry/v1/agents/{agentId}/governance/assignments` | Replace the full set of roles (`assignments`, `reason`) |
| `POST /registry/v1/agents/{agentId}/governance/documents` | Link a document |
| `POST /registry/v1/agents/{agentId}/governance/documents/{documentId}/approve` | Approve a draft |
| `POST /registry/v1/agents/{agentId}/governance/documents/{documentId}/supersede` | Replace a document with a new draft version |
| `POST /registry/v1/agents/{agentId}/governance/attestations` | Attest an obligation (`obligationId`, `note`, `attestedOn`) |
| `GET`, `PUT /registry/v1/agents/{agentId}/governance/transparency` | Read or replace the Art. 50 settings (agents only) |

***

## Next

<CardGroup cols={2}>
  <Card title="Overview" icon="compass" href="/governance/overview">
    Where things live, day one after upgrading, permissions.
  </Card>

  <Card title="Classification" icon="scale-balanced" href="/governance/classification">
    Risk tiers, the wizard, second signatures and inherited tiers.
  </Card>

  <Card title="Lifecycle and policy" icon="arrows-rotate" href="/governance/lifecycle-and-policy">
    States, suspension, retirement and the tenant governance policy.
  </Card>

  <Card title="Incidents and evidence" icon="file-shield" href="/governance/incidents-and-evidence">
    Serious incidents, the register, exports and the evidence pack.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.