​

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

​

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.

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

​

Status

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

​

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

​

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.

​

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.

---

​

API

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

---

​

Next