> ## 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.

# Compliance Packs

> Choose which compliance frameworks appear on your evidence surfaces, and author your own custom framework→control mappings (BYO packs).

Wardin ships a set of **baseline compliance packs** — EU AI Act, NIST AI RMF, ISO/IEC
42001, SOC 2, NIST 800-53, ISO/IEC 27001 — that map signed receipt checks to each
framework's controls (see [Framework Coverage](/concepts/framework-coverage)). Those are
company-authored, counsel-reviewed, and version-controlled in git.

**Compliance Packs** is where a tenant tailors that layer, in two ways.

<Note>
  Custom packs are your organization's **own DRAFT interpretation** — always surfaced as
  such (`source: tenant`), never as the counsel-reviewed baseline. Mappings are draft,
  pending your own counsel's review; Wardin doesn't certify them, and nothing here makes you
  "compliant." Scope is gateway-routed traffic only.
</Note>

## Framework opt-in

By default every baseline framework shows on your EVIDENCE coverage surfaces. In
**Console → Organization → Compliance Frameworks**, a manager can narrow that to just the
frameworks your organization is audited against — a view filter only; the pack mappings
themselves stay in-repo. Selecting all frameworks (the default) means a newly-added pack
appears automatically.

## Custom packs (BYO mappings)

When the built-in frameworks don't cover a framework you need — an internal standard, or a
regulation we haven't shipped a pack for yet — you can author your own in
**Console → Compliance Packs**.

A custom pack is a YAML file that maps your controls to the gateway's in-path checks
(`AUTH`, `BUDGET`, `ALLOWLIST`, `GUARDRAIL`, `PII`, `UPSTREAM`). On save it is **validated fail-closed**:
the same schema + referential-integrity checks the baseline packs pass at boot run on
your pack, and a malformed pack is rejected with an error — it never persists, so it can
never mis-cite at query time.

Once saved, your pack is **merged behind the baseline**: it overrides a baseline framework
at the same effective date, or adds a new framework/version. Everything downstream — the
coverage map, per-control receipt queries, the [attestation](/concepts/attestation), and
the [Evidence Bundle](/concepts/offline-verification) — resolves against your merged set,
with tenant-authored packs always marked distinctly from the baseline.

### How it stays trustworthy

* **Content-hashed.** Every pack is `sha256`-hashed over its exact bytes; that hash is
  verified each time the pack loads (a silent database edit of a pack is detected and the
  pack is skipped, never served as the audited one).
* **Reproducible offline.** Unlike baseline packs (reproducible from git), a custom pack
  has no external copy — so its exact bytes are **snapshotted into every Evidence Bundle**
  (active and archived), and its `packHash` travels with any citation. An auditor can
  reproduce a tenant-authored mapping without trusting us.
* **Audited.** Every create / edit / archive / restore is recorded with who, what, and the
  content hash — visible as change history and carried in the bundle.
* **Archive, don't delete.** Disabling a pack archives it (kept for reproducibility);
  restoring it re-merges it.

<Note>
  A custom pack is always stored and rendered as **DRAFT**, regardless of what its YAML
  declares — a tenant-authored mapping can never present itself with counsel-reviewed
  authority.
</Note>