> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mnemom.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Unified cards

> The alignment and protection card surface — what each card is, how they compose, and where to find each endpoint.

<Note>
  Available under `X-Mnemom-Version: 2026-04-15` and later. See
  [Agent cards](/concepts/agent-cards) for the two-card model.
</Note>

## Two cards per agent

Every agent on Mnemom is governed by two YAML cards:

| Card                | Authors                   | Answers                                                    |
| ------------------- | ------------------------- | ---------------------------------------------------------- |
| **Alignment card**  | Agent operator, Org admin | Who is this agent? What may it do? What does it commit to? |
| **Protection card** | Security operator         | How is this agent protected from threats?                  |

Both cards are composed at storage time from three scopes — **Platform** ⇒ **Org** ⇒ **Agent** — into a canonical document the gateway and observer read on every request. Composition semantics (union / deny-overrides / floor / concat) are defined on the [Agent cards](/concepts/agent-cards) page.

## Endpoint surface

### Per-agent

| Method | Path                                      | Purpose                                     |
| ------ | ----------------------------------------- | ------------------------------------------- |
| GET    | `/v1/alignment/agent/:id`                 | Read the canonical alignment card           |
| PUT    | `/v1/alignment/agent/:id`                 | Publish a new alignment card (YAML or JSON) |
| GET    | `/v1/protection/agent/:id`                | Read the canonical protection card          |
| PUT    | `/v1/protection/agent/:id`                | Publish a new protection card               |
| GET    | `/v1/agents/:id/exemptions`               | List active exemptions                      |
| POST   | `/v1/agents/:id/exemptions`               | Grant an exemption (org-admin only)         |
| DELETE | `/v1/agents/:id/exemptions/:exemption_id` | Revoke an exemption                         |

### Per-org

| Method | Path                     | Purpose                                           |
| ------ | ------------------------ | ------------------------------------------------- |
| GET    | `/v1/alignment/org/:id`  | Read the org alignment template                   |
| PUT    | `/v1/alignment/org/:id`  | Update the template (triggers org-wide recompose) |
| DELETE | `/v1/alignment/org/:id`  | Clear the template                                |
| GET    | `/v1/protection/org/:id` | Read the org protection template                  |
| PUT    | `/v1/protection/org/:id` | Update the template (triggers org-wide recompose) |
| DELETE | `/v1/protection/org/:id` | Clear the template                                |

## Content negotiation

All card endpoints are YAML-first.

| Request header                | Response body |
| ----------------------------- | ------------- |
| `Accept: text/yaml` (default) | YAML          |
| `Accept: application/yaml`    | YAML          |
| `Accept: application/json`    | JSON          |

PUT endpoints accept either YAML (via `Content-Type: text/yaml`) or JSON
(via `Content-Type: application/json` with the raw card as the body, or
wrapped as `{ "card_yaml": "<yaml string>" }` or `{ "card_json": {...} }`).

## Required request headers on mutations

Every `PUT`, `POST`, or `DELETE` must carry:

```
Idempotency-Key: <opaque 24h-unique string>
```

Replays of the same key with the same request body return the cached
response. Replays with a different body return `422 Idempotency-Key conflict`.

## Cross-cutting contracts

Every response from a card endpoint includes `X-Mnemom-Schema`, every
mutation writes a `governance_audit_log` row before responding, and every
mutation emits a webhook event. See the [Governance guarantees](/api-reference/governance) page for details.

## What is NOT available through these endpoints

* **Trust edges, team cards, team coherence, fault lines** — separate endpoints under `/v1/teams/…`; unchanged by the unified-cards consolidation.
* **Safe House operational endpoints** (quarantine, canary, patterns, metrics, sessions, compliance reports) — preserved; unchanged by the unified-cards consolidation.
* **Policy evaluation** — `/v1/policies/evaluate` and `/v1/policies/evaluate/historical` are preserved as a distinct concern (evaluate a card's enforcement section against a tool manifest).