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: 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:
  • AUTH — virtual-key authentication
  • BUDGET — per-key spend-limit enforcement
  • ALLOWLIST — model allowlist
  • GUARDRAIL — prompt-injection / jailbreak detection
  • PII — PII redaction
  • 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.
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.
The one-click auditor Evidence Bundle export and the offline verifier (spec published; reference CLI, public release in preparation) are available today. In development: long-term WORM retention beyond the hot analytics window, so a bundle can span years rather than the recent window. Until it ships, treat framework coverage as a lens over the recent, verifiable receipt window — see Signed Receipts for exactly what’s verifiable today.