The Three-Phase Rule
Every intelligent system -- whether it is a trading bot, an LLM agent, or a sovereign AI -- must enforce a strict separation: cognition proposes, a deterministic governance runtime authorizes, and execution is logged.
This is not policy theater. It is architecture.
Most AI safety discussions focus on alignment, constraints, and red-teaming. These are important, but they address a downstream problem. The upstream problem is structural: the system that decides what to do and the system that is allowed to do it are often the same code path. This is a design flaw, not a constraint failure.
When you ask an LLM to generate a SQL query and it directly executes that query, you have collapsed the proposal layer into the execution layer. No governance runtime exists between them. The model proposes and executes in a single step. When things go wrong -- hallucinated joins, injection patterns, runaway loops -- there is no gate to catch it.
The fix is not a better model. The fix is separation.
The Enable Equation: 10 Gates
At Werner Harmonic Labs, the formalized version of this separation is called the Enable Equation: a 10-gate pipeline where all gates must evaluate to ALLOW before execution proceeds. They are AND conditions, not OR conditions. Any single gate that returns DENY blocks the proposal.
The gates cover distinct dimensions of validity:
- Regime validity: is the market environment appropriate for this signal type?
- Leverage bounds: does the proposed position size fall within policy?
- Drawdown constraint: would this trade breach a loss ceiling?
- Kelly criterion: is the risk-adjusted sizing correct for the current edge estimate?
- Capital availability: is there sufficient capital to cover the position?
- Thermal constraint: has the system already exhausted its execution budget for this window?
Each gate is fail-closed by default. If a gate cannot evaluate cleanly -- because upstream data is unavailable, or the proposal is malformed -- execution is blocked and the proposal is logged for forensic review.
The key point: gates are not added to handle edge cases. Gates are the architecture. They are what separates a governed system from an unconstrained one.
Why This Matters for LLM Agents
Modern LLM agents execute tools directly within a conversation loop. The model sees tool output, updates its context, and makes the next decision in real time. This is fast. It is also structurally ungoverned.
Consider a financial agent that reads a user request for a wire transfer, generates a proposal with a target account and amount, and immediately calls the wire API. If the model confuses two similarly named accounts -- a well-documented failure mode -- the money moves before any gate has evaluated whether it should.
A governed version of the same agent would:
- Generate the proposal with supporting metadata (confidence, source, reasoning chain)
- Route the proposal through a gate pipeline: Is the target account in an approved list? Does the amount fall within daily limits? Does the confidence score meet the acceptance threshold?
- Execute only if all gates pass
- Log the full decision to an immutable receipt ledger
This adds latency. It adds implementation complexity. It is the correct trade-off.
Fail-Closed Defaults
Fail-closed means: if a gate cannot decide, the answer is no.
If a regime detector crashes mid-evaluation, the gate does not default to ALLOW and continue. It defaults to DENY and logs the error for human review.
If a capital availability check queries a database that is momentarily unreachable, the gate does not time out and permit anyway. It waits, or it fails closed.
This sounds conservative. It is. That is the point.
When you separate proposal from authorization, you accept that some valid proposals will be rejected due to transient gate failures. This is the cost of maintaining structural control. The alternative -- allowing execution when governance is uncertain -- is how systems drift. Each exception seems reasonable in isolation. Taken together, they erode every boundary you designed.
Alignment-focused AI safety tries to ensure the model never generates bad proposals in the first place. This is necessary but not sufficient. Even a well-aligned model can hallucinate. Deterministic governance gates catch the hallucinations at the exit, regardless of what produced them.
Evidence and Receipts
Every authorization decision must be logged with full context: the proposal, each gate's evaluation result, the final decision, timestamps, and any override metadata.
These receipts serve three purposes.
First, forensic audit. When something goes wrong, you have a machine-readable record of what the governance system decided and why. You are not reconstructing intent from scattered logs.
Second, learning feedback. The governance system can improve over time by analyzing which gates reject proposals that, in retrospect, would have succeeded. If a gate is producing too many false negatives, receipts surface that pattern.
Third, accountability. If your intelligent system manages capital, handles user data, or influences consequential decisions, evidence that governance happened is not optional. Receipts are that evidence.
A receipt should never say "trade executed." It should say: "Trade executed because gates A, B, C, and D each evaluated to ALLOW, with supporting metrics available, at timestamp T, with a decision duration of N milliseconds."
If you cannot explain why a governance gate allowed something, you do not have governance. You have a system that sometimes says no, with no proof of the reasoning behind either answer.
Implementation Pattern
The simplest implementation separates gate evaluation from execution explicitly:
```python
class ProposalGate:
def evaluate(self, proposal, context):
"""Returns (allowed: bool, reasoning: dict, evidence: dict)"""
checks = [
self.check_regime(proposal, context),
self.check_leverage(proposal, context),
self.check_capital(proposal, context),
self.check_drawdown(proposal, context),
]
# All gates must pass (AND logic -- no short-circuit)
allowed = all(c[0] for c in checks)
reasoning = {c[1] for c in checks}
evidence = {c[2] for c in checks}
receipt = {
'proposal_id': proposal.id,
'allowed': allowed,
'gates': reasoning,
'evidence': evidence,
'timestamp': time.time(),
}
self.log_receipt(receipt)
return allowed, reasoning, evidence
```
Notice there is no short-circuit logic. Every gate runs on every proposal. This is slower, but it preserves complete evidence. You always know what every gate decided, not just the first gate that fired.
Gates vs. Constraints
A constraint solver evaluates declarative rules and rejects invalid inputs. This is useful for form validation and API input sanitization.
A governance gate does something different: it evaluates the context -- system state, operating environment, historical performance -- alongside the proposal, and decides whether execution is aligned with policy given current conditions.
A constraint says: "Numbers above 1000 are invalid."
A governance gate says: "If current drawdown exceeds 3%, no new positions, even if the proposal is well-formed and the model is highly confident. The system is already under stress."
Constraints are static conditions on the proposal. Gates are adaptive evaluations of the proposal within context. When circumstances change, the gate's behavior changes without any modification to its code -- because the context has changed, not the rule.
Why Teams Skip This
Adding governance layers feels expensive. You lose the speed of end-to-end execution. You introduce new implementation surface. You have to design, build, and debug deterministic evaluation logic that sits between your model and the world.
The real cost is in the alternative. Operating an intelligent system without structural gates means betting that the model will never hallucinate, never face an edge case the training distribution did not cover, never make a mistake under distribution shift.
This bet fails. Not occasionally. Always, given sufficient scale and time.
You can bet on alignment. You can bet on fine-tuning. You can bet on red-teaming. None of these bets replace governance structure, because none of them operate at runtime, between the model's output and the world's state.
Architecture beats hope.
The Path Forward
If you are building an intelligent system -- an agent, an autonomous platform, a decision support tool -- start with these six steps:
- Define the proposal format: what does a decision look like when it leaves the intelligence layer?
- Enumerate the governance gates: what dimensions of validity are relevant to your domain?
- Implement fail-closed defaults: if a gate cannot decide, the answer is no.
- Log everything: every proposal, every gate evaluation, every authorization decision.
- Make gates testable independently: unit-test each gate; integration-test the pipeline.
- Monitor gate behavior: which gates reject the most proposals? Are those rejections correct in retrospect? Tune accordingly.
This is not a feature you add later. This is the foundation. Intelligence proposes. Governance authorizes. Execution is logged. That separation is what makes an intelligent system safe by construction rather than safe by hope.