Order Changes Meaning

Here is an invented illustration, not an incident. A harness team ships a minor upgrade. Nothing is added or removed from the collection of context items. The release notes mention only a rendering change: tool results now appear above the project rules instead of below them. Suppose the team’s deployment-safety rule, which the agent had followed for months, then starts being violated. The items’ text is unchanged, but their sequence differs, and the team’s observed behaviour changes. That would justify investigating an ordering regression; it would not yet establish that the move caused the violation, or which changed relationship mattered. The team would need a controlled replay to separate a real layout effect from model variability and other differences between runs.

The title is shorthand. Moving text does not change what any item says. It changes the relations among items, and with them how the bundle is used. This chapter asks what ordering controls, and the answer is larger than position.

Context is a sequence

A context bundle is not merely a set of information from which the model draws what it needs. At the level of an assembled, ordered representation, write it as C = (c₁, c₂, …, cₙ), where each cᵢ has content and relevant boundaries or metadata. Two bundles with identical items in different sequences are different context conditions, even if the words are unchanged. This formalisation describes the observed or compiler-produced sequence, not a claim that the provider preserves every boundary or renders the same sequence downstream. Order is part of context identity:

same items ⇏ same context

That is the chapter’s formal claim. Everything else in it is about what varies when order varies, and how to keep from mistaking one thing for another.

What order can vary

“Order” covers several concerns of different kinds. Four are relations among rendered items. Two more interact with order without being properties of it.

The six concerns are related but not interchangeable. Position, adjacency and grouping describe relationships in a particular rendered layout. Temporal sequencing is a policy for ordering items that refer to events or states over time. Precedence is a rule about which instructions govern, not a location in the sequence. Stability is a relation between invocations that can have caching consequences; it is not itself a price or a behavioural benefit.

Position. Where an item falls in the rendered sequence. The direct evidence is Lost in the Middle, reviewed in Chapter 5: in tested QA and key-value retrieval, performance depended on where relevant information appeared even though it was present. That is a controlled result on those tasks. Position in agent-shaped bundles is a book hypothesis, and this chapter does not claim otherwise. Broader long-context results on length, task complexity or lexical overlap are not position evidence and are not used as such.

Position rarely varies alone in an ordinary rearrangement. Moving an item can change its absolute and normalised position, its distance from the current request or related evidence, its neighbours, its group membership and the matching prefix across invocations. Message roles and boundaries, however, change only if the rendering operation also changes them; a within-message reorder need not. A position experiment is interpretable only to the degree that accompanying differences are held fixed, counterbalanced or explicitly reported. Some distances cannot be independently held fixed under a particular layout, so those effects remain confounded.

Adjacency. The rendered distance or neighbourhood relationship between items expected to be used together: a tool call and its result, a claim and its evidence, a rule and the operation it constrains, an example and its query. It is measurable as token distance, item distance and the number of intervening group boundaries. The hypothesis is that increasing the separation between dependent items may reduce successful joint use. That is a candidate to test. Chapter 5 removed mechanism claims about interference, and none is made here.

Grouping. Related items are grouped when they are rendered contiguously or under a shared structural container or label. Possible benefits include a shared heading, less separation and predictable location, and none is a measured result. Chapter 5 recorded a result that blocks a universal rule: in Chroma’s technical report, shuffled haystacks sometimes outperformed coherent ones, with the mechanism unresolved. One could propose that coherence helps when the material is task-relevant and hurts when it is filler, but that is a hypothesis, and it would take a manipulation of relevance and coherence together to distinguish it. Grouping also changes adjacency, so the two may not be separable in a simple manipulation.

Temporal sequencing. How time-bearing items are ordered: chronological, reverse-chronological or grouped by role. Each arrangement foregrounds different relationships. Chronological order preserves the narrated progression when the records accurately describe it; reverse-chronological order makes recent records easier to encounter in a simple linear presentation; role-grouping collects similar items but may separate an action from its outcome. These are design possibilities, not demonstrated improvements. Moreover, an item’s timestamp, the event time it describes and the time it was admitted may differ. A temporal policy needs to name which clock it orders by. Temporal sequencing is untested in the book’s own experiments.

Few-shot prompting offers the oldest related evidence. Zhao et al. (ICML 2021) found that few-shot classification accuracy with GPT-3 and GPT-2 varied from near chance to near state-of-the-art depending on prompt format, examples and example order, and attributed part of it to a bias towards answers placed near the end of the prompt or common in pre-training data. That is a behavioural effect under those conditions. Whether a long agent trace shows anything similar is speculative.

The word recency names three different things: temporal freshness (newer information), rendered lateness (closer to the end), and a behavioural bias towards later-presented alternatives. They are not the same. A newer item can be rendered early and an older one late, and a position effect can exist with no connection to real-world freshness. Newer does not mean later in the rendered sequence. Freshness is Chapter 20’s subject.

One move, several effects

Take a bundle whose tail reads: project rules, two file excerpts, three tool results, the current request. The harness team moves the rules to just above the request.

That single edit changes position, since the rules move from early-middle to late. It changes adjacency: the rules gain proximity to the request and lose proximity to some earlier neighbours. It changes grouping only if the move splits or joins a defined group. It may shorten a cross-invocation matching prefix, depending on the previous request and the provider’s rendering and caching rules. It leaves the rules’ formal authority unchanged only if their roles, provenance and applicable policy are preserved. Temporal ordering of time-bearing items need not change, although the moved rules now occur at a different place relative to those items.

So one physical edit can alter several measurable relations while leaving policy relations untouched. If behaviour then changes, the team may credit the change it intended, and it cannot attribute the difference to any one relation without additional controls. A harness change that alters several dimensions at once cannot attribute a behavioural difference to one of them.

Sequence is not authority

Teams sometimes observe that later items seem to weigh more, or that earlier items set the frame, and conclude that position confers importance. Then they use position as a control knob: the rule they most want obeyed goes last. The bundle becomes a set of hints about standing, expressed through sequence.

Salience is shorthand here for an observed change in selection, use or weighting associated with presentation order. It is not a directly measured internal quantity, and it is not authority. Wang et al. (arXiv preprint, 2023) reported that the quality ranking of candidate responses could be changed by altering their order of appearance, with GPT-4 and ChatGPT as evaluators: Vicuna-13B beat ChatGPT on 66 of 80 queries under a particular ordering with ChatGPT as the evaluator. The supported conclusion is narrow: candidate order changed LLM-judge verdicts in the tested evaluation. It does not show what the judge attended to, and it says nothing about instruction following in agents.

The distinction that matters is between behavioural influence from position and policy authority. If moving an instruction changes compliance, that does not mean its authority changed. The OpenAI Model Spec dated 18 August 2026 describes an instruction hierarchy running from Root through System, Developer and User to Guideline. Authority is assigned through the instruction source and applicable policy, not by being physically closer to the answer. For instructions at the same authority level, later applicable instructions can supersede earlier conflicting ones; this is a policy rule with conditions, not a general claim that whichever text appears last wins. The specification also treats tool outputs and quoted text as untrusted by default. This is OpenAI’s documented policy for its own systems, not a universal law or evidence that a model always complies. Other providers may specify different policies.

Three invariants follow, and they are worth stating in the book’s own vocabulary:

freshness  ≠ authority
position   ≠ precedence
proximity  ≠ scope

Physical sequence is an inadequate representation of authority and scope. Later chapters make authority and scope explicit and do not encode them implicitly through layout.

Cache order and behaviour order

The stability concern deserves one caution, and the full mechanics belong to Chapter 9. OpenAI’s documentation says cache reuse requires the entire rendered prefix to match, and that changes such as compaction or truncation can change the prefix and reset reuse. Under a prefix-matching cache, an order change can shorten the reusable matching prefix. That is provider-specific, and billing, latency and any local runtime cache are separate matters.

What follows is durable: cache-optimal order and behaviour-optimal order need not coincide. Caching may favour stable spans first. Behaviour may favour another arrangement. A layout policy has to state which it is optimising, or how it trades them, and neither is the default.

The evidence, by type

The results behind this chapter are different kinds of evidence and are not equivalent:

The chapter refuses three tempting sentences. “Always place important information first” confuses authority with primacy. “Always place the request last” matches common harness practice but has not earned the status of a law. “Middle context is ignored” turns a degradation curve into a deletion claim the data never supported. Where results disagree, as Chroma’s does with the intuition that clustering helps, both stay visible.

Proposed experiments

Nothing in this section has been run. Chapter 5 introduced the position experiment, and this chapter reuses that design rather than claiming independent evidence. Position, adjacency and grouping are proposed as distinct questions within a related fixture programme. They cannot be guaranteed to vary independently in every rendered layout: moving evidence normally changes neighbours and distances, while grouping often changes adjacency. Where a clean intervention is impossible, the analysis must name the compound manipulation instead of treating its result as an isolated effect.

For every experiment, the task fixture is the primary unit of analysis; repeated runs on one fixture estimate within-fixture variability and are not independent tasks. For the position condition, define normalised position as the midpoint token index of the critical item divided by the total rendered token count, and choose five target positions spanning the feasible range. Report the achieved positions, not just their labels, alongside token-count differences, role boundaries and any content displaced to make room. A target called “first” or “last” may be infeasible when the harness fixes leading instructions or a trailing user request.

Position. Move the same critical evidence across feasible positions. Hold fixed the task, model and version, settings, instructions, tool access and placement of the current request. Counterbalance which distractors occupy the vacated and new locations, and record their identity, position and distance from the evidence. Measure evidence recovery, task success and unsupported claims across repeated runs. A reproducible difference between positions would support an effect of this layout intervention in the tested tasks; it would not by itself identify an internal position mechanism. If no difference is detected, report the uncertainty and sensitivity of the test rather than declaring position irrelevant. Remaining limitation: position, distance from the request and the identity of neighbours cannot always be independently varied.

Adjacency. Vary the distance between two items that must be used together across several feasible separations, not only adjacent and far. Hold fixed their content, task, model settings, total length and structural labels where possible; counterbalance the intervening material and report the achieved distances and resulting absolute positions. Measure correct joint use, task success and unsupported claims across fixtures and repeated runs. A reproducible distance-related difference would support the tested adjacency intervention, not a pure mechanism claim, because changing separation also changes intervening material or one item’s position. A null result leaves an effect undetected at the tested separations and precision; it does not prove adjacency never matters.

Grouping. Contiguous against dispersed related items. Because grouping changes adjacency, this is a compound layout intervention unless structural labels can be varied at similar distances. If it cannot be separated from adjacency, the book should say so and defer the claim.

Temporal sequencing is not tested here. Which layout serves a coding-agent repair, and whether the answer changes with trajectory length, remains a hypothesis awaiting its own fixture family. A fourth fixture on instruction and data order was dropped, since it mixes position, precedence and adjacency. Latency is recorded as a secondary operational measurement, and is not treated as a behavioural verdict here because provider variance and caching can move it.

Inspect this in the Context Viewer

The viewer scene for this chapter shows one fixture bundle in two rendered orders: critical evidence first in one, third beside the fixed request in the other. Open the scene and follow the evidence’s movement by slot. What to examine: neighbours and distances in each ordering, with importance taken only from the fixture task spec. The two orderings are different layout conditions; no behavioural effect is measured and none is inferred from position.

Open the ordering scene in the Context Viewer

A layout contract

Experiments test, and production must still ship. The chapter does not earn a universal ordering, and it does not offer one. What it recommends is a contract that any layout should meet:

• Explicit and deterministic where possible, not an accident of arrival order.
• Versioned with the harness.
• Observable, so the rendered order can be read from a capture.
• Reproducible, so the same inputs yield the same sequence.
• Traceable, so a change of layout can be seen and attributed.
• Authority and scope not inferred from position.

A potential ordering regression cannot be diagnosed from an unordered inventory of content alone: identical items may be assembled in a different sequence, and behaviour can differ. Detecting the layout change requires an ordered trace; attributing a behavioural regression to it requires a comparable outcome and a controlled comparison. The desired trace records each admitted item’s identifier, rendered start and end offsets, group, neighbouring items, role or channel where known, and provenance or an explicit unknown status. Chapter 2’s observer preserves the ordered parts visible at its host boundary, but does not necessarily identify every item’s original source or the provider’s final rendering. Chapter 23’s compiler can record planned placement and compare it with what the observer actually captured.

A candidate layout can be shown as an example and nothing more:

The compiler’s default order, by role and then by identifier, is a declared policy rather than an experimental finding. It should be versioned and checked against role constraints and relationships that must remain intact, such as tool calls and their results; sorting every message or part indiscriminately could destroy the very sequence the compiler is intended to preserve.

The question ordering cannot answer

Chapter 4 said not everything can fit. Chapter 5 said not everything that fits helps. This chapter has said that even admitted information is affected by arrangement, and that arrangement is part of the context’s identity. Suppose the layout is settled. Capacity pressure arrives anyway, and something must give. Should the safety rule and the compiler log yield in the same way? Should the architecture decision and the abandoned hypothesis be treated by the same policy? Ordering says where information appears. It does not say what kind of information it is, and that is a matter of classification:

If admitted information differs not only by where it appears but by what kind it is, how should the system classify it before deciding how to treat it?

References

• Liu, N. F., Lin, K., Hewitt, J., et al. “Lost in the Middle: How Language Models Use Long Contexts.” Transactions of the Association for Computational Linguistics 12 (2024): 157–173; arXiv:2307.03172 (2023 preprint). Peer-reviewed. https://arxiv.org/abs/2307.03172
• Zhao, T. Z., Wallace, E., Feng, S., Klein, D., Singh, S. “Calibrate Before Use: Improving Few-Shot Performance of Language Models.” ICML 2021; arXiv:2102.09690. Peer-reviewed. Few-shot classification with GPT-3 and GPT-2. https://arxiv.org/abs/2102.09690
• Wang, P., Li, L., Chen, L., et al. “Large Language Models are not Fair Evaluators.” Preprint, arXiv:2305.17926, v2 August 2023. Not peer-reviewed. https://arxiv.org/abs/2305.17926
• Hong, K., Troynikov, A., Huber, J. “Context Rot: How Increasing Input Tokens Impacts LLM Performance.” Chroma technical report, 14 July 2025. Not peer-reviewed. https://www.trychroma.com/research/context-rot
• OpenAI. “Model Spec.” Current version dated 18 August 2026; first published May 2024. First-party policy documentation, provider-specific. https://model-spec.openai.com/
• OpenAI. “Prompt caching.” Official documentation, verified September 2026. Prefix-match requirement; provider-specific. https://developers.openai.com/api/docs/guides/prompt-caching