Skip to main content
A framework checklist is a list of clauses. A compliance pack is the same checklist with each clause wired to a control that actually runs on the gateway. When you install a pack, OrcaRouter reads its clause-to-control mapping and materializes real, editable policy objects in your workspace — so “SOC 2 CC6.1” stops being a line in a spreadsheet and becomes a guardrail that blocks confidential PII before it reaches the model. This page explains what an ai compliance pack contains, how its two enforcement planes map back to clauses, and the provenance lineage that lets an auditor trace any clause down to the exact policy enforcing it. For the install flow and the signed report, follow the links at the end.

​
1. A pack is a clause-to-control mapping, not new enforcement

A pack ships no new runtime engine. Every control it carries reuses the same Guardrails and Firewall machinery you already configure by hand — a pack is the authored mapping that says which existing control satisfies which clause. Each pack spans two enforcement planes:

Guardrail plane

The text / data controls — clauses about confidential data, PII disclosure, injection defense, or required disclosures map to guardrail rules (pii, regex, llm_judge, and friends) with a block, mask, or flag action.

Firewall plane

The tool-call controls — clauses about excessive agency, dangerous actions, or egress map to firewall rules with an allow / audit / deny verdict on the inbound, response, mcp, or egress surface.
Installing the pack merges its selected controls into one guardrail and one firewall policy, tagged with the pack’s provenance, so they co-enforce through the normal resolver and every existing attachment and history path keeps working.
A pack covers gateway-enforceable controls only. Organizational clauses — workforce training, Business Associate Agreements, physical access — can never be enforced by a proxy, so the report discloses them as gaps (or as owner-attested) rather than claiming false coverage. See the control matrix.

​
2. One clause, end to end — a concrete example

Take the SOC 2 pack. It maps three Trust Services clauses to three live controls:
ClausePlaneControl
CC6.1 Logical accessguardrailblock confidential PII in prompts
CC7.2 System monitoringguardrailrecord every guardrail decision as evidence
CC7.2 Anomaly detectionfirewallaudit every tool dispatch
You install it from the console — Compliance → Catalog → SOC 2 → Install — which is workspace-Admin only and calls POST /api/compliance/packs/soc2/install for you under your console session. You never hand a relay sk-orca-… key to a configuration route; content and policy live entirely behind your console login. After install, the CC6.1 row is no longer prose — it is a guardrail rule you can open, read, and tune like any other.

​
3. Provenance lineage — clause to enforcing policy

The reason a pack is auditable is that the link between a clause and the policy enforcing it is recorded, not implied. Every control the pack materializes carries:
A stable control_id (e.g. soc2.confidentiality) and the verbatim clause text (TSC CC6.1 Logical access controls), plus an official source link so an auditor reads the regulation, not just our paraphrase.
Whether the control lives on the guardrail or firewall plane, and the id of the exact guardrail or firewall policy that install materialized. That id is what ties a row in the report back to a live, editable object in your workspace.
covered, observe, gap, or attested — and, over the report period, how many times that control actually fired. A clause with zero matches and a clause that blocked 4,000 requests read differently to an auditor, and the report shows both.
Each pack carries a MappedBy line — who authored the clause-to-control mapping, its version, and the honest disclaimer that it covers gateway-enforceable controls only and is not itself a certification. That line is stamped onto the signed report cover.
Put together, this is the lineage an auditor walks: clause → control id → enforcing guardrail or firewall policy → the matches it produced this period → who authored the mapping. No step is inferred.
The same coverage matrix powers both the console and the report, so the two can never silently drift. A clause the framework expects but no installed pack covers always renders as a disclosed gap on both surfaces.

​
4. Observe first, then enforce

A pack does not start blocking traffic the moment you install it. Installs land in observe mode: guardrail actions are coerced to flag and the firewall policy runs in shadow (log-only). The pack produces “would-have-blocked” evidence so you can see exactly what it would do against real traffic before it does it. When you are satisfied, a workspace Admin calls go-live, which restores the controls’ declared actions (mask / block / deny) and optionally promotes the materialized policies to workspace default. This is the same observe-then- enforce discipline described in Observe vs enforce.
Browsing the catalog, installed packs, and readiness is open to every workspace member and is free. Installing a pack and going live are workspace-Admin actions that require a paid plan — the server enforces both gates, so a viewer or a free workspace cannot materialize enforcement by calling the API directly. Generating a report is also Admin: the free plan includes one PDF report, while CSV/JSON exports and additional reports require a paid plan. Setting data residency is workspace-Admin as well, but is not itself paywalled.

​
5. What a pack does not contain

To keep the boundary honest:
  • No certification. A pack maps your gateway controls to a framework’s clauses and produces signed evidence. It is not an audit, an attestation of your whole organization, or legal advice.
  • No organizational controls. People-and-process clauses are surfaced as disclosed gaps or owner attestations, never as automated coverage.
  • No magic catalog. Frameworks in the catalog are the ones with an authored mapping — SOC 2, HIPAA, GDPR / UK GDPR, the EU AI Act, ISO 27001 / 42001, NIST AI RMF, PCI DSS, the OWASP LLM Top 10, and the regional privacy laws. Browse the live set on Frameworks.

​
6. Where to go next

Install a pack

The full install flow — selecting controls, observe mode, and go-live.

The signed report

What the Ed25519-signed evidence report contains and how the lineage renders for an auditor.

Control matrix

Every clause, its plane, and whether it is covered, observed, a gap, or attested.

Guardrails vs Firewall

The two planes a pack writes to, and how the resolver runs them together.
A compliance pack is the bridge between a regulator’s language and the gateway’s enforcement: it maps each clause to a real control, materializes that control into a policy you own and can tune, and records the lineage so the evidence holds up to inspection.