Terminology, specifications and documentation should be clear, accurate and consistent.

1. Terminology should be clearly defined in [glossary](https://github.com/a2ui-project/a2ui/blob/main/docs/public/concepts/glossary.md).
2. Each doc in [specification](https://github.com/a2ui-project/a2ui/tree/main/specification), prioritizing [specification/v1_0](https://github.com/a2ui-project/a2ui/tree/main/specification/v1_0), should contain section 'Glossary' on the top, that itemizes glossary terms, used in the doc, linked to the section in glossary. See [discussion](https://github.com/a2ui-project/a2ui/pull/2540#issuecomment-5563665027).
3. Each doc in [specification](https://github.com/a2ui-project/a2ui/tree/main/specification), prioritizing [specification/v1_0](https://github.com/a2ui-project/a2ui/tree/main/specification/v1_0) should be reviewed to make sure it is easy to understand.

IMPORTANT: clean up of terminology can be set of small PRs, so that they are easy to review and discuss.

Some terms that are currently missing or inconsistently used:

# Glossary candidates from the specification folder

Terms used in `specification/` that [the glossary](https://github.com/a2ui-project/a2ui/blob/main/docs/public/concepts/glossary.md) does not define. Scratch file — not meant to be committed.

**How this was built.** Read every `.md` under `specification/`, pulled out the terms the prose treats as named concepts (bolded, headed, or used as if already defined), then checked each against the glossary. Focus is `v1_0` (the current candidate) and `proposals/`; `v0_8`, `v0_9` and `v0_9_1` were scanned but historical-only terms are left out. Links are absolute and pinned to `main`.

**Priority.** ⭐ = worth adding first: either a reader hits it in the first few pages of the protocol doc, or the glossary already says something that contradicts it.

---

## A. Terminology conflicts — names that do not agree

These are not just missing terms. Something is already called two things, so a glossary entry has to pick a winner before it can be written. Worth settling before adding anything new.

### A.1. The glossary and the spec disagree

The glossary defines something under a name v1.0 uses for a different thing, or defines a v0.9-era meaning that v1.0 changed.

- ⭐ **`Surface` (container component)** vs **Surface (area of UI)** — the glossary defines Surface as "an area of UI … which consists of a number of components". v1.0 also reserves `"Surface"` as a **component type name**: the canonical container that `createSurface` implicitly instantiates, always holding `"child": "root"`, which catalogs MUST NOT redefine and `updateComponents` cannot modify. Two different things under one word, one of them a reserved identifier. The glossary entry needs to name both senses.
[a2ui_protocol.md L180](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L180), [reserved name rule L536](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L536)

- ⭐ **Client function** is a v0.9 definition — the glossary says "a function provided for agent to invoke when needed" and contrasts it with LLM tools. v1.0 made function calling bidirectional (`callRendererFunction` / `callAgentFunction`) and moved the invocation rules into the catalog via `allowedCallers`. The entry describes one direction of what is now a two-way mechanism, and its table row "Executor: A2UI Renderer" is no longer always true.
[a2ui_protocol.md L297](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L297)

- ⭐ **A2UI Tag** vs **sentinel tags** — the glossary calls `` / `` an "A2UI Tag". Every inference-format proposal calls the same thing "sentinel tags". Pick one and cross-reference the other.
[a2ui_express.md L16](https://github.com/a2ui-project/a2ui/blob/main/specification/proposals/express/a2ui_express.md#L16)

- **Renderer stack** vs the **three-tier SDK architecture** — the glossary's "Renderer stack" lists Core Library / Catalog Schema / Framework adapter / Catalog Implementation. `sdks_spec.md` defines a different decomposition — A2UI Core SDK, Inference SDK, Framework Adapters — and the Inference SDK has no glossary counterpart at all. Two vocabularies for the same ecosystem.
[sdks_spec.md L3](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/sdks_spec.md#L3)

- **Capabilities Object** predates the v1.0 split — the glossary describes it as a "set of catalogs that are available for use" and notes the v0.9/v0.8 naming. v1.0 splits it into `agent_capabilities.json` and `renderer_capabilities.json` with distinct fields (`acceptsInlineCatalogs` on one side, `inlineCatalogs` on the other), which the entry does not mention.
[a2ui_protocol.md L1466](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1466)

### A.2. The spec disagrees with itself

One concept, several spellings, none marked as the canonical one. Each of these needs a preferred term chosen before it can be glossed — and the choice is a spec edit, not just a glossary edit.

- ⭐ **Authorized callers** — the `allowedCallers` concept is spelled at least five ways in v1.0 alone: "Runtime authorized callers" ([evolution_guide.md L9](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/evolution_guide.md#L9)), "authorized callers" ([a2ui_protocol.md L599](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L599)), "execution boundary" ([L312](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L312), and again in the renderer `error` section at [L1408](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1408)), "Security Boundaries and Verification" as a heading ([L310](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L310)), and "remote invocation safety" ([L1484](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1484)). Since this is the protocol's main security control, five names for it is the worst place to have this problem. Suggest `allowedCallers` as the schema field, "execution boundary" as the prose term, and the rest folded into the glossary entry as aliases.

- ⭐ **Renderer-side function** — also called "registered function" ([a2ui_protocol.md L1032](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1032)), "renderer-side logic" ([L1030](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1030)), and "local function" where actions invoke one ([L813](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L813)). The glossary adds a fourth name for the same thing, **Client function**, which no v1.0 doc uses. Four names, and the one the glossary picked is the one the spec abandoned.

- **Inference format vs DSL** — `specification/inference_formats/` is a directory name, and the phrase "inference format" appears twice across the v1.0 docs and proposals, against 26 uses of "DSL". If the category term is meant to be "inference format", the proposals do not reflect it yet; see the section H entry.

---

---

## B. Wire format and message structure

- ⭐ **Envelope** — the JSON object wrapping exactly one message body, carrying `version` plus exactly one of `createSurface`, `updateComponents`, `updateDataModel`, `deleteSurface`, `callRendererFunction`, `agentFunctionResponse`. The one-key rule is the first thing any validator enforces, and the glossary's "A2UI message" entry never names it.
[a2ui_protocol.md L136](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L136), [one-key rule L172](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L172)

- ⭐ **Agent-to-renderer message** / **renderer-to-agent message** — the two directions have separate schemas and separate message sets. The glossary's "A2UI message" covers both without distinguishing them, so the four/four split is invisible.
[renderer-to-agent set L1296](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1296)

- ⭐ **`root` component** — the reserved component id that every surface's tree must have exactly one of, and until it arrives other components are buffered and invisible. A load-bearing convention with no glossary entry.
[a2ui_protocol.md L704](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L704)

- **`functionCallId`** — the correlation id a renderer must copy verbatim from `callRendererFunction` into its response or error. The only thing tying an RPC pair together.
[a2ui_protocol.md L297](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L297)

- **`FunctionResponse`** (`rendererFunctionResponse` / `agentFunctionResponse`) — the shared payload shape carrying either `value` or `error`, never both.
[a2ui_protocol.md L363](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L363)

---

## C. Composition

- ⭐ **Adjacency list model** — the defining structural choice of the protocol: components arrive as a flat list and the tree is rebuilt from id references, which is what lets the agent send them in any order. Named as a heading in the protocol doc, absent from the glossary.
[a2ui_protocol.md L704](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L704)

- ⭐ **Progressive rendering** — rendering a partial tree while the stream is still arriving, with unresolved references and `undefined` paths handled gracefully rather than as errors. Used from the opening paragraph onward as if already defined.
[a2ui_protocol.md L22](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L22), [data-path note L839](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L839)

- **Composition constraints** (`allowedParents` / `allowedChildren`) — catalog-declared parent-child rules, evaluated at runtime because JSON Schema cannot express them across a flat id-referenced list. Comes with its own error codes, `UNALLOWED_PARENT` and `UNALLOWED_CHILD`.
[a2ui_protocol.md L737](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L737)

- **`ComponentId`** / **`ChildList`** — the two schema types a catalog must use for child references so validators can tell a structural link from a plain string. Getting this wrong silently disables reference checking, which makes it worth a glossary entry rather than only a spec footnote.
[a2ui_protocol.md L133](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L133), [validator rules L159](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L159)

- **Template** (`ChildList` object form) — a `{componentId, path}` pair that generates one instantiated component per array item, as opposed to a static array of ids. Prerequisite for understanding Collection Scope and `@index`.
[a2ui_protocol.md L129](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L129)

- **`AccessibilityAttributes`** — `label`, `description`, `live`, `hidden`, attached through `ComponentCommon`, with normative requirements that renderers map them to native accessibility APIs and infer defaults. Nothing in the glossary covers accessibility.
[a2ui_protocol.md L506](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L506)

---

## D. Catalogs

- ⭐ **Mixable catalogs** and the **catalog resolution order** — one surface may combine components from several catalogs; each component or function call resolves through its own `catalogId`, then the surface default, then errors, with explicitly _no_ fallback to advertised capabilities. The single most consequential v1.0 change to catalog handling, and the glossary's "Catalog" entry says nothing about it.
[a2ui_protocol.md L493](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L493)

- ⭐ **`catalogId`** — an arbitrary string identifier conventionally shaped like a URI but explicitly _not_ resolvable and not required to point at anything. The spec repeats this disclaimer three times, which suggests people keep assuming otherwise; a glossary entry would settle it.
[a2ui_protocol.md L185](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L185), [catalog structure L516](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L516)

- ⭐ **Inline catalog** (`inlineCatalogs` / `acceptsInlineCatalogs`) — a full catalog definition the renderer ships to the agent in capabilities metadata, rather than both sides agreeing on a well-known id in advance. The negotiated alternative to `supportedCatalogIds`.
[a2ui_protocol.md L1476](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1476)

- **`supportedCatalogIds`** — what each side advertises it can render or generate. Referenced constantly; only obliquely covered by "Capabilities Object".
[a2ui_protocol.md L1466](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1466)

- **Catalog entity naming rules (UAX #31)** — component names, function names and argument keys must be valid Unicode identifiers, `^[\p{XID_Start}_][\p{XID_Continue}]*$`. A hard conformance requirement, easy to violate accidentally with a hyphen.
[a2ui_protocol.md L529](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L529)

- **`instructions`** (catalog field) — Markdown design rules embedded in the catalog to steer the LLM, replacing the old external `rules.txt`. This is the "explanation on how renderer capabilities should be used" half of the glossary's Catalog definition, now with a concrete home.
[a2ui_protocol.md L516](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L516)

- **`protocolVersion`** (catalog metadata) — distinct from the envelope's `version`; defaults to `"0.9"` when absent. Two version fields with different meanings is a reliable source of confusion.
[evolution_guide.md L38](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/evolution_guide.md#L38)

---

## E. Data model and binding

- ⭐ **Evaluation scope**, **Root Scope**, **Collection Scope** / **Child Scope**, **Absolute Path**, **Relative Path** — the whole path-resolution vocabulary. Whether a path is absolute is decided by a leading `/`, and relative paths only mean anything inside a template instantiation. The glossary's "Data reference" entry does not reach any of this.
[a2ui_protocol.md L835](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L835)

- ⭐ **Two-way binding** — input components write to the local data model immediately on interaction, and the write is local: it does not reach the agent until an action is dispatched. The glossary's "Data model" entry claims bidirectional synchronization without explaining that the renderer-to-agent half is action-triggered, which is the part people get wrong.
[a2ui_protocol.md L910](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L910)

- ⭐ **`DynamicString` / `DynamicNumber` / `DynamicBoolean` / `DynamicStringList`** — the `Dynamic*` family, each accepting a literal, a `path`, or a `FunctionCall`. This is what "bindable property" actually means on the wire.
[a2ui_protocol.md L128](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L128)

- **`sendDataModel`** — the per-surface opt-in that makes the renderer attach its full data model to every outbound message as transport metadata, delivered only to the agent that created the surface.
[a2ui_protocol.md L186](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L186)

- **`@index`** and the reserved **`@` namespace** — a built-in system function, available in every catalog, valid only inside template iteration. The `@` prefix is reserved protocol-wide for system context evaluation, which is a namespace rule worth recording once rather than per-function.
[a2ui_protocol.md L1230](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1230)

- **JSON Pointer (RFC 6901)** — the path syntax for every binding and for `updateDataModel.path`. Worth one line so the glossary can link out to the RFC.
[a2ui_protocol.md L835](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L835)

---

## F. Functions, validation, security

- ⭐ **`allowedCallers`** / **execution boundary** — `rendererOnly`, `agentOnly`, `rendererOrAgent`, declared in the catalog and enforced by the renderer at runtime. This is the protocol's main security surface: an `agentOnly` function cannot be bound to a component, a `rendererOnly` function called remotely is rejected with `INVALID_FUNCTION_CALL`. Note the naming problem in A.2 — pick a canonical term before writing the entry.
[a2ui_protocol.md L312](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L312)

- ⭐ **`requiresUserActivation`** / **user activation** — a function that may only run inside the execution scope of a genuine user gesture, blocking auto-invocation during render, interpolation, or reactive updates. `openUrl` is the motivating case. Currently only explained in a proposal doc, though the flag is already in the v1.0 catalog schema.
[user_initiated_functions.md L68](https://github.com/a2ui-project/a2ui/blob/main/specification/proposals/user_initiated_functions.md#L68)

- **`CheckRule`** and **`ValidationResult`** — renderer-side validation attached to input components, where a condition evaluates to `{valid, code, message, severity}`. The glossary has no vocabulary for client-side validation at all.
[a2ui_protocol.md L1036](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1036), [ValidationResult L1042](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1042)

- **Registered function** — the term the spec uses for a named, catalog-declared function referenced by name so no executable code crosses the wire. Overlaps the glossary's "Client function" but is the wording v1.0 actually uses.
[a2ui_protocol.md L1032](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1032)

- **Standard error codes** — `VALIDATION_FAILED`, `UNALLOWED_PARENT`, `UNALLOWED_CHILD`, `INVALID_FUNCTION_CALL`. A short table in the glossary would save readers hunting across three sections.
[a2ui_protocol.md L1274](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1274), [composition codes L783](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L783)

- **Pending state** / **asynchronous evaluation** — what the renderer shows while a binding waits on a function that routes to the agent, and the failure rules when it never resolves.
[a2ui_protocol.md L1430](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1430)

---

## G. Extensibility and transport

- ⭐ **Extensions** (`metadata.extensions`) — the sanctioned escape hatch from `additionalProperties: false`, with a reserved `a2ui_` prefix, reverse-domain naming for third parties, no central registry, and a MUST-ignore-unknown-keys rule. Available at four scopes (surface, component, catalog component definition, action egress).
[a2ui_protocol.md L1495](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1495), [wire containers L1509](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1509)

- ⭐ **Transport binding** — A2UI is transport-agnostic and defines a contract (ordered delivery, message framing, metadata support, optional return channel) that AG-UI, A2A and MCP each satisfy differently. The glossary mentions transports once, in passing, inside "Capabilities Object".
[a2ui_protocol.md L81](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L81), [bindings L96](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L96)

- **`application/a2ui+json`** — the official MIME type, changed in v1.0 from `application/json+a2ui`. The marker that identifies an A2UI payload inside a transport envelope.
[evolution_guide.md L77](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/evolution_guide.md#L77)

- **Extension URI** — `https://a2ui.org/a2a-extension/a2ui/v1.0`, the canonical way protocol version is negotiated over A2A.
[a2ui_extension_specification.md L9](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/extensions/a2a/docs/a2ui_extension_specification.md#L9)

- **`DataPart`** — the A2A carrier for a _list_ of A2UI messages, processed sequentially and explicitly non-transactional: one failing message does not stop the rest.
[a2ui_extension_specification.md L172](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/extensions/a2a/docs/a2ui_extension_specification.md#L172)

---

## H. Inference formats

The glossary's "Compilation" entry name-drops "Express DSL syntax" and "Elemental HTML tags" without defining either, and does not mention Atom at all.

- ⭐ **Inference format** — the category itself: a compact representation an LLM generates instead of raw A2UI JSON, compiled host-side into wire payloads. There is even a top-level `specification/inference_formats/` directory holding an Express grammar, with no glossary term covering it. The proposals themselves mostly say "DSL" instead; see A.2.
[inference_formats/express/Express.g4](https://github.com/a2ui-project/a2ui/blob/main/specification/inference_formats/express/Express.g4)

- ⭐ **A2UI Express** — positional, line-oriented DSL aimed at small on-device models; claims 55–70% fewer output tokens than JSON.
[a2ui_express.md L3](https://github.com/a2ui-project/a2ui/blob/main/specification/proposals/express/a2ui_express.md#L3)

- ⭐ **A2UI Elemental** — HTML5-like markup with Web Component custom elements, leaning on LLM pre-training over HTML and on native nesting instead of adjacency-list ids.
[a2ui_elemental.md L3](https://github.com/a2ui-project/a2ui/blob/main/specification/proposals/elemental/a2ui_elemental.md#L3)

- ⭐ **A2UI Atom** — S-expression format; parents emitted before children, unclosed parens auto-healed at EOF.
[a2ui_atom.md L3](https://github.com/a2ui-project/a2ui/blob/main/specification/proposals/atom/a2ui_atom.md#L3)

- **TTFC (time-to-first-component)** — the streaming latency metric these formats optimize for.
[a2ui_atom.md L3](https://github.com/a2ui-project/a2ui/blob/main/specification/proposals/atom/a2ui_atom.md#L3)

- **Micro-refinement loop** — the error-recovery pass that re-prompts the model on a malformed fragment rather than discarding the whole stream. Shared by Express and Elemental.
[a2ui_express.md L203](https://github.com/a2ui-project/a2ui/blob/main/specification/proposals/express/a2ui_express.md#L203)

---

## I. SDK and process vocabulary

- ⭐ **Inference SDK** — the tier that turns a catalog plus context into prompts and parses model output back into envelopes. Third of the three-tier architecture and the only one with no glossary presence at all.
[sdks_spec.md L31](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/sdks_spec.md#L31)

- **A2UI Core SDK** — protocol models, surface state, `MessageProcessor`, validation. Roughly the glossary's "Core Library" but with a different name and a wider remit.
[sdks_spec.md L19](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/sdks_spec.md#L19)

- **Catalog linter** — tooling that checks component schemas declare accessible label requirements. A named MUST in the accessibility rules.
[sdks_spec.md L28](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/sdks_spec.md#L28)

- **Incremental snapshotting** / **`ComponentNode`** — collapsing a stream of incremental updates into a flat renderable tree.
[sdks_spec.md L29](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/sdks_spec.md#L29)

- **Prompt-generate-validate loop** — the three-step cycle the protocol is designed around, where validation errors are fed back to the LLM for self-correction. Named as a section heading; a good anchor for explaining why validation exists at all.
[a2ui_protocol.md L1259](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md#L1259)

- **Feature blueprint** / **module blueprint** — the spec-driven-development document types the repo's own `blueprints/` tree is built from. Contributor-facing rather than protocol vocabulary, so possibly better in a contributing guide than the glossary.
[spec_driven_development.md L53](https://github.com/a2ui-project/a2ui/blob/main/specification/proposals/spec_driven_development.md#L53)

- **Candidate specification** — a status with a defined meaning here: implementable, feedback-gathering, high bar for breaking changes, not yet stable. Readers need it to know how much to trust v1.0.
[v1_0/README.md L5](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/README.md#L5)

---

## Left out on purpose

- Individual basic-catalog components and functions (`Text`, `Modal`, `formatCurrency`, `pluralize`, …) — that is catalog reference material, and [the implementation guide](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/basic_catalog_implementation_guide.md) already covers it.
- v0.8/v0.9-only terms now removed — `theme`, `primaryColor`, `client`/`server` naming, `callFunction`. Only worth glossary space if the glossary starts carrying deprecations.
- Borrowed terms with authoritative external definitions — JSON Schema, WAI-ARIA, S-expression, SSE. Link out rather than redefine.
- Eval and test tooling (Genkit, `ajv`, wireit) — repo infrastructure, not protocol vocabulary.

## Open question

Sections A and H raise the same issue from two directions: several of these terms exist in the glossary under older names, or in proposals that may never ship. Adding a proposal's vocabulary to the glossary implies more commitment than a proposal has. It may be worth marking entries with a status — stable / candidate / proposed — rather than deciding case by case what is glossary-worthy yet.