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

# Framework Coverage

> How Wardin maps signed receipts to compliance-framework controls (EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2, NIST 800-53, ISO/IEC 27001) at read time — a coverage map and per-control evidence, without ever altering the canonical receipt.

Every gateway request already produces a [signed, hash-chained receipt](/concepts/receipts).
**Framework coverage** reads those receipts against a compliance framework and shows,
control by control, where a signed in-path check stands in for the control's evidence —
and, just as important, where it doesn't.

The mapping happens **at read time**. The canonical receipt — the thing that's signed —
is never changed by it. A framework pack is a separate, versioned interpretation layer
on top of the same immutable chain, so the same receipt can be read against EU AI Act
today and ISO/IEC 42001 tomorrow without re-signing anything.

<Note>
  These mappings are **draft legal-interpretation artifacts**, pending
  compliance-counsel review — **not legal advice**, and they cover **gateway-routed
  traffic only**. Wardin produces **Art-12-grade runtime records**; it does **not** make
  you "EU AI Act compliant," and no software can. Every pack is shown with a `DRAFT`
  status, its disclaimer verbatim, and its content hash.
</Note>

## Packs

A **pack** maps Wardin's receipt checks to a framework's controls. Six ship today, each
versioned and effective-dated:

| Framework           | Pack focus                                                                                                                                                     |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **EU AI Act**       | Automatic logging (Art 12), robustness (Art 15), deployer duties (Art 26)                                                                                      |
| **NIST AI RMF 1.0** | Govern / Map / Measure / Manage functions                                                                                                                      |
| **ISO/IEC 42001**   | AI management-system operational controls. *Evidence for an ISO/IEC 42001 audit — Wardin holds no ISO 42001 certification.*                                    |
| **SOC 2**           | Access & monitoring TSC — CC6.1/CC6.6 (access), CC7.2 (monitoring), C1.1 (confidentiality). *Evidence for a SOC 2 examination — Wardin holds no SOC 2 report.* |
| **NIST 800-53**     | Audit & Accountability (AU-2/3/12) + Access Control (AC-3), System Integrity (SI-4). *Not a FedRAMP authorization.*                                            |
| **ISO/IEC 27001**   | Annex A logging (A.8.15), monitoring (A.8.16), access (A.8.3). *Evidence for an ISO/IEC 27001 audit — Wardin holds no ISO 27001 certification.*                |

Each pack carries a **version**, an **effective date**, a verbatim **disclaimer**, and a
**pack hash** (a content hash of the pack's raw bytes). The gateway stamps the pack
version onto each receipt as it's written, so a receipt is always read against the exact
mapping that was in force when it was produced — even after a pack is later revised.

<Note>
  **The control mappings above are drafts, pending compliance-counsel review.** Which
  articles, functions, and controls each pack cites — and whether a check "proves" a
  given control — is Wardin's current engineering interpretation, **not a
  counsel-reviewed crosswalk and not legal advice**. Mappings will change as review
  completes; the pack `version` + `packHash` let you pin exactly which interpretation
  produced any claim. Treat them as a starting point for your own compliance team, not a
  substitute for one.
</Note>

## Coverage levels

Every control the pack cites gets one of three coverage postures:

* **`ENFORCED`** — a signed in-path check proves the control on every request (e.g. EU AI
  Act **Art 12**, satisfied by the signed, chained event log itself).
* **`PARTIAL`** — gateway checks cover part of the control; the rest is your process. The
  control row spells out the gap under **"Your responsibility."**
* **`EXTERNAL`** — no gateway check maps to the control. Its evidence lives outside the
  request path; Wardin can reference it, not prove it.

The coverage map summarizes these as a bar and counts (`n enforced · n partial · n
external`), so you can see a framework's request-path coverage at a glance.

## Proven by — the checks behind a control

An `ENFORCED` or `PARTIAL` control lists the in-path checks whose signed pass/fail results
are its evidence:

* **`BUDGET`** — per-key spend-limit enforcement
* **`ALLOWLIST`** — model allowlist
* **`GUARDRAIL`** — PII redaction / prompt-injection shield
* **`UPSTREAM`** — the provider call's outcome

Those check names are exactly the ordered `checks` on the receipt, so a control's claim is
traceable straight down to individual signed records.

## Querying evidence by control

Coverage tells you *what a control means*; the per-control drill-down tells you *which
requests it applied to*. For any in-path control you can pull a window (24h / 7d / 30d) of
the receipts that applied it, each with its outcome (`enforced` / `failed` /
`indeterminate`) and pack version, and open any one to verify it.

```bash theme={null}
# List the frameworks and their pack versions
curl https://gw.wardin.ai/api/v1/compliance/frameworks \
  -H "Authorization: Bearer $WARDIN_API_KEY"

# Coverage map for one framework
curl https://gw.wardin.ai/api/v1/compliance/coverage/eu_ai_act \
  -H "Authorization: Bearer $WARDIN_API_KEY"

# Receipts that applied a specific control, over a window
curl "https://gw.wardin.ai/api/v1/compliance/coverage/eu_ai_act/controls/eu_ai_act:art_12/receipts?range=7d" \
  -H "Authorization: Bearer $WARDIN_API_KEY"

# Which controls a single receipt satisfies
curl https://gw.wardin.ai/api/v1/compliance/receipts/$RECEIPT_ID/controls \
  -H "Authorization: Bearer $WARDIN_API_KEY"
```

The receipt query returns a **capped sample** of the window with cursor pagination — the
window totals are exact, the receipt rows are a page you scroll through.

Full request/response schemas are in the API reference:
[List frameworks](/api-reference/compliance/frameworks),
[Coverage map](/api-reference/compliance/coverage),
[Receipts by control](/api-reference/compliance/control-receipts), and
[Receipt controls](/api-reference/compliance/receipt-controls).

## Where to see it

The **EVIDENCE** rail stage in the app renders the full coverage map: pick a framework, read
each control's posture and evidence, and drill into the signed receipts behind it. It sits
next to the chain statistics and a sample verified receipt, because framework coverage is a
lens on the same receipt chain — read-only, never a place you configure anything.

<Note>
  **In active development (not yet available):** long-term **WORM retention** beyond the hot
  analytics window, a **one-click auditor export** bundle, and a fully **offline verifier**
  (check the chain with no Wardin account). Until those ship, treat framework coverage as a
  lens over the recent, verifiable receipt window — see [Signed
  Receipts](/concepts/receipts) for exactly what's verifiable today.
</Note>