Incentives · research february to july 2026 · published 2026-08-03 · v1 · 3 min read
Unable, not instructed
A rule the model is asked to remember is a rule enforced by the party it binds
Three places we put hard constraints below the model rather than inside its prompt, from a deterministic phase evaluator to a database trigger, and why the difference from a well-written instruction is categorical.
British railways solved this in the 1850s, on a network where the enforcing party was a man in a box with a row of levers. A signalman could be perfectly trained and still, on the one wet evening that mattered, clear a train onto a route whose points were set for another. John Saxby patented mechanical interlocking in 1856 and it went into service at Bricklayers Arms Junction the same year, and what it did was not remind the signalman of anything. It connected the levers to each other with bars and locks so that contradictory signal and point settings were physically impossible to select. The lever for the conflicting route would not move. The instruction had been replaced by a shape, and the whole of modern signalling descends from that substitution.
Our own guardrails document states the equivalent in one sentence, and it is the sentence the rest of the architecture is built to make true. The model is never asked to remember hard rules, and is instead made unable to violate them. The distinction is not a matter of degree from a firmly worded prompt, because an instruction is evaluated by the thing it constrains, which means a hard rule delegated to a model depends on the compliance of the party it binds, and relocating the rule somewhere the model cannot reach is the only change that removes the dependency.
It shows up three times, at three depths. The first is the phase evaluator. A budget-tier model reads the conversation and produces numeric signals, engagement and risk and readiness, and that is the whole of its authority, because the decision about whether a phase may advance is taken by a deterministic condition evaluator that is not a model at all. The architecture’s own rationale for the split is that observation is expensive and fallible while decision is cheap and offline-capable, and the consequence is that phase order, dependency gates, and context isolation live in state machines and permissions rather than in prose anybody has to trust. The second is the crisis check. Client-side agents run one locally to cut latency, and the server re-runs it regardless of what the client reports, on the stated ground that a local agent reduces latency and never holds final safety authority. A client that lies, or is simply out of date, changes the speed of the answer and not the answer.
The third is underneath everything, in the schema. Safety invariants are written as check constraints and triggers, so a tool classed as a sensor cannot be given an irreversible side effect and a record marked immutable cannot be updated or deleted, and the database rejects the write rather than logging a complaint. The design note is blunt about why, holding that buggy application code cannot be permitted to create unsafe states and that the database is the last line of defense. Each layer assumes the one above it will eventually be wrong.
This is the same posture as keeping the frontier model in a subordinate position, argued one level down, and it is the reason the competence ceiling does not apply to the phase evaluator. A model that is right about readiness more often than the deterministic rule is still the wrong place to put the decision, because being right more often is a property of an average and the constraint exists for the tail. We are not claiming the rules are correct, only that they are the kind of thing that can be inspected, tested, and argued about in a review, which a prompt’s behavior under an unseen input cannot. Write the rule where the bound party cannot reach it, and the question stops being whether it will be obeyed and becomes the far better question of whether it is right.
Evidence and lineage
Research trail
Follow the sources, inspect how the claims are graded, or propose a correction at the exact record it concerns.
Sources 3
-
John Saxby (1856). Patent for mechanical interlocking of signals and points, first installed at Bricklayers Arms Junction
The braided precedent, chosen because it replaces an instruction with a mechanism rather than adding a check. The signalman is not reminded of the conflicting route; the lever will not move.
Comment on this source -
MNSTRY platform documentation (2026). Session flow guardrails (internal record of the hard-constraint rule and the deterministic enforcement layer)
The stated principle in its sharpest form, that the model is never asked to remember hard rules and is instead made unable to violate them, together with the list of constraints encoded below the model.
Comment on this source -
MNSTRY platform documentation (2026). Agentic session architecture and database architectural rationale (internal records of the observation and decision split, the server-side safety re-check, and the database-level invariants)
The three implementations. A budget model that observes and a deterministic evaluator that decides, a server that re-runs the crisis check regardless of client claims, and check constraints and triggers that reject unsafe writes outright.
Comment on this source
Claims and confidence 6
- verified
John Saxby patented mechanical interlocking in 1856 and it entered service on the British railway network the same year, making contradictory signal and point settings physically impossible to select rather than merely forbidden.
Railway engineering history; long settled and uncontested.
Respond to this claim - verified
Our session flow guardrails state that the model is never asked to remember hard rules and is instead made unable to violate them, and require hard constraints to be encoded in deterministic logic such as state machines, database gating, and tool permissions.
Our own guardrails document, read from the record before authoring. A statement about what our documents specify, not a measured outcome.
Respond to this claim - verified
The same document lists phase order, dependency gates, intensity caps, and cross-context isolation as hard constraints enforced below the model.
The hard-constraint section of the same document.
Respond to this claim - verified
Our session architecture separates signal extraction, performed by a budget-tier model, from phase decisions, performed by a deterministic condition evaluator, on the recorded rationale that observation is expensive and fallible while decision is cheap and offline-capable.
The design decisions record in our agentic session architecture document.
Respond to this claim - verified
The same record specifies that the server always re-runs the crisis check regardless of client-reported local results, because client-side agents reduce latency but never hold final safety authority.
The same design decisions record.
Respond to this claim - verified
Our database rationale places safety invariants in check constraints and immutability triggers, so that a sensor-class tool cannot carry an irreversible side effect and an immutable record cannot be updated or deleted, on the stated ground that the database is the last line of defense against buggy application code.
The safety-invariant theme and the accompanying constraint definitions in our database architectural rationale.
Respond to this claim