4
gates on the outbound path
Every outbound action passes all four. There is no priority lane.
The policy layer
Four gates, and the record of every time one of them said no.
The policy layer is the part of Gevurah that is allowed to refuse. It closes by default, it refuses when it cannot verify, and it writes down the reason every single time.
Definition
A gate is a question the system must answer before it is allowed to act.
Most agent stacks put permission in the prompt. The model is told what it should not do, and the system hopes the instruction survives the next few thousand tokens. That is guidance, and guidance is not enforcement. A gate is code that sits between the intent and the outside world, and it runs whether or not the model remembered the rule.
There are four of them. Every action that leaves the system, a message, a purchase, a publish, a change to a live store, goes through all four. They close by default. If a gate cannot reach the evidence it needs to decide, it does not fall back to allow, and it does not ask the model for a second opinion. It refuses and writes down that it could not see.
What this page will not tell you
The exact conditions a gate evaluates, the order it evaluates them in, and the shape of the record it writes are not published. Publishing the pass conditions of a policy layer is publishing the instructions for getting past it. What is published here is what the layer enforces and what it has actually done.
Scale
Four gates, and the surface they cover.
42
read points across the codebase
Places where the policy state is consulted before something happens.
39
write points that record a decision
A decision that is not written down did not happen, as far as the audit is concerned.
≈102
tests on the policy layer
The layer that is allowed to say no carries more test weight than the layers that say yes.
29/137
policy decisions blocked, 21%
Each block is stored with the reason it was blocked. Snapshot of 12 August 2026.
281
records in the contact ledger
466 identities across 11 channels, so that the same person is the same person whether they arrived by email, chat, or phone.
Anatomy
The interesting record is the one where nothing happened.
A block is not an error. Errors are what a system produces when it tried and failed. A block is what a system produces when it was capable, was asked, and decided the action should not go out. The record holds the intent, the recipient, the channel, the gate that stopped it, the evidence the gate was looking at, and whether the refusal came from a rule or from an inability to verify.
- An agent forms an intent. Send this message, run this charge, publish this page.
- The gates read state, not intent. They look at what is true about the recipient and the channel right now, from the ledger and from the live source, rather than at what the agent believes.
- A refusal is recorded with its reason. The intent is not silently dropped. It stays visible, which means it can be picked up by a person later instead of being lost.
- An unverifiable state is a refusal. If the live source cannot be read, the gate does not guess. This single rule is responsible for a meaningful share of the blocks.
Why fail-closed is the whole design
The expensive failure in agent systems is not the action that gets blocked. It is the action that goes out on stale or missing information, to a real customer, with the system reporting success. A gate that opens when it cannot see is not a gate. It is a delay.
Provenance
Every gate exists because something went wrong once.
None of these rules were designed in advance. Each one was added after a specific failure in a real business: a message that went to someone who had already replied, a follow-up sent into a thread the system had misread, an action taken on a state nobody had checked. The rule is the scar.
That is also the part that is hard to copy. The architecture of a policy layer can be rebuilt by a competent team in a quarter. The list of things that actually break, in the specific order they break, takes as long as it takes.