Enforcement configurations
One appliance. Three ways to make sure.
All three configurations are designed to terminate in the same non-bypassable hardware interlock. Today, Mode B ships as software with deterministic, by-construction guarantees inside the software trust boundary; Mode A ships as measurement and governed routing while its enforcement signal is validated. The hardware rung is where both modes' guarantees stop depending on trusting privileged software.
Three configurations of one appliance
Shown as a mode, never as three products.
Ships now. The verdict is a decidable accept/reject: output either conforms to the attested formal policy or it does not. Deterministic, reproducible, certifiable.
Certifying. Calibrated detection lanes carry a certified miss-rate α at confidence δ over a named corpus, revalidated on interface, model, drift, or calendar triggers.
Under experiment. Divergence in embedding space as a governance signal; the distance-tracks-compliance premise is being reduced to practice and is shown as experimental wherever it appears.
This page · where it acts
The two modes, A semantic and B structural, answer where enforcement acts.
The other lens · how strong is the proof
The three appliances, rules · distribution · meaning, answer how strong the proof is, and what ships. See the ladder →
Mode A · Semantic constraint
Check what an action actually means.
Checks each consequential action against an envelope of acceptable meaning and exposure declared in advance. The interlock physically refuses to actuate outside it, and governs the book, not just the single decision, so locally-compliant choices can't compound into an aggregate no one chose.
The question it answers
"Does this decision stay inside what we declared, and can I prove it?"
- Acts at the boundary where a recommendation becomes an irreversible action.
- Constraint expressed in the organisation's own terms, mandate, policy, exposure limits.
- Governs any frontier model, because it sits beneath the model at the point of actuation.
- Tamper-evident proof that the action was admitted under the declared envelope.
Best for banking, energy, insurance, retirement and industry, anywhere capital sits behind an automated decision.
Mode B · Structural constraint
Make a banned output impossible to produce.
Checks output against a formal rule, a schema, an enumerated command set, a safety grammar, as it is generated, one step at a time. A non-conforming output is never produced rather than produced and caught: the interlock prevents it in the datapath, so no privileged software can let it through.
The question it answers
"Is this output structurally incapable of breaking the rule, and can I prove it did?"
- Acts inside generation, where the output is formed, not after it has left.
- Constraint expressed as a formal grammar, valid structured output, a fixed command vocabulary, a safety automaton.
- Prevention is a property of the hardware, not a software check that can be removed.
- Per-output proof that the sequence was generated under an attested, unmodified rule.
Best for regulated and safety-critical settings where output must be provably well-formed, structured records, command interfaces, certified pipelines.
What all three configurations share
Three configurations, one appliance, not three products.
Non-bypassable in hardware
Enforcement biased to block by default. No software process, at any privilege level, can release it without a valid attestation.
One attestation root
The same hardware root of trust verifies that the governing artifact, envelope or grammar, is the one declared, and unmodified.
Proof anyone can check
Every governed event emits a tamper-evident artifact, evidence a regulator or counterparty can verify without trusting the operator.
Which mode
Pick by the question you have to answer.
Where each configuration fits
All three configurations run on the same appliance; they differ in where that appliance sits relative to the model. Semantic governance works wherever the appliance sees the action before it actuates, including models reached through an external API, which is why it governs any frontier model from beneath.
Structural governance acts during generation, so it fits deployments that run inline with the model, on-premise, self-hosted, or appliance-integrated estates where the generation path is yours to govern. For most regulated and safety-critical buyers, that is already where the model runs.
What's real at each rung
One design, compared honestly in three columns.
Not sure which mode your problem needs?
Most institutions need one to start and the other before long. Tell us the decision or output you have to stand behind, and we'll map it to a mode.
Talk to us →