CWA is a free specification for assembling everything a model call needs — instructions, state, evidence, history, the live turn — into one payload where every item has an owner, an authority, a lifecycle, a budget, and a place. The assembly is deterministic, and every step of it can be inspected.
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.
Given the same request state, source versions, selection rules, and budget, the assembler emits the same payload in the same order. That is a claim a test can check. "The model will answer the same way" is not, and CWA never makes it.
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 by priority, and renders them in a tested order. 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 passage, 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 passages, 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.
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 normative rules, the producer contract, and the placement evidence each have a page of their own.
"Retrieval goes in slot three" is memorable, but it is too coarse. Between the vector store and the payload sit eight decisions, and each one is a deterministic rule the trace can point at. For high-stakes answers the slot holds evidence packets, each carrying source, passage, version, relevance, authority, and whether it is binding or informative, rather than undifferentiated "knowledge."
{{ s.text }}
CWA does not dictate syntax, so tag slots however your stack prefers: XML-style blocks, message roles, or delimited sections. What matters is that every item names its slot and authority, evidence arrives as packets with provenance, and the profile that ordered them is recorded.
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, how they're packetized, 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 migrator that proposes slots for your prompt and five files to copy: an assembly function, an empty payload, the item schema as YAML 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. A reference assembler that implements this spec, covering admission, fitting, profiles, and traces, is in progress, and we want to hear what it must do. A future revision will describe request intent as a typed tree that items bind to.