Skip to main content
Every control plane on OrcaRouter has two postures: observe, where the gateway evaluates and logs what a policy would do but never changes a response, and enforce, where the same policy actually blocks, masks, or holds the call. The split lets you watch a framework against your real traffic for a week before a single request ever fails — then flip it live when the numbers look right. This page is the customer-facing map of that boundary: which posture is free, which is paid, who can change it, and how to read the gap between the two before you commit.

​
1. Why compliance observe enforce is a two-step gate

A compliance framework that blocks on day one is a framework you turn off on day two. The honest sequence is: install in observe, read the would-block numbers against your own traffic, fix the gaps you didn’t know you had, then go live. OrcaRouter builds that sequence into the posture model so you never have to guess. (Installing a pack is a paid, Admin step on every plan — observe and enforce are two postures of the same paid pack, not a free tier and a paid tier. The free observe path lives on the Firewall and Guardrails planes, which carry no plan gate.)

Observe — free on Firewall & Guardrails

Put a Firewall policy in shadow_mode or a Guardrail in audit, and the gateway evaluates it against live traffic and records what it would have done — without ever changing a response. No plan required; writes are gated to Developer+. Browsing the compliance catalog and reading readiness rollups are free for any workspace member too.

Compliance packs — paid, Admin only

The compliance-pack plane — installing a pack (even in observe), setting up controls, and going live — requires a paid plan and the workspace Admin role. Go-live is where the pack’s materialized rules start actually blocking, masking, and holding calls.
Observe is not a watered-down trial. It runs the same evaluation engine as enforce against the same live traffic — it just suppresses the verdict’s effect. The numbers you see in observe are the numbers you’ll get when you flip the switch.

​
2. What each posture looks like across the planes

The two-step gate isn’t unique to compliance packs — every plane exposes an observe equivalent. Same idea everywhere: evaluate and log, don’t act.
PlaneObserve postureEnforce posture
Compliance pack (paid)Installed in observe mode — materialized rules log onlygolive flips the pack to enforce
Firewall policyshadow_mode — verdicts logged as [shadow] would …Live deny / sanitize / pending_approval
Firewall workspacefirewall_observe_mode — logs uncovered calls as gapsPolicies evaluate and act on covered surfaces
Autonomy levelpermissive — observe only, no enforcing policybalanced / tight — real audit and deny rows
Installing a compliance pack writes real, editable Guardrails and Firewall policies into your workspace in observe posture (firewall policies land in shadow_mode). Going live is just a posture flip on rows that already exist — not a re-install.

​
3. One concrete walkthrough

Here is the full observe-to-enforce loop for a single framework. Browsing the catalog and reading rollups are free; installing the pack (even in observe) and the final golive both require a paid plan and Admin.
1

Browse the catalog (free, any member)

Open Compliance in the console and review the available frameworks. Any workspace member can read the catalog, the installed-pack list, and the readiness rollup — no plan required.
# Read-only, session-authenticated (UserAuth) — done from the console.
GET /api/compliance/catalog
GET /api/compliance/readiness
2

Install in observe (paid plan, Admin)

From the framework’s card, choose Install. Installing a compliance pack requires a paid plan — the server rejects a free-plan install. The pack materializes its guardrail and firewall rules in observe posture (firewall rules in shadow_mode, guardrail actions coerced to log-only), so the gateway evaluates them against your live traffic immediately and logs every would-block without changing a single response.
# Paid + Admin, server-gated. Done from the console.
POST /api/compliance/packs/{key}/install
3

Read the gap (free, any member)

The readiness view now shows a would-block count per framework: how many real requests in your trailing window the framework would have stopped (attributed to the pack’s guardrail-plane rows). A high number is your signal to fix a workflow before you enforce, not after.
4

Go live (paid plan, Admin)

When the numbers look right, an Admin on a paid plan flips the pack to enforce. The same rules that were logging now block, mask, and hold — and the pack’s firewall policy leaves shadow_mode.
# Paid + Admin, server-gated. Done from the console.
POST /api/compliance/packs/{key}/golive
Configuration routes (/api/compliance/*, /api/guardrail/*, /api/workspace/firewall/*) authenticate with your console session, not a relay key. Only /v1/* model calls use an sk-orca-… key. The examples above are shown as routes for clarity, but you drive all of them from the console.

​
4. The free / paid boundary, precisely

On the compliance plane, only reading your posture is free; the moment you materialize a pack you’re on a paid path. The plan check is enforced server-side — a direct API call can’t bypass it.
Browsing the framework catalog, listing installed packs, reading the readiness rollup, reading the configured data residency, and listing report metadata are open to every member at no cost. Generating your workspace’s first compliance report as a PDF is free, too.
Setting data residency is gated to the workspace Admin role but is not behind a paid plan — any Admin can set the region.
Reports are publicly verifiable once generated — anyone with the artifact can confirm its signature without an account via report verification. Every report is signed (PDF, CSV, and JSON alike); verification is open to the world.

​
5. Read the would-block numbers before you flip

Observe exists so you can answer one question with data instead of nerve: what breaks when this goes live? Two surfaces give you the answer.
  • Readiness rollup — per-framework would-block counts for installed compliance packs (attributed to the pack’s guardrail-plane rows), so you can see which frameworks bite hardest against your trailing traffic before you enforce them. Readable by any workspace member.
  • Firewall events — record what each shadow_mode policy would have done; a [shadow] would deny line is a denial that didn’t happen yet. The Events feed is gated to Developer+ (the rows carry tool-call provenance). Firewall policies, settings, the discovered-tools view, the autonomy simulator, and the anomaly feed stay readable by any member.
  • Guardrails matches — the match feed records what each audit-mode guardrail would have flagged. Readable by any member.
The same staged rollout works at the autonomy level. Apply permissive (observe only) first, watch the events feed, then step up to balanced and tight for the surfaces that earn it — with one-click undo from the audit snapshot. See the secure-agents baseline.

​
6. Where to go next

Plan gating

Exactly which compliance actions require a paid plan, and what stays free on every tier.

Install a pack

Materialize a framework’s guardrail and firewall rules in observe — a paid, Admin first step before you go live.

Enforcement modes

The full posture vocabulary — observe, shadow, audit, and enforce — across every plane.

Shared responsibility

What the gateway enforces versus what stays your decision.
Observe is where you learn what enforce will cost you. On the Firewall and Guardrails planes you can watch for free; on the compliance-pack plane, install and go-live are the paid, Admin steps — read the would-block numbers first, then take it live on your terms.