CWA Specification v2 draft — Context Window Architecture
CWA
GitHub
Specification · v2 draft · 2026-09-15

Context Window Architecture

A specification for assembling every model call from typed slots. This page is the normative text. Anything on the landing page, in the producer guide, or in the evidence notes that disagrees with this page is wrong. Requirements are numbered R-1 to R-23; numbers are permanent and never reused.

Status: draft. Not yet stable. Mirror: SPEC.md in the repository, same numbering. Licence: free to implement, no attribution required.
Requirement index · {{ ruleCount }} requirements
1

Conformance

The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are used as in RFC 2119. MUST is required for conformance; SHOULD is expected unless a reason is recorded; MAY is optional.

A conformant assembler satisfies every MUST in this document and can emit its trace as JSON with the fields required by R-21. A conformant producer satisfies every MUST in section 2 and the producer-specific rules in section 4 that apply to its kind.

Requirements are numbered R-n in a single flat sequence. A number is assigned once and never reused. A withdrawn requirement keeps its number and is marked withdrawn in the index. Other pages on this site, and the reference implementation, cite requirements by number.

The wire syntax of payloads and traces is not specified. Fields and behaviour are.

2

Model: planes, slots, items

A model call is assembled from items. Every item belongs to exactly one slot; slots are grouped into four planes. The planes answer four different questions and are never merged.

{{ p.name }}
{{ p.answers }}
{{ s }}
2.1 Slots
{{ s.id }}
{{ s.holds }}
{{ s.rule }}
2.2 Item fields

Eight fields are the minimum an assembler needs to place, rank, expire and trace an item. Six more carry the item's policy; when a producer omits them the assembler fills them from the slot's defaults. The JSON Schema is published with the scaffold.

Minimum · MUST
{{ f }}
Policy · SHOULD
{{ f }}
{{ f.key }} {{ f.text }}
{{ r.id }}
{{ s.text }}
3

Governance

Rule zero
Language guidance goes in context. Enforceable invariants go outside the model. "Never quote an unverified price" is stated in governance and enforced by a tool guard: the model is instructed; the application still enforces.
3.1 Authority hierarchy · high → low
{{ a.n }} {{ a.name }} {{ a.text }}

Slots never override platform message roles or application controls. A retrieved document is not an instruction because it contains imperatives. A preference does not lift a safety constraint. Tool output is evidence, not permission to act.

3.2 State is not memory
state.*

Canonical, structured, typed, current, application-owned. Workflow stage, approval status, selected entity IDs, pending action, retry count. The database is the source of truth, never the model.

interaction.memory

Fallible, compressible, source-linked, revocable. Preferences, prior-discussion summaries, inferred long-term facts. Every entry carries a TTL and the turn it was derived from.

3.3 Conflict resolution · default policy, overridable per route
{{ c.when }} → {{ c.then }}
row vs column
{{ t }}
{{ r.name }}
{{ c.text }}

Freshness tie-break. Between items of equal authority the fresher item governs; when freshness is equal or unknown the assembler escalates: surface both, retrieve more, or abstain. A fresh tool observation governs a retrieved passage for current facts, and a user correction revokes an inferred memory. Untrusted content defers to everything and is never an instruction.

{{ r.id }}
{{ s.text }}
4

Admission & fitting

Between a producer and the payload sit eight decisions. Each is a deterministic rule the trace can point at. A producer owns the first three stages for evidence it emits; the assembler owns the other five.

{{ s.n }} {{ s.name }} {{ s.text }}
4.1 Budget tiers

Every slot sits in one of three tiers. Protected items are rendered whole or the assembly is refused. Compressible items may be replaced by a precomputed shorter variant. Droppable items may be omitted. Under pressure the assembler drops before it compresses, and never touches protected items.

{{ r.id }}
{{ s.text }}
5

Placement profiles

Placement is model-, task- and content-dependent. This specification takes no position on where items go. It fixes the semantic slots and requires that placement be a profile: versioned, per route, evaluated against that route's tasks. The evidence for this position is collected on the Evidence page.

profile.yamlthe shape every profile is an instance of
profile: id: policy-first-chat version: 1 route: support-chat model_family: "<family and version this profile was evaluated on>" placement: # ordered; omitted slots are not rendered - { 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: interaction.examples, wrap: xml:examples } - { slot: governance.output_contract, wrap: xml:format } - { slot: interaction.query, wrap: xml:query } evaluation: suite: "<route eval suite and version>" date: "<date>" result: "<metrics that justified promotion>"
{{ r.id }}
{{ s.text }}
6

Trace & conformance tests

Every assembly emits a trace. "Debuggable" means an engineer can reconstruct and compare assembly decisions, not just read the payload. Outcome metrics ride on top: groundedness, task success, tool-call correctness, recovery behaviour, latency, cost.

Trace fields
MUST · trace_id · profile { id, version } · budget { input, reserved_output } · result { input_tokens, hash } · included[] { slot, item_id, tokens } · compressed[] { slot, from, to, method } · excluded[] { item_id, reason } · conflicts[] { items, resolution } · refused { bool, reason }
SHOULD · per-item source_version · the eligibility rule text · admission-stage timings · defaults filled per item
6.1 Tests the trace makes possible
{{ t.name }} {{ t.text }} {{ t.rule }}
{{ r.id }}
{{ s.text }}
Changelog
v2 draft
2026-09-15
  • Moved the normative text to this page. Numbered every requirement R-1 to R-23 in one flat sequence.
  • Made explicit as requirements what the landing stated as tests: budget-tier order (R-16), refusal (R-17), determinism (R-23).
v2 draft
2026-09-14
  • Added the problem statement with seven named failure modes, each reproducible in the demo.
  • Added the conformance definition and normative MUST / SHOULD / MAY forms of existing rules.
  • Enumerated the authority + freshness matrix and defined the profile shape (profile.yaml).
  • Expanded placement evidence with cited sources; the site takes no position on where items go.
  • Added the producer contract for retrieval, memory and MCP, and the precomputed-variant rule.
  • Published the context item as JSON Schema; stated required trace fields.
Future work · non-normative

A future revision will describe request intent as a typed tree that items bind to, so that eligibility rules can reference the part of the request an item serves rather than the request as a whole. A reference assembler implementing this specification is in progress; its conformance status is tracked on the Assembler page.