Policy-as-code, without the cult.

The frame

Policy-as-code is one of those phrases that gets sold harder than it gets shipped. Every vendor has a manifesto. Every conference has a track. Most of the deployments we see in the wild are policy-flavored YAML, written by a single person, reviewed by no one, and enforced never.

We have shipped policy-as-code into seventeen regulated environments over the last four years. The ones that worked had three things in common.

One — the policy is enforceable in the runtime, not at the door

Most failed deployments treat policy like a customs check. You define a rule. The rule lives in some external service. Requests pass through it on the way in. Everything past the door is unchecked.

The problem is that real systems do work past the door. They emit events. They retry. They transform. They mutate state across many actions. A door check cannot reason about a saga that lasts four hours and crosses six systems.

Policy has to live inside the runtime, on the same data plane as the workflows it constrains. Otherwise the policy becomes theatre.

Two — the policy is simulated before it is enforced

The fastest way to lose Risk's trust is to ship a policy change that breaks production. The second fastest way is to ship one that does nothing, but tells everyone it did something.

Every policy change should run in three modes:

1. Simulate against the last 30 days of production traffic. Show me what would have been blocked. Show me what would have been allowed.

2. Shadow against current traffic. Decide, log, but do not enforce. Compare outcomes.

3. Enforce, with a manual kill switch and an automatic rollback if metrics regress.

If your policy framework does not support this, you do not have policy-as-code. You have a YAML file with ambitions.

Three — the policy has an owner who is awake

Every policy must name a human owner. Every change must name a human reviewer. Every alert must name an on-call rotation.

We have lost count of the deployments where the policy was right, the simulation was clean, and the enforcement was sound — and the entire system fell over because nobody knew who to call when an edge case fired at 2:14 a.m. on a Sunday.

The runtime can enforce the rule. The runtime cannot decide whether the rule was wrong. That is a human job.

What we mean when we say policy-as-code

We mean a system in which:

• +Rules are written in a real, typed language with real tests.
• +Rules are simulated, shadowed, and enforced through the same code path.
• +Rules carry an owner, a reviewer, and a rollback strategy.
• +Rules emit evidence the auditor can read without us in the room.

Anything less is a manifesto. We are not in the manifesto business.