{"course":{"slug":"context-engineering","title":"Context Engineering","url":"https://addaly.com/learn/context-engineering","level":"advanced","track":"build"},"lesson":{"slug":"ordering-evidence-relevance-or-chronology","title":"Ranked order is not always reading order","url":"https://addaly.com/learn/context-engineering/ordering-evidence-relevance-or-chronology","position":37,"of":87,"minutes":8,"answer":"Retrieval rank decides what enters the window; reading order is a separate decision (relevance order for finding a fact.","keyIdea":"Retrieval rank decides what enters the window; reading order is a separate decision (relevance order for finding a fact, natural order whenever a human reading the passages out of sequence would be misled) and either way state the order in one line so the model does not infer a different one."},"body":{"format":"markdown","text":"## Three orders, three different tasks\n\nThe retriever hands you passages ranked by relevance. That ranking decided what got in. It is not automatically the order they should appear in, and the right order depends on what the model is being asked to do with them.\n\n**Relevance descending.** Best first. The default, and the right choice when the task is to find one fact and the strongest passage is likely to contain it. It also puts the best material at the start of the window, where the position curve is favourable.\n\n**Relevance ascending.** Best last, closest to the question. Exploits the recency half of the U curve and is worth testing whenever your instruction block sits at the top. Frequently wins on single-fact extraction; frequently makes no difference at five passages.\n\n**Natural order.** Chronological for events, document order for a report, dependency order for code. This is not a tuning choice: for some tasks it is a correctness requirement.\n\n## When natural order is not optional\n\nIf the material has an inherent sequence and the task depends on it, relevance ordering actively corrupts the input.\n\n**Meeting notes, incident timelines, message threads.** Reordered by relevance, the model sees the resolution before the cause. It will produce a coherent narrative in the order you gave it, and the narrative will be wrong about what led to what. This is a real and frequent failure in incident-summary tools, and it is invisible unless somebody who was there reads the output.\n\n**Legal and policy documents.** Clause 7 modifies clause 4. Presented in the other order, or with clause 4 absent, the model states the general rule without the exception.\n\n**Code.** A function presented before its imports and type definitions is harder to reason about, and a model asked to modify it will reference things that do not exist in the order given.\n\n**Versioned material.** If several versions are present, chronological with dates is the only order that lets the model reason about supersession at all.\n\nThe rule: **if a human reading these passages out of order would be misled, the model will be too.**\n\n## Say what the order is\n\nWhichever you choose, tell the model. One line, immediately above the block:\n\n```\nPassages are ordered by relevance, not by date. Each carries its own date.\n```\n\nor\n\n```\nPassages are in chronological order, oldest first.\n```\n\nThis costs ten tokens and prevents a specific inference the model otherwise makes on its own. Without it, a model reading eight passages tends to treat their order as meaningful (often as chronological) because in its training data ordered lists usually are. Stating the truth removes the guess.\n\n## Interleaving groups\n\nWhen material comes from different kinds of source (documents, database rows, the user's uploaded file, a tool result) do not merge them into one relevance-ranked stream. Group them, label each group, and order within groups.\n\n```\n<user_document> ... </user_document>\n<retrieved_passages> ... </retrieved_passages>\n<account_records> ... </account_records>\n```\n\nThree reasons. The groups have different trust levels, and the trust module needs them separable. They have different orders: records are chronological, passages are ranked. And the model can be told how to weigh them: \"prefer the user's document where it conflicts with general documentation\" is a usable instruction only if the two are distinguishable.\n\n## Deciding between relevance directions\n\nThis is an experiment, not a principle, and it is one of the cheapest in the course: the same content, two orderings, one evaluation set. No re-indexing, no new retrieval, nothing else changes.\n\nExpect a small effect at five passages and a larger one at twenty. Expect it to differ by model. Expect the direction to flip when you move your question from the top of the request to the bottom, since the two are interacting, which is why the two experiments should be run together rather than months apart.\n\nAnd expect, on many systems, no significant difference at all. That result is worth having: it tells you ordering is not where your quality is going, and you can spend the next week on retrieval recall instead.\n\n## Keep ordering separate in the code\n\nAs the packing lesson argued: selection decides what, ordering decides where. If those are one function you cannot change the order without touching selection, and every ordering experiment silently becomes a selection experiment.\n\n```python\nchosen = pack(ranked_candidates, budget)      # what\nordered = arrange(chosen, strategy=cfg.order) # where\n```\n\nTwo functions, one configuration field, and the experiment is a config change rather than a branch."},"check":{"question":"An incident-summary tool retrieves twelve chat messages and orders them by relevance. Summaries are fluent but frequently state the wrong cause. Why?","options":[{"text":"Relevance ranking favoured the resolution messages, which contain the clearest language, so earlier messages were dropped.","correct":false,"tempting":"Explains a selection bias that may also be present, but the described failure is about sequence, not about missing messages."},{"text":"Chat messages are short, so chunking split them and destroyed context.","correct":false,"tempting":"Short messages are the case chunking handles well; nothing here suggests a split."},{"text":"Reordering destroyed the temporal sequence, and the model reads the given order as the order events happened.","correct":true},{"text":"Messages lacked timestamps in their headers, so the model could not date them.","correct":false,"tempting":"Adding timestamps helps, but a model presented with scrambled order still tends to narrate in presentation order."}]},"prev":{"slug":"delimiters-and-boundaries","title":"Marking where one thing ends","url":"https://addaly.com/learn/context-engineering/delimiters-and-boundaries"},"next":{"slug":"few-shot-examples-inside-a-budget","title":"What examples cost, and what they buy","url":"https://addaly.com/learn/context-engineering/few-shot-examples-inside-a-budget"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Ranked order is not always reading order', in Context Engineering. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/context-engineering/ordering-evidence-relevance-or-chronology (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Ranked order is not always reading order","courseTitle":"Context Engineering","module":{"index":4,"slug":"position-and-order","title":"Position, order and what the model actually reads"},"answer":null,"keyIdea":"Retrieval rank decides what enters the window; reading order is a separate decision (relevance order for finding a fact, natural order whenever a human reading the passages out of sequence would be misled) and either way state the order in one line so the model does not infer a different one.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"three-orders-three-different-tasks","runs":[{"text":"Three orders, three different tasks"}]},{"t":"p","runs":[{"text":"The retriever hands you passages ranked by relevance. That ranking decided what got in. It is not automatically the order they should appear in, and the right order depends on what the model is being asked to do with them."}]},{"t":"p","runs":[{"text":"Relevance descending.","b":true},{"text":" Best first. The default, and the right choice when the task is to find one fact and the strongest passage is likely to contain it. It also puts the best material at the start of the window, where the position curve is favourable."}]},{"t":"p","runs":[{"text":"Relevance ascending.","b":true},{"text":" Best last, closest to the question. Exploits the recency half of the U curve and is worth testing whenever your instruction block sits at the top. Frequently wins on single-fact extraction; frequently makes no difference at five passages."}]},{"t":"p","runs":[{"text":"Natural order.","b":true},{"text":" Chronological for events, document order for a report, dependency order for code. This is not a tuning choice: for some tasks it is a correctness requirement."}]},{"t":"h2","id":"when-natural-order-is-not-optional","runs":[{"text":"When natural order is not optional"}]},{"t":"p","runs":[{"text":"If the material has an inherent sequence and the task depends on it, relevance ordering actively corrupts the input."}]},{"t":"p","runs":[{"text":"Meeting notes, incident timelines, message threads.","b":true},{"text":" Reordered by relevance, the model sees the resolution before the cause. It will produce a coherent narrative in the order you gave it, and the narrative will be wrong about what led to what. This is a real and frequent failure in incident-summary tools, and it is invisible unless somebody who was there reads the output."}]},{"t":"p","runs":[{"text":"Legal and policy documents.","b":true},{"text":" Clause 7 modifies clause 4. Presented in the other order, or with clause 4 absent, the model states the general rule without the exception."}]},{"t":"p","runs":[{"text":"Code.","b":true},{"text":" A function presented before its imports and type definitions is harder to reason about, and a model asked to modify it will reference things that do not exist in the order given."}]},{"t":"p","runs":[{"text":"Versioned material.","b":true},{"text":" If several versions are present, chronological with dates is the only order that lets the model reason about supersession at all."}]},{"t":"p","runs":[{"text":"The rule: "},{"text":"if a human reading these passages out of order would be misled, the model will be too.","b":true}]},{"t":"h2","id":"say-what-the-order-is","runs":[{"text":"Say what the order is"}]},{"t":"p","runs":[{"text":"Whichever you choose, tell the model. One line, immediately above the block:"}]},{"t":"code","lang":"","label":"Text","text":"Passages are ordered by relevance, not by date. Each carries its own date."},{"t":"p","runs":[{"text":"or"}]},{"t":"code","lang":"","label":"Text","text":"Passages are in chronological order, oldest first."},{"t":"p","runs":[{"text":"This costs ten tokens and prevents a specific inference the model otherwise makes on its own. Without it, a model reading eight passages tends to treat their order as meaningful (often as chronological) because in its training data ordered lists usually are. Stating the truth removes the guess."}]},{"t":"h2","id":"interleaving-groups","runs":[{"text":"Interleaving groups"}]},{"t":"p","runs":[{"text":"When material comes from different kinds of source (documents, database rows, the user’s uploaded file, a tool result) do not merge them into one relevance-ranked stream. Group them, label each group, and order within groups."}]},{"t":"code","lang":"","label":"Text","text":"<user_document> ... </user_document>\n<retrieved_passages> ... </retrieved_passages>\n<account_records> ... </account_records>"},{"t":"p","runs":[{"text":"Three reasons. The groups have different trust levels, and the trust module needs them separable. They have different orders: records are chronological, passages are ranked. And the model can be told how to weigh them: “prefer the user’s document where it conflicts with general documentation” is a usable instruction only if the two are distinguishable."}]},{"t":"h2","id":"deciding-between-relevance-directions","runs":[{"text":"Deciding between relevance directions"}]},{"t":"p","runs":[{"text":"This is an experiment, not a principle, and it is one of the cheapest in the course: the same content, two orderings, one evaluation set. No re-indexing, no new retrieval, nothing else changes."}]},{"t":"p","runs":[{"text":"Expect a small effect at five passages and a larger one at twenty. Expect it to differ by model. Expect the direction to flip when you move your question from the top of the request to the bottom, since the two are interacting, which is why the two experiments should be run together rather than months apart."}]},{"t":"p","runs":[{"text":"And expect, on many systems, no significant difference at all. That result is worth having: it tells you ordering is not where your quality is going, and you can spend the next week on retrieval recall instead."}]},{"t":"h2","id":"keep-ordering-separate-in-the-code","runs":[{"text":"Keep ordering separate in the code"}]},{"t":"p","runs":[{"text":"As the packing lesson argued: selection decides what, ordering decides where. If those are one function you cannot change the order without touching selection, and every ordering experiment silently becomes a selection experiment."}]},{"t":"code","lang":"python","label":"Python","text":"chosen = pack(ranked_candidates, budget)      # what\nordered = arrange(chosen, strategy=cfg.order) # where"},{"t":"p","runs":[{"text":"Two functions, one configuration field, and the experiment is a config change rather than a branch."}]}],"check":{"question":[{"text":"An incident-summary tool retrieves twelve chat messages and orders them by relevance. Summaries are fluent but frequently state the wrong cause. Why?"}],"options":[{"text":[{"text":"Relevance ranking favoured the resolution messages, which contain the clearest language, so earlier messages were dropped."}],"correct":false,"tempting":[{"text":"Explains a selection bias that may also be present, but the described failure is about sequence, not about missing messages."}]},{"text":[{"text":"Chat messages are short, so chunking split them and destroyed context."}],"correct":false,"tempting":[{"text":"Short messages are the case chunking handles well; nothing here suggests a split."}]},{"text":[{"text":"Reordering destroyed the temporal sequence, and the model reads the given order as the order events happened."}],"correct":true,"tempting":null},{"text":[{"text":"Messages lacked timestamps in their headers, so the model could not date them."}],"correct":false,"tempting":[{"text":"Adding timestamps helps, but a model presented with scrambled order still tends to narrate in presentation order."}]}],"order":[1,3,2,0],"why":null},"prev":{"slug":"delimiters-and-boundaries","title":"Marking where one thing ends","minutes":8},"next":{"slug":"few-shot-examples-inside-a-budget","title":"What examples cost, and what they buy","minutes":9}}}