The Coherence Problem
Intelligent systems tend to come apart as they scale, and the failure modes are predictable.
More components means more conflict. One engine signals buy, another sell, a third hold. With nothing to arbitrate, the system thrashes, burning resources to argue with itself and producing incoherent behavior.
More autonomy means more room for local optimization to drift from global intent. One subsystem optimizes for speed, another for accuracy, a third for cost. Each is right locally. Globally the system pulls in three directions and achieves none of them well.
More interfaces means more places where assumptions break in silence. Component A expects data with certain properties. Component B emits data that violates them. The system degrades gradually, with no clean error, until it fails in a way no one can trace.
Intelligent systems are not immune to any of this. They are more exposed, because the failures are subtle. The system is still running. It has just stopped doing what you designed it to do, and without explicit governance you may not notice until the damage is real.
The Three Layers
The WHL approach to governed intelligence at scale rests on three layers with clear, non-overlapping responsibilities.
Layer one is perception and proposal: the intelligence layer. Signal engines, planners, recommendation components. They observe the world and generate candidates for action. They do not decide whether to act. Their job is to notice patterns and propose responses, with reasoning attached.
Layer two is governance and authorization. It evaluates proposals against policy, current state, and hard constraints. Is the proposal consistent with operating conditions? Does it break a non-negotiable rule? Are we inside the risk budget? Does the evidence support the action? Gates live here. The layer's output is binary: yes or no, with a logged reason every time.
Layer three is execution and logging. An authorized proposal goes to execution, and execution generates a receipt: the full context of what was proposed, why, which gates it cleared, the decision, the outcome. The receipt is the primary artifact of execution. Not a log file. The artifact.
The layers are genuinely separate. Different subsystems implement them. Different testing strategies apply. Perception can be probabilistic and experimental. Governance must be deterministic and precise. Execution must be reliable and complete in its logging.
Coherence Through Separation
Separate these layers and coherence stops being something you enforce through constant coordination. It becomes a structural property.
The proposal layer cannot decide. It can only propose, which forces it to articulate its reasoning. A component that cannot explain why it is proposing something cannot propose it at all. That is a free quality filter, a side effect of the architectural constraint.
The governance layer cannot optimize for anything but consistency with policy. It judges every proposal against criteria that do not bend to the proposal's content. The same gates apply to all of them. The layer is impartial by construction, not by good intentions.
The execution layer cannot interpret. It runs what it is authorized to run, which removes the gap where a system decides to do something slightly different from what was approved. Authorization and execution are coupled with no daylight between them.
And because the layers talk through explicit interfaces, assumptions cannot stay implicit. Perception cannot quietly assume governance will accept certain reasoning; it has to express the reasoning as part of the proposal. Governance cannot change execution without updating the authorization. Each layer's assumptions about the others live in the interface, not in someone's head.
Building the Governance Layer
Governance is the most important layer and the one most often skipped. Teams build smart perception, add execution, skip governance, and call the result autonomous. Then they are surprised when the system behaves incoherently under conditions perception never anticipated.
Governance starts with policy: the explicit rules that define acceptable behavior. Not guidelines, not preferences. Rules. Hard constraints on what the system may and may not do.
In trading they look like this: never exceed position-sizing bounds, never trade past the daily loss limit, never hold certain assets past certain conditions. These are not suggestions weighed against the objective. They are structural limits.
Policies become gates. Each gate is a deterministic yes-or-no check that returns the same output for the same input, every time. Gates can be parameterized. The position-sizing gate checks against a threshold set during calibration; the threshold can move, the gate logic does not. A proposal reaches a gate, the gate evaluates, pass or fail. All required gates pass, authorization is granted. Any required gate fails, authorization is denied and logged with the reason.
The hard part is calibration. Too strict and you suppress good proposals. Too loose and you admit bad ones. But this is a measured problem. You can see which gates close most often, which closures correlate with good outcomes avoided versus bad outcomes prevented, and adjust on data.
Designing Proposals
Proposals must carry their reasoning. A bare request, "buy X," is not a proposal. A proposal specifies the action, the why (the signal and threshold that triggered it), the proposing component's confidence, and any constraints on execution: slippage limits, time windows, risk bounds.
The structure serves governance. To evaluate a proposal, governance has to answer whether the reasoning is sound given what is known, whether the confidence is sufficient for this class of action, whether the proposed execution window introduces risks it should know about. Without structured proposals, governance is deciding with incomplete information.
Structured proposals also impose discipline on perception. Components that cannot articulate their reasoning tend to generate worse proposals, and the requirement to express reasoning surfaces those design problems early.
Execution and the Receipt Chain
Execution generates receipts. Each receipt is a complete record: timestamp, proposal, gates evaluated with pass or fail for each, the authorization decision, execution details, outcome. When a position closes, the receipt is updated with exit price, hold duration, realized result, exit reason.
Over time the receipt ledger becomes the system's primary source of truth about its own behavior. Not documentation. Evidence.
With that evidence you can ask questions the system could not otherwise answer. Which proposal types tend to produce good outcomes? Which gate combinations best predict eventual success or failure? Are there correlations between proposal characteristics and outcomes that should inform how governance weights its checks?
This is how the system improves without retraining perception. Perception keeps proposing. Governance updates its calibration on measured outcomes. The architecture learns through its logs.
Scaling Without Incoherence
The structure scales without the coherence failures that plague monoliths.
Add more perception components and governance does not grow proportionally more complex. Gates are reusable. The position-sizing gate applies to every proposal involving position sizing, whatever engine produced it. Capital conservation applies universally. You add new engines freely.
Bad perception components are harmless. An engine generating poor proposals has them rejected by governance. It causes no damage; it is simply ignored. That is liberating, because it means experimental engines can run alongside proven ones. The experiments sink or swim on proposal quality. Sink, and governance quietly rejects them. Swim, and governance authorizes them, and now you have evidence to promote them.
When a new failure mode emerges, you add a gate. The gate is general: it applies to all proposals, not only the ones that revealed the failure. One addition raises the safety of the entire perception layer at once.
Measuring Governance Health
You need metrics for how well governance is working. Three matter most.
Passage rate: what fraction of proposals clear all gates and reach execution? Very high, and governance may be too loose. Very low, and it may be too strict, starving the system of actions it should be taking. The right level depends on domain and risk tolerance, but you want the number and you want to track it.
Gate-level rejection distribution: for each gate, how often is it the one that closes on a failed proposal? This tells you which constraints bind. If one gate rejects most proposals, ask whether it is calibrated correctly. If a gate almost never fires, ask whether it tests a real constraint or a theoretical one.
Coherence rate: how often do proposals from different components contradict each other? One engine proposing long and another proposing short on the same asset at the same moment means perception has not reached a coherent view. Governance can resolve the contradiction, but a high contradiction rate is a signal to fix the perception architecture, not just arbitrate it.
The Build Order
Start small. One perception component, one set of gates, one execution environment. Get the layering right. Get the logging right. Confirm the receipt chain is complete and trustworthy.
Then scale perception. Add engines, data sources, experimental signals. Governance does not change. Execution does not change. You are expanding perception inside a governance container that is already solid.
That is the build order that produces governed intelligence which stays coherent as it grows. Not coherent by accident. Coherent by structure.