Context Engineering and Prompt Management
Instruction Hierarchy — Stack
Instruction hierarchy › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
The hierarchy has to be expressed in something the model actually distinguishes, and enforced by something that is not the model.
- Structural expressiveness. How many distinct, model-visible levels the target inference API offers, and whether content can carry a trust attribute rather than only a role.
- Trained behaviour versus convention. Whether the provider states that the model is trained to prefer one role over another, or whether the separation is purely your convention.
- Portability. Whether the same level assignment maps onto every provider in use. Role vocabularies differ, and collapsing two levels during a migration is a silent policy change.
- Delegation modelling. Whether grants from one level to the next can be stated as data rather than as prose that the model has to interpret.
- External enforcement. Whether anything outside the model can refuse an action that a lower level requested and a higher level forbade, since the model's compliance is a prior and not a control.
- Conflict visibility. Whether a disagreement between levels can be detected and emitted as a signal rather than being resolved invisibly.
- Survival through the pipeline. Whether level labels persist through history storage, summarisation, and replay, or are flattened at the first transformation.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Native message roles (system, developer, user, tool) on the inference API | The baseline separation every product should use, since it is what the model was trained on | Role sets and their stated precedence differ per provider; a role that exists on one API has no equivalent on another |
| Typed content blocks with per-block metadata | Distinguishing data from direction inside a single message | Metadata is rarely trained on; the model sees structure, not semantics, unless the convention is also stated in the instructions |
| Published behaviour specifications (OpenAI Model Spec and comparable provider policy documents) | Understanding what the platform level already asserts before you design on top of it | These describe the provider's intent, not a guarantee; they change between model releases |
| Policy engines over model-requested actions (Open Policy Agent, Cedar, in-house authorisation) | Making the hierarchy enforceable where it matters — at the point an action is taken | Enforces on actions, not on text, so anything that is purely a wording or disclosure rule stays unenforced |
| Guardrail frameworks (NeMo Guardrails, Guardrails AI, provider-side moderation hooks) | Expressing some precedence rules as checks that run independently of the model's compliance | Overlaps heavily with runtime safety tooling; precedence logic split between two systems is hard to reason about |
| Prose-stated precedence inside the instruction block | Products on APIs with only one instruction channel | The statement is itself text in the context and can be argued with by later text; the weakest available option |
| Separate calls per trust level | Cases where the separation must be structural rather than advisory | Not a hierarchy so much as an avoidance of one; costs a round-trip and loses the ability to reason across levels |