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

# Certification

> May this agent be given authority at all? One check, called from every place authority is issued or escalated.

Certification answers a question that sits **before** the nine gates: may this
agent hold authority in the first place?

The gates ask whether a particular action is permitted under a particular grant.
Certification asks whether the agent was ever fit to be granted anything. An
uncertified agent can be issued authority in `observe`, because observing costs
nothing, and cannot be promoted to a rung that refuses.

## What a certificate records

| Field                          | What it is                                        |
| ------------------------------ | ------------------------------------------------- |
| `agent_id`, `environment`      | Which agent, in which environment                 |
| `issued_by`, `issued_by_email` | The human who certified it. Not a service account |
| `basis`                        | What the certification rests on                   |
| `provenance_version`           | The model provenance bound at the time            |
| `manifest_hash`                | The MCP tool manifest as it stood                 |
| `content_hash`                 | The agent's own content, pinned                   |
| `market_profile`               | Which jurisdiction it was certified for           |
| `checks`                       | What was actually verified                        |
| `revoked_at`, `revoked_by`     | Certification is revocable                        |

The hashes are the point. A certificate that does not pin what it certified is
an opinion with a date on it.

## Four places it is enforced, not two

The check is one function called from every path that issues or escalates
authority:

```
POST /v1/grants                              issue
POST /v1/grant-families/{id}/instantiate     issue, from a template
POST /v1/grants/{id}/delegate                issue, to a DIFFERENT agent
POST /v1/grants/{id}/enforcement             escalate an existing grant
```

<Warning>
  The first implementation covered two of these, and the two it missed were the
  two that mattered.

  **Delegation** hands enforcing authority to an agent nobody checked.
  Attenuation does not help: a child that is a strict subset on all five axes
  still runs different tools under a different provenance.

  **Promotion** is the exact transition this exists for. Issue in `observe`, which
  needs no clearance by design, then promote. A control with a two-step path
  around it is worse than no control, because the console reports the grant as
  enforcing either way.
</Warning>

## The API

```http theme={"system"}
GET  /v1/agents/{agent_id}/certification
POST /v1/agents/{agent_id}/certification
GET  /v1/certificates
POST /v1/certificates/{certificate_id}/revoke
```

## Revoking

Revocation is a first-class field rather than a delete. A certificate that was
valid and then was not is a fact about a period of time, and deleting it would
destroy the only record that the agent was ever cleared.