Why placement is a profile, not a rule.

Where an item sits in the window changes whether the model uses it. That effect is real, measured, and different for every model family, task shape and context length. A specification that hard-coded an order would be right for one deployment and wrong for the next, and nobody would be able to tell which.

So CWA takes no position on where items go. It requires only that placement be a profile: versioned, per route, evaluated against that route's tasks before it's promoted for deployment, and recorded in every trace. Every profile on this site is an unevaluated example. No reproducible profile evaluation is published here; evaluate the target route before promotion.

Serial-position effects are measured, not folklore. Liu et al. tested models on multi-document question answering and key-value retrieval and found a U-shaped curve: accuracy is highest when the relevant information sits at the beginning of the context (primacy) or at the end (recency), and drops when it sits in the middle. [1]

Later long-context work finds the effect persists and varies. RULER evaluated 17 models and found almost all lose accuracy as context length grows, despite near-perfect scores on simple needle retrieval. [2] NoLiMa finds models do well at the edges of the window when the task is a literal match, but when the answer needs an associative hop, longer contexts pull performance down even at the edges. [3]

Position, length, model family and task interact. No single number describes it, and no single order is safe to bake into a spec.

Placement decides a second thing: how much of one call's payload the next call repeats byte for byte. Provider prompt caches reuse a request's leading part only up to the first byte that changed. [6] [7] A slot whose content changes every turn, placed early, makes everything after it full price on every call.

CWA's part is to make the repeat exact and its boundaries visible. An identical snapshot renders identical bytes (R-23). History renders in the order turns were said, so a new turn lands after the earlier ones (R-7). The optional cwa-message-blocks/v1 renderer hands each placed item over as its own content entry, so a breakpoint can follow any item. The application's part is the request: which entry carries a breakpoint, which cache lifetime to pay for, and any cache key. None of it is text, so the count and hash the trace records still describe what the model reads (§1).

Attention and caching mostly agree: stable governance goes early and the live query goes last. They disagree in the middle. Long-context guidance puts documents near the top [4], while a cache wants per-turn retrieval below the history. cache-first-chat/v1 is the cache-ordered example; policy-first-chat/v1 is the attention-ordered one, and both are published in examples/profiles.json. Which order wins for a route is an evaluation question, like every other placement choice.

Some things break reuse even in a stable order: budget pressure that sheds the oldest turn on every call (R-16), a different variant chosen for an early item (R-18), a governance item at a new source_version, and a surfaced conflict's mark (R-11). A history producer that compacts old turns in blocks, rather than dropping one per call, keeps the history's leading part unchanged between compactions.

{  "spec": "cwa/draft",  "id": "policy-first-chat",  "version": 1,  "route": "support-chat",  "model_family": null,  "route_policy_version": "illustrative/v1",  "placement": [    {      "slot": "governance.instructions",      "wrap": "system"    },    {      "slot": "state.user",      "wrap": "xml:user_profile"    },    {      "slot": "evidence.knowledge",      "wrap": "xml:evidence"    },    {      "slot": "state.task",      "wrap": "xml:task"    },    {      "slot": "interaction.memory",      "wrap": "xml:memory"    },    {      "slot": "interaction.history",      "wrap": "xml:history"    },    {      "slot": "governance.capabilities",      "wrap": "tools"    },    {      "slot": "evidence.tool_results",      "wrap": "xml:observation"    },    {      "slot": "governance.examples",      "wrap": "xml:examples"    },    {      "slot": "governance.output_contract",      "wrap": "xml:format"    },    {      "slot": "interaction.query",      "wrap": "xml:query"    }  ],  "evaluation": {    "status": "unevaluated",    "suite": null,    "date": null,    "result": null,    "artifact": null  }}

── system ──
You are Ada, a support agent for Northwind.
Never quote prices you cannot verify with a tool.

── tool ──
{"name": "issue_refund", "parameters": {"order_id": "string", "amount": "number"}}

── tool ──
{"name": "lookup_order", "parameters": {"order_id": "string"}}

── user ──
<user_profile id="user:profile">
plan=pro; region=EU; tone=concise
</user_profile>
<evidence id="billing-faq:v3#p1">
Refunds return to the original payment method.
</evidence>
<evidence id="refunds-eu:v17#p4">
Pro plans refund in full within 30 days of purchase.
</evidence>
<task id="task:refund_request">
refund_request: verify_eligibility=done, issue=pending
</task>
<memory id="mem:plan-purchase">
User bought Pro in March, EU billing.
</memory>
<history id="turn:16" speaker="user">
Is my order refundable?
</history>
<history id="turn:17" speaker="assistant">
Let me check order 8821.
</history>
<observation id="obs:order-8821">
{"order_id": "8821", "total": 240, "days_since_purchase": 12}
</observation>
<format id="format:chat">
Max 3 sentences. No bullet lists.
</format>
<query id="turn:18">
Can you just process it now?
</query>