Every model call is built from pieces: instructions, what the app knows, what it looked up, the conversation, and the question. CWA specifies how those pieces are chosen, fitted to a budget and ordered, so the same inputs always build the same request, and every decision can be read back.
Every model call is assembled by a function, and in most systems that function has no name. It has grown arguments for a year, it concatenates whatever the route happens to hold, and it knows nothing about who is allowed to direct the model, how old each piece is, what to shorten when the window is full, or what it sent last time. The failures this produces are not random: they repeat, they have recognisable shapes, and they can be named.
Where an item sits in the window matters too, and that question has evidence of its own: Why placement is a profile, not a rule.
"Evidence polluted governance" and "history displaced tool results" are sentences a team can act on. Named planes and slots turn vague prompt debates into specific bug reports.
A governance item may state a rule, but the application enforces it outside the model (R-5). CWA never relies on context to keep an invariant, and it never claims the model will answer the same way twice.
Tokens are finite, so when every item is measured and tiered the assembler knows what to protect, what to compress, what to drop, and when to stop and report that the evidence did not fit.
CWA gives you four planes and eleven typed slots, and no single request fills them all. The assembler admits the items each request actually needs, fits them to a finite budget in tier order, and renders them in a profile-defined order. This simulation uses estimated tokens and illustrative outcomes, not model evaluations; each system's route is taken to require evidence when the system uses an evidence slot. Remove the instructions or the query and it shows the refusal R-4 requires instead of a payload. A refused assembly has no payload, but its trace still records every decision made before the refusal (R-17); a snapshot that fails its schemas or checks is rejected before assembly, with neither a payload nor a trace. Watch seven very different systems assemble, then pull a slot out or squeeze the budget and see what degrades first.
{{ ucSymptom }}
{{ ucNote }}
A plane says why a piece of context exists. A slot is a typed collection inside a plane, with its own admission rules. An item is one governed object in a slot — a policy, a retrieved chunk, a tool observation. Newcomers learn the planes; implementers use the slots; the assembler moves the items.
{{ pl.blurb }}
{{ layer.purpose }}
{{ layer.value }}
Real systems put three retrieved chunks, two tool observations, and a memory summary plus a task episode into the same request. Each one is a separate item with its own metadata, and without that metadata even a clean slot order produces unpredictable payloads.
Every item carries its source and version, its authority, when it was true and when it expires, its scope, its budget and tier, and the fields that say how it may be handled. The Producers page lists all fourteen, with the slot defaults that fill the ones a producer omits.
The minimum item →{
"id": "refunds-eu:v17#p4",
"slot": "evidence.knowledge",
"source": "policy-corpus",
"source_version": "2026-09-10",
"authority": "reference_only",
"trust": "verified",
"freshness": "2026-09-12T15:30:00Z",
"expires": "2026-12-12T15:30:00Z",
"scope": {
"tenant": "acme",
"task": "refund_request"
},
"relevance": 0.91,
"token_budget": 420,
"tier": "compressible",
"variants": [],
"conflict_policy": "defers",
"injection_risk": "untrusted_content",
"lineage": "verbatim",
"eligibility": "support-chat/illustrative/v1: tenant acme; rerank at least 0.5",
"body": "Pro plans refund in full within 30 days of purchase."
}
A fixed order reproduces a payload, but it says nothing about who is allowed to direct the model, what wins when sources disagree, whether this order is right for this model, or how anyone would know. The six steps, the normative rules, the producer contract, the placement evidence and the implementations each have a page of their own.
Your existing tools supply the materials, and CWA is the assembly step between them and the model.
Retrieval produces candidates for the Evidence plane. CWA decides which are admitted, where they're placed, and what they may never overrule.
Read →MCP is the transport for tools and resources. CWA governs what it returns — tool specs proposed to the route's capability policy and admitted into Governance, observations in Evidence, each with freshness and authority.
Read →Frameworks orchestrate the loop. CWA assembles the payload each step of that loop actually sends, and emits the trace for it.
Read →Prompting is craft at the sentence level and CWA is structure at the payload level, so you need both.
Read →Your framework is the harness: it runs the loop, calls the tools, keeps the state, and retries the failures. It is deliberately unopinionated about the one thing that decides answer quality, which is what actually lands in the window on each pass. CWA fills that gap. Pick your stack:
The getting-started guide takes you in six steps from your current prompt to a payload with owners. It includes a sample prompt split into slots, to see CWA in action, and five files to copy: an integration sketch, a rendering template, a complete item example and JSON Schema, and a cwa.md for coding agents.
Name the slots you already send, give every item an authority and a source, and see how much of your payload had no owner. Draft of 2026-10-07. Four assemblers, in Python, TypeScript, Go and Rust, each pass all 90 published cases, rejections included; none has a versioned release yet, and we want to hear what they must do. That report is what an assembler's conformance claim rests on, while a producer's or an application's rests on its word, and an application must render with a renderer the published cases cover (§1).