Skip to main content
Every gateway request already produces a signed, hash-chained receipt. 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.
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.

​
Packs

A pack maps Wardin’s receipt checks to a framework’s controls. Six ship today, each versioned and effective-dated:
FrameworkPack focus
EU AI ActAutomatic logging (Art 12), robustness (Art 15), deployer duties (Art 26)
NIST AI RMF 1.0Govern / Map / Measure / Manage functions
ISO/IEC 42001AI management-system operational controls. Evidence for an ISO/IEC 42001 audit — Wardin holds no ISO 42001 certification.
SOC 2Access & 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-53Audit & Accountability (AU-2/3/12) + Access Control (AC-3), System Integrity (SI-4). Not a FedRAMP authorization.
ISO/IEC 27001Annex 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.
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.

​
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. 
# 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, Coverage map, Receipts by control, and 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.
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 for exactly what’s verifiable today.