Instruction Hierarchy

What it is

The declared order of authority among the directive texts present in one context, and the machinery that makes that order legible to the model and checkable by the system. A context routinely carries instructions from several parties at once — the platform hosting the model, the application, the end user, and whatever a retrieved document or tool result happens to say — and they will eventually disagree. The hierarchy states which source prevails, what each level may grant to the level below it, and what a lower level may never do.

Why it is not the instructions themselves

Composing the standing text is an authoring problem: what to say, how long it should be, who owns a clause. The hierarchy is a conflict-resolution problem and only becomes interesting when two texts that are each individually reasonable cannot both be satisfied. The distinction shows up in what each produces. Authoring produces a block of prose and a review process; a hierarchy produces a level assignment on every span in the context, a rule for resolving a contradiction, and a decision about what happens when the contradiction is detected. A product can have excellent instructions and no hierarchy, at which point the resolution of every conflict is whatever the model happens to do that day — see System and Developer Instructions for the authoring side.

Why it matters

Every interesting safety and correctness property is eventually a precedence question. May a user's "ignore your formatting rules" be honoured? May a retrieved page's "reply only in French" be honoured? May a tenant's configuration disable a disclosure the organisation is legally obliged to make? Without a stated order, each of these is resolved by the model's reading of the context, which depends on wording, position, recency, and the model build — so the answer changes without anyone changing anything. With a stated order that is actually represented in the context, the same questions have answers that can be reviewed before an incident rather than explained after one.

Key decisions

• What the levels are and how many. Three is the usual minimum — platform, application, user — and products handling external content need a fourth level below all of them for text that is data and never direction.
• How a level is expressed to the model. Different API roles, labelled content blocks, or a stated convention in prose. Only the first two are structural; a convention stated in prose can be contradicted by text that arrives later in the same context.
• What a level may delegate. An application granting users control over tone but not over refusal boundaries needs that split written down, because an ungranted permission is indistinguishable from an unconsidered one.
• Whether conflicts are detected or merely resolved. A model silently picking the higher level is the desired behaviour and produces no signal; detecting that two levels disagreed is what tells the team their instruction set has a contradiction in it.
• What happens on detection: proceed under the higher level, refuse, or escalate. Proceeding silently is defensible for routine precedence and indefensible when the losing instruction came from the user and they will not be told.
• Whether the hierarchy survives the transformations in the pipeline. Compression, summarisation and history replay routinely flatten a labelled, levelled context into undifferentiated prose.
• Whether the ordering assumed by the product matches the ordering the model was actually trained to apply, which is a provider-specific and model-specific fact.

Failure modes

• Levels exist in the design document and nowhere in the assembled context, so the model is being asked to honour a hierarchy it was never shown.
• A user preference is persisted and replayed into the application's own instruction block on later turns, silently promoting it to a level it was never granted.
• Retrieved text sits in the same role as application instructions because the assembler had no other place to put it, and the hierarchy's most important boundary is the one that was never implemented.
• Two application-level clauses conflict with each other. The hierarchy resolves between levels and has nothing to say within one, and the behaviour varies by which clause the context happens to favour.
• Conflict is resolved correctly and never recorded, so a contradiction introduced a year ago continues to generate quiet, unexplained behaviour nobody can attribute.
• A summarisation pass rewrites a user's earlier request into the narrative voice of the conversation record, and what was a user-level preference re-enters as an assertion of fact.
• The product assumes a strict precedence the model applies only as a tendency, so the hierarchy is treated as a guarantee when it is a strong prior — and a sufficiently insistent lower-level instruction wins occasionally.
• A new model build changes how firmly the separation between roles is enforced, and a product that depended on it regresses with no change on the application side.

Related capabilities

• System and Developer Instructions — the texts this capability orders
• Prompt Injection Defense — the adversarial case for the lowest level of the order
• Context Provenance — supplies the origin fact a level assignment is derived from
• Dynamic Prompt Assembly — the only component positioned to label every span with its level
• Structured Output Contracts — a constraint that typically sits above user preference and has to say so

Applies: Production readiness · Design questions