Skip to content

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.

In brief
The problem

verified

Every claim this passage rests on has been checked against its sources.

  • "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."

    verified. Railway engineering history; long settled and uncontested.

Open the complete evidence in the structured publication.

Hard constraints on a system built around a language model tend to be written as instructions to that model, which makes the model both the bound party and the enforcer.
The mechanism

verified

Every claim this passage rests on has been checked against its sources.

  • "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."

    verified. Our own guardrails document, read from the record before authoring. A statement about what our documents specify, not a measured outcome.

Open the complete evidence in the structured publication.

An instruction is evaluated by the thing it constrains, so 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.
The move

position

This is the publication's stated position, not an empirical claim. It rests on the argument rather than graded evidence.

Open the complete evidence in the structured publication.

Split observation from decision, re-run every safety check on the authority that owns the outcome regardless of what the client reports, and put the invariants that must never break into constraints and triggers underneath the application.

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
  1. 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
  2. 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
  3. 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
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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

Read next

Or survey the topics.

Concepts in this piece 1

Add to the work

Contribute to Unable, not instructed

Write the useful part. Identity, provenance, and review history are attached when you submit. The published source stays unchanged.

Target Unable, not instructed

Contribution intent
Use an agent instead

The interface is ready. Public authenticated intake remains off until the hosted migration and feature flag are deployed together.