Context Engineering and Prompt Management

Context Engineering and Prompt Management

Instruction Hierarchy — Patterns

Instruction hierarchy › Patterns

35 of 57 in this book · 3 min read

Level assigned at admission, never inferred later

Problem. By the time the context reaches the model, every span is text. Working out which level a paragraph belongs to from its content is guesswork, and it is exactly the guess an adversary wants the system to make.

Approach. Attach the level at the moment a span enters the assembled context, from the producer that supplied it rather than from anything in the span itself. A retrieved passage is data because retrieval produced it, not because it looks like data. Carry the label as a structural property, and make the assembler refuse to admit a span with no level rather than defaulting one.

Trade-off. Every producer must now declare a level, including the ones written before the hierarchy existed, and a wrong declaration at the source propagates everywhere with full confidence. The refusal to default also breaks any path that was quietly adding content without going through the assembler, which is the point and is still disruptive.

Delegation as an enumerated grant

Problem. "The user may customise the assistant's behaviour" is a sentence that sounds like a policy and decides nothing. In practice each request to honour a user preference is resolved by whoever is implementing it that week.

Approach. Express what a higher level permits a lower one to influence as an enumerated list of parameters with allowed ranges — tone, verbosity, language, the format of a list — rather than as prose. Lower-level text is then mapped onto that parameter set before it reaches the model, and anything outside it is carried as a stated request the model may acknowledge but not act on.

Trade-off. The list is always behind what users want, and every addition is a small policy decision, so the mechanism generates a steady stream of requests. Mapping free text onto parameters also needs a step of its own, which is one more place for an adversarial instruction to be read as a preference.

Conflict detection as a separate signal

Problem. When precedence works, nothing happens — the higher level simply wins. So a contradiction between two instructions can sit in the product for a year, producing behaviour nobody ordered, with no trace of it anywhere.

Approach. Run a cheap check for directive language in lower-level spans that targets the same subject as a higher-level rule, and emit a counter when one is found, independently of how the model resolved it. Treat a rising rate on a particular rule as evidence the instruction set needs an edit, and sample the detected cases for review rather than acting on them automatically.

Trade-off. Detection on text is noisy in both directions: it fires on quoted examples and harmless restatements, and misses conflicts expressed obliquely. It also costs a scan of the context on every request, and the signal is only valuable if somebody is funded to read it.

Enforcement moved to the action boundary

Problem. The hierarchy is a statement about what the model should do, and the model's adherence is strong but probabilistic. Anything with a real-world effect cannot rest on a prior.

Approach. For every rule whose violation matters, find the point where the violation would become an effect — a tool call, an outbound message, a write — and enforce it there with a check that does not involve the model. The context-side hierarchy then carries the rules that are about wording and emphasis, and the action-side check carries the rules that are about consequence.

Trade-off. It splits one policy across two implementations that drift apart, and the action-side check sees only the action, not the reasoning that led to it, so it rejects some legitimate requests and cannot express rules about how an answer is phrased.