{ "schema": "org-writing@v1", "slug": "unable-not-instructed", "kg": { "id": "org:writing:unable-not-instructed", "type": "brick", "graph": "/kg.json" }, "title": "Unable, not instructed", "subtitle": "A rule the model is asked to remember is a rule enforced by the party it binds", "abstract": "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.", "kind": "brick", "topics": [ "Incentives" ], "courseMemberships": [ { "course": "org:courses:incentives", "topic": "Incentives", "wall": "org:walls:engineering", "position": 5, "total": 6 } ], "publishedAt": "2026-08-03T00:00:00.000Z", "version": 1, "guidelinesVersion": 15, "brief": { "problem": { "text": "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.", "claims": [ "contradictory signal and point settings physically impossible to select" ] }, "mechanism": { "text": "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.", "claims": [ "never asked to remember hard rules and is instead made unable to violate them" ] }, "move": { "text": "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.", "claims": [] } }, "sources": [ { "repo": "mnstry-monorepo", "path": "docs/10-platform/40-architecture/core/therapeutic-flow-guardrails.md" }, { "repo": "mnstry-monorepo", "path": "docs/10-platform/40-architecture/core/agentic-session-architecture.md" }, { "repo": "mnstry-monorepo", "path": "docs/10-platform/50-database/00-principles/architectural-rationale.md" } ], "canonicalPath": "/writing/unable-not-instructed/", "body": "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.\n\nOur 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.\n\nIt 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.\n\nThe 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.\n\nThis 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.", "apparatus": { "note": "The human-facing essay is deliberately practical; this apparatus carries the full references, evidence-graded claims, article-local concepts, and research context behind it. Canonical concept definitions come from the concept registry.", "references": [ { "id": "org:references:unable-not-instructed:r01", "author": "John Saxby", "work": "Patent for mechanical interlocking of signals and points, first installed at Bricklayers Arms Junction", "year": 1856, "relevance": "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." }, { "id": "org:references:unable-not-instructed:r02", "author": "MNSTRY platform documentation", "work": "Session flow guardrails (internal record of the hard-constraint rule and the deterministic enforcement layer)", "year": 2026, "relevance": "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." }, { "id": "org:references:unable-not-instructed:r03", "author": "MNSTRY platform documentation", "work": "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)", "year": 2026, "relevance": "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." } ], "claims": [ { "id": "org:claims:unable-not-instructed:c01", "claim": "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.", "basis": "Railway engineering history; long settled and uncontested.", "confidence": "verified", "sources": [] }, { "id": "org:claims:unable-not-instructed:c02", "claim": "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.", "basis": "Our own guardrails document, read from the record before authoring. A statement about what our documents specify, not a measured outcome.", "confidence": "verified", "sources": [] }, { "id": "org:claims:unable-not-instructed:c03", "claim": "The same document lists phase order, dependency gates, intensity caps, and cross-context isolation as hard constraints enforced below the model.", "basis": "The hard-constraint section of the same document.", "confidence": "verified", "sources": [] }, { "id": "org:claims:unable-not-instructed:c04", "claim": "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.", "basis": "The design decisions record in our agentic session architecture document.", "confidence": "verified", "sources": [] }, { "id": "org:claims:unable-not-instructed:c05", "claim": "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.", "basis": "The same design decisions record.", "confidence": "verified", "sources": [] }, { "id": "org:claims:unable-not-instructed:c06", "claim": "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.", "basis": "The safety-invariant theme and the accompanying constraint definitions in our database architectural rationale.", "confidence": "verified", "sources": [] } ], "concepts": [ { "id": "org:concepts:unable-not-instructed", "name": "Unable, not instructed", "definition": "The distinction between a constraint a model is asked to honor and one it has no path to violate. An instruction is evaluated by the party it binds, so a hard rule delegated to a model depends on the compliance of the thing it constrains, and relocating the rule below the model is the only change that removes the dependency.", "provenance": "canonical" }, { "name": "Last line of defense", "definition": "The placement of the invariants that must never break in the layer furthest from application code, as constraints and triggers a wrong query cannot talk its way past.", "provenance": "local" } ], "researchContext": "The parent essay draws the structural-versus-behavioral line and proves\nit with three moves at the level of a whole system. This brick owns one\ndistinction inside that line, between a rule an actor is asked to follow\nand a rule it cannot reach, and the reason the distinction is categorical\nrather than a matter of degree. The three implementations are ordered by\ndepth on purpose, since the argument is that each layer assumes the layer\nabove it will eventually be wrong.\n\nTwo kinships are cited rather than absorbed. The subordinate model\nposition argues the same posture at the strategic layer, that the engine\nis interchangeable because the guarantees were never in it, and this brick\nargues it at the enforcement layer. The competence ceiling supplies the\ncounter-argument that has to be answered, that a model right more often\nthan a rule is a reason to defer to it, and the answer given here is that\naccuracy is an average and a hard constraint exists for the tail. Neither\nargument is restated at length.\n\nThe interlocking case is braided in rather than cited as authority. Its\none job is to show that replacing an instruction with an inability is a\nsettled answer in a domain where the operators were competent and the\nconsequences were fatal, so the move is not a novel caution invented for\nlanguage models.\n\nEvery internal claim is graded as a statement about what our documents\nspecify. Nothing here asserts that the constraints are correct, only that\nthey are the kind of object that can be inspected and argued about, and\nthe published text says so explicitly. Per the wave's de-identification\nruling, no component identifiers, file paths, table names, or product\nnaming appear in the published body, and the constraints are described by\nwhat they forbid rather than by how they are addressed in the schema." }, "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json", "releaseHash": "70e9b2469ae94d0d4aa8f23f80cddf5c4997a8168290c5f7bc6a856e51020ea5", "versions": [ { "version": 1, "cutAt": "2026-08-03", "note": "Initial publication, incentives wave", "visibility": "published", "path": "/writing/unable-not-instructed/", "contentHash": "sha256:00b40412ea55ac65", "releaseHash": "70e9b2469ae94d0d4aa8f23f80cddf5c4997a8168290c5f7bc6a856e51020ea5" } ] }