Three sentences about tone. A vague instruction about format. A reminder not to hallucinate, as if asking nicely were a control mechanism. That is the familiar shape of a system prompt, and you can tell exactly what the author was worried about the day they wrote it — and nothing about what the system is supposed to do once that worry has passed.
More than a dozen instruction files run this practice, one per active workspace, several of those splitting further into their own sub-project files. Each is read in full at the start of every session and rewritten the moment a mistake surfaces a rule that wasn’t there yet. Line them up side by side — a product build, a care-coordination app, a family caregiving tool, a publishing operation — and the topics have nothing in common. The structure underneath does. Read enough of these files and the same four components keep showing up, present or missing, regardless of domain:
Knowledge — what’s true in this domain that doesn’t need re-deriving every session.
Prohibition — what the system must never do, stated in a form that actually holds.
Surfacing — what the operator doesn’t know to ask for, volunteered without a prompt.
Handoff — when the system stops acting and hands the moment back.
Four distinct components.
The reason it’s four and not one, or forty: each layer fails in a different way when it’s missing, and the fix for one doesn’t repair another. More context can’t supply a trigger the system was never told to watch for. A stronger prohibition can’t close a task that’s already been handed to someone else. A rule about when to stop can’t tell the system a fact it was never given. Diagnose a system failure by asking which of the four it belongs to, not by adding another sentence to whichever layer already exists.
Knowledge
This is the layer everyone builds. A directory of facts that would otherwise get re-explained every session: which timezone the operator is in, and which UTC offset that resolves to this week; which correspondence channels are attorney-led and therefore off-limits to drafting entirely; what publishes on which day; who the recurring people are and what role each one plays. None of this is judgment — it’s just true, and a system that has to re-derive it from context every time is spending its first several exchanges figuring out what a five-line file could have told it for free.
Knowledge alone produces a system that’s accurate about the world and has no opinion about its own behavior in it. It’s also the least novel of the four — most serious prompt-writing already does this part. The files in this practice did not become reliable by stopping there.
Prohibition
The obvious version of this layer is a list: don’t do X, don’t say Y, never use these words. Across four unrelated systems in this practice, that version kept failing in a specific way, not a vague one. Writing an exclusion directly into a matching system’s own field — “what this is not” — increased how strongly it matched the very case it was meant to rule out. A set of content-generation rules that banned patterns by naming them failed to suppress those patterns; instructions that said what to produce instead did. A review rubric had to ban a judgment word even in its negated form, because the negated version still read as the judgment to whoever — or whatever — was scoring against it. And a recurring flaw in prose only stopped when the offending move was deleted and rewritten, never when the instruction said not to make it.
Two things held instead, and they’re not the same thing. A positive instruction replaced the excluded move with the behavior the system should produce instead. A mechanical gate checked the output itself and blocked the excluded case categorically, rather than relying on the model to observe a prose instruction. Prose guidance, positive or negative, can still make a system less likely to produce something. It cannot, by itself, make a system unable to. Where the boundary genuinely has to hold, the enforcement lives outside the prompt, in whatever checks the output before it ships — the instruction file can state the rule, but stating it is not what makes it hold.
Surfacing
Most instruction files skip this layer entirely, because it isn’t a response to anything — it’s the system volunteering something the operator didn’t ask for. A rule that says: when a new person shows up who matters enough to track, ask for their contact information before the session ends, unprompted. A standing instruction to check, before a significant decision, whether a different part of the operation already solved an adjacent version of the same problem — and to say so in one sentence, with a date, only when it’s genuinely relevant. The value isn’t in the answers this produces. It’s that the operator wouldn’t have thought to ask the question that produced them.
Handoff
The sharpest example in this layer isn’t about what the system refuses to do. It’s about what it stops tracking. Once responsibility for something has been explicitly handed to someone else, it has to disappear from the list of things the operator is asked to act on — not deprioritized, gone, until the other party re-engages. Get this wrong and the system doesn’t just nag; it teaches the operator that its flags aren’t reliable, because it keeps raising something as unfinished long after the operator correctly stopped tracking it. That’s a trust failure, not a missing feature, and it’s the kind of thing you only learn by running a system long enough to watch it happen.
A second, related but distinct example: some categories of communication go through exactly one channel — a professional, a specialist, whoever owns that relationship — and the system’s job is to produce nothing resembling a draft of it, not a paraphrase, not “here’s roughly what I’d say.” The two examples answer the same underlying question — where does the system’s authority end? — but in different senses. One closes a channel it should never have opened. The other closes a loop it opened correctly and then has to know to let go of.
The name
Call the structure the Instruction Stack: an instruction file built from Knowledge, Prohibition, Surfacing, and Handoff, each layer failing in its own specific way when it’s missing. This is not the same claim as this practice’s existing concept of Governance — the framework holding that structural constraints prevent drift and accumulate commitments rather than just records, across an entire operation. Governance is the umbrella. The Instruction Stack describes what a persistent instruction file contains when that governance is expressed through this kind of operator system. Not everything governance requires lives in the file — some of it lives in mechanical gates, task state, or application logic that sits outside the prompt even when the prompt is the thing that states the rule. A single real situation can touch more than one layer at once: which correspondence channel is attorney-led is Knowledge; the instruction not to draft it is Prohibition; the act of routing it back to the attorney is Handoff. The layers classify what kind of work an instruction is doing, not what subject it concerns.
Most public system-message frameworks organize instructions by message precedence or by categories such as role, scope, safety, tools, and data. The Instruction Stack makes a different cut: it classifies instructions by the operational failure that appears when their function is missing. A system can have excellent tone-and-scope phrasing and still have no Surfacing layer at all.
The Honest Part
This structure was extracted from one operator’s persistent instruction files, re-read every session over months — not from a controlled comparison of one-layer prompts against four-layer ones on any measured task. The account is n of one, and it says nothing yet about the proportions or enforcement mechanisms a single-shot system prompt might need: no persistent file, no re-reading, one chance to establish behavior for one conversation.
There’s a harder version of that limitation worth stating plainly: these four may describe the shape of one persistent, multi-domain, operator-assistant system rather than the shape every effective instruction system needs. A tool with no ongoing operator relationship may have nothing for Surfacing to do. A narrow, single-turn transformation task may need no Handoff beyond refusing what it can’t do. A broader sample, across more operators and more system shapes, might show that Knowledge and Prohibition generalize while Surfacing and Handoff turn out to be specific to systems built the way this one is — not universal layers at all. That’s the real risk to this framework, not an unanswered implementation detail.
What can be said with more confidence is narrower and still useful: when a system misbehaves, the first diagnostic question worth asking isn’t “what should the prompt say instead.” It’s which of these four the failure belongs to — because a missing fact, an unenforced boundary, an absent trigger, and an authority that never ended each get fixed by building a different thing, not by adding another sentence to the same wish list.
How this was made: drafted in working sessions with Claude, revised across three adversarial rounds I read and scored myself. The judgment — what’s true, what’s cut, what ships — is mine throughout, including this line.
Robert Ford builds products, writes stories and essays, and publishes The Intelligence Engine — a practitioner research publication about AI systems that compound. His other writing lives at Brittle Views.