Skip to main content
An auditor’s first question is never “do you have a policy?” — it is “show me, clause by clause, which control satisfies it, and prove it ran.” A control matrix answers exactly that: one row per in-scope clause, the plane it maps to, the live policy object enforcing it, and whether that control is covered, still in observe, a disclosed gap, or owner-attested. OrcaRouter builds this matrix for you from the packs you install — the same mapping that powers the signed report, so the readiness view and the evidence can never drift. This page shows how to read and assemble the ai compliance control matrix for your workspace, with one concrete clause walked end to end. For what a pack actually contains, follow the links at the end.

​
1. What an ai compliance control matrix is here

The matrix is the union of two lists per framework:
  • the clauses an installed pack covers — each joined to the exact guardrail or firewall policy that install materialized;
  • the clauses that can never be gateway-automated — workforce training, Business Associate Agreements, physical access — authored as honest gaps so the matrix discloses them rather than implying false 100%.
The matrix is a view, not a second engine. Every covered row points at a real, editable guardrail rule or firewall policy you already own — open it, read it, tune it. The matrix just records which one answers which clause.
Each clause maps to exactly one of two planes:

Guardrail plane

Content clauses — confidential PII, secrets, required disclosures — map to a guardrail rule with a block, mask, or flag action.

Firewall plane

Action clauses — excessive agency, dangerous tool calls, egress — map to a firewall rule with an allow / audit / deny verdict on the inbound, response, mcp, or egress surface.

​
2. The readiness states a row can carry

Every matrix row carries one state. These are the words an auditor reads, so they mean exactly what they say:
StateWhat it means
coveredA pack control is installed and enforcing the clause.
observeInstalled but log-only — collecting would-have-blocked evidence, not yet enforcing.
gapNo installed control covers the clause (or it is organizational and can’t be).
attestedAn organizational clause an Admin has owner-attested rather than automated.
A gap is not a failure — it is honesty. An organizational clause like HIPAA 45 CFR §164.308(a)(5) workforce training can never be enforced by a proxy, so the matrix surfaces it as a disclosed gap (or, once an Admin attests ownership, as attested) instead of pretending the gateway covers it.
There is also a drift overlay: if an installed pack’s mapping lags the current catalog version, its rows render as drift so you know to re-install before relying on the evidence.

​
3. Read the matrix (one concrete call)

The readiness endpoint returns the whole matrix — per-framework coverage percentages, the ranked top risks over the window, and one coverage_rows entry per clause. Browsing readiness is open to every workspace Member and is free, so your security and audit reviewers can watch the matrix without write access. The console drives this management route under your session — you never hand a relay sk-orca-… key to a compliance route: 
GET /api/compliance/readiness?window=30d
Authorization: Bearer <your console session>
A single covered row looks like this — clause, plane, state, and the live policy id it joins to: 
{
  "framework": "soc2",
  "control_id": "soc2.confidentiality",
  "clause": "TSC CC6.1 Logical access controls",
  "reference": "https://www.aicpa-cima.com/resources/...",
  "plane": "guardrail",
  "state": "covered",
  "guardrail_id": 41,
  "observe_count": 0,
  "organizational": false
}
The guardrail_id (or firewall_policy_id on the firewall plane) is the load-bearing field: it ties the clause straight to an object you can open in the console and edit like any other. That is the lineage an auditor walks — clause → control id → enforcing policy → the matches it produced.
Reading the matrix is a free Member capability. Building it — installing a pack so its controls populate the rows — is a workspace Admin action on a paid plan, and the server enforces both. A viewer or a free workspace cannot materialize coverage by calling the API directly. See Plan gating.

​
4. Assemble the matrix for your frameworks

You build the matrix by installing packs. Each install merges its controls into one guardrail and one firewall policy tagged with the pack’s provenance, and its clauses begin populating coverage_rows:
  1. Pick your frameworks. Install runs from the console under Compliance → Catalog, as a workspace Admin. The catalog covers security and AI-governance regimes (soc2, iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, owasp_llm), sector regimes (hipaa, pci_dss, glba, nist_800_53), and a wide set of regional privacy laws (gdpr, uk_gdpr, ccpa, and more). Browse the live set on Frameworks.
  2. Install in observe first. A fresh install lands in observe mode — guardrail actions coerced to flag, the firewall policy in shadow — so every new row starts as observe and produces would-have-blocked evidence before it enforces.
  3. Watch the rows fill. Re-fetch readiness over a real window. Covered rows show their observe_count; gaps stay disclosed; organizational clauses wait for attestation.
  4. Go live. When the rows read clean, a workspace Admin goes live and the observe rows flip to covered enforcement.
The OWASP Top 10 for LLM Applications is in the catalog as the owasp_llm pack — its clauses (for example LLM05:2025 Supply Chain) land in the matrix the same way every other framework’s do, mapped to live controls or disclosed as gaps. See OWASP LLM Top 10.

​
5. From matrix to signed evidence

The matrix you read in the console is the same coverage data the report serializes — so when you generate evidence, the auditor sees the identical per-clause states, plus the enforcement counts each control produced over the period. A clause that blocked 4,000 requests and a clause with zero matches read very differently, and the report shows both. Reports are SHA-256 hashed, Ed25519-signed, and publicly verifiable.
The exact guardrail and firewall objects a pack materializes, and how each clause joins to its enforcing policy — see Pack contents.
Why every row starts in observe, what it logs, and how go-live flips it — see Observe vs enforce.
How the matrix renders for an auditor, with per-clause states and enforcement counts — see Signed report.

​
6. Where to go next

Install a pack

The full install flow that populates the matrix — selecting controls, observe mode, and go-live.

All frameworks

The live catalog of frameworks whose clauses you can build into the matrix.

Guardrails vs Firewall

The two planes a matrix row can map to, and how the resolver runs them together.

Shared responsibility

Why some clauses are gateway-enforceable and others stay yours — the boundary every gap row reflects.
A control matrix is the bridge between a regulator’s checklist and your running gateway: one row per clause, joined to the live control enforcing it, honest about what a proxy can’t cover, and identical to the signed evidence you hand an auditor.