The Turing Complete Problem

Software can do anything. That is its strength, and in governance contexts, its fundamental weakness.

A software-based governance gate can evaluate rules, check constraints, and authorize or deny actions. But the code that evaluates those rules is itself software. It can be patched, modified, or circumvented. If the system is Turing complete, any rule can in principle be rewritten, either by a sufficiently motivated actor or by a sufficiently broken process.

This is not paranoia. It is a basic property of computation. A universal machine can compute anything, including a proof that its own rules no longer apply. If the final decision boundary lives inside the universal machine, the boundary is conditional.

The only way to make it unconditional is to move it outside the universal machine. Hardware is the answer.

How a Hardware Interlock Works

An FPGA does one thing: it evaluates a fixed circuit. That circuit cannot be changed without recompiling the bitstream and physically reprogramming the device. A reprogramming event is observable, auditable, and requires physical access to the hardware.

In a governed execution system, the interlock works as follows.

The governance gate, running in software, evaluates whether an action is authorized. If authorized, it produces a signed token: the action type, the relevant parameters, a logical timestamp, a nonce, and an HMAC signature computed with a key that is hardcoded in the FPGA.

The token is passed to the FPGA. The FPGA checks the signature against its hardcoded key. It checks the nonce against its replay-protection register. It checks the logical timestamp for freshness. It verifies that the action encoded in the token matches what the execution capsule is about to perform.

If all checks pass, the FPGA signals proceed. If any check fails, the FPGA signals stop. The execution capsule observes the GPIO line and either acts or halts.

The critical property: the HMAC key is hardcoded. It cannot be extracted from software. It cannot be changed at runtime. Circumventing the interlock requires physical access to the device. No software bug, no compromised dependency, and no malformed input can bypass the check.

Why Software Governance Alone Creates Residual Risk

Consider a concrete failure scenario without hardware enforcement.

The governance gate in software decides: this order exceeds the maximum position size, deny. The denial is returned to the trading algorithm. The algorithm, being software, can introspect its own execution environment. A bug in the governance logic, or a deliberately malicious modification, could cause the algorithm to treat the denial as advisory rather than binding, generate a different code path that skips the gate, or rewrite the denial result in memory before it is acted upon.

With a hardware interlock, none of these paths lead to execution. The governance gate produces no token, so the FPGA receives no authorization signal, so the execution capsule observes a low signal on the GPIO line, and the order does not go to the exchange. The software failure is isolated. The physical action cannot happen without the hardware signal. The FPGA does not know about software bugs. It only knows about tokens.

This asymmetry is the point. Software failures and software exploits operate entirely within the software layer. The hardware layer is orthogonal to them.

The Token Structure

The token is small by design. Compactness is a security property: a larger token has more fields that can be malformed or manipulated.

A minimal but complete token contains: the action identifier, the authorized parameters (size, target, direction), a logical clock value, a unique nonce, and an HMAC over all preceding fields using the key shared only with the FPGA.

The FPGA verifies each field independently. The nonce check prevents replay: a token already accepted cannot be submitted a second time. The timestamp check prevents stale tokens: an authorization that was valid five minutes ago is no longer valid if the epoch has advanced. The action check prevents substitution: a token authorizing a small order cannot be used to authorize a large one.

These checks are simple, individually. Their power comes from the fact that they are evaluated in silicon, not in code that can be patched.

The Tamper-Evident Audit Trail

When a token is accepted by the FPGA, the FPGA logs the acceptance event to non-volatile memory. The log is append-only. It records the token hash, the logical timestamp, and the action type. It cannot be modified without physical access to the storage, and any modification attempt is detectable through the receipt chain.

This audit trail has a property that software-only logs cannot provide: it is physically decoupled from the system that generated the authorizations. Even if the software governance layer is compromised entirely, the hardware log is an independent record of what was actually authorized to execute.

Cross-referencing the hardware log with the software execution ledger gives you two independent chains of evidence. Discrepancies between them are anomalies that demand explanation. An authorization in the hardware log with no corresponding execution in the software ledger suggests a capsule failure. An execution in the software ledger with no corresponding hardware log entry suggests a serious integrity problem.

A Second Boundary: Thermal State

In the WHL architecture, a second interlock monitors the system's entropy budget, the accumulated risk load across a time window.

The Enable Equation includes a thermal gate: the system tracks how much "risk energy" it has expended relative to its declared budget. If that budget is exhausted, the thermal gate closes, and the FPGA will not authorize further execution until the budget recovers.

This boundary is important because it prevents compounding. A software-only system can fail repeatedly in rapid succession, with each failure justifying the next action in an attempt to recover. The thermal interlock enforces a physical cooldown. Even if the software logic argues that more action is warranted, the hardware disagrees, and the hardware wins.

The mechanism enforces what the WHL architecture calls the entropy budget: risk is a finite resource, and the governance layer must respect that constraint whether the cognitive engine believes it should or not.

Honest Limits

Hardware enforcement is not a complete solution to governance. It is a constraint on one specific failure mode.

Hardware cannot prevent bad authorizations from being generated. If the software gate approves a bad action, the FPGA will execute it. The hardware enforces that the authorization is authentic. It does not enforce that the authorization is correct.

Hardware cannot prevent policy changes. If the governance team decides to raise position limits or add new action types to the token vocabulary, those changes will be enforced by the new hardware configuration. The hardware is only as good as the policies encoded into it.

Hardware cannot prevent physical attacks. Someone with physical access to the device can reset or reprogram it. Physical security of the hardware is a separate requirement.

What hardware enforcement does, and does absolutely, is prevent circumvention. Once a policy is encoded in silicon, that policy holds for every action, every time, regardless of what is happening in software. There are no runtime overrides. No emergency bypass. No "just this once" path.

Where the Trust Boundary Sits

The purpose of a hardware interlock is to locate the trust boundary correctly.

In a software-only system, you must trust the entire stack: the cognitive engine, the governance gate, the execution capsule, the operating system, the runtime, and all of their dependencies. A failure anywhere in that stack is a failure in the trust model.

With a hardware interlock, you must trust far less. The cognitive engine can be complex and occasionally wrong. The governance gate can have bugs. The execution capsule can misbehave. As long as the governance gate produces valid tokens when and only when it should, execution is safe. And if the governance gate fails to produce a token, execution does not happen.

This is the difference between a system that is safe by hope and a system that is safe by construction. Safety by hope relies on every component behaving correctly. Safety by construction relies on one simple, verifiable, silicon-enforced property: no token, no action.

For systems controlling real capital or real resources, the construction-based approach is not a premium option. It is the baseline.