Vocabulary

Vocabulary registry

Status: normative. Document version 1.0-draft-1.

core.json is generated from the schema package. It contains every admitted v1 key, its closed value schema, supported disclosure levels, renderer operations/examples and policy flags. This page explains the 30-key vocabulary 1.1 release boundary and its compatibility with the original 27 keys. Unknown and future candidate keys are rejected; there is no implicit free-text fallback.

The viewing, reading and music domains form the named group media (groups.media in core.json). The group is a label for documentation and the worked example; it adds no key, level or permission.

The normative core vocabulary version 1.1 contains 30 keys across 17 domains. Each key has a closed value schema, semantic kind, cardinality, supported levels, closed L0 category, safety/sensitivity/inference flags, advertising eligibility, label, explanation and example renderer output at every supported level.

Renderer operations are closed: category emits only the L0 code; identity emits the already-validated value; pick_first emits only first; approved_override_or_omit emits the person's approved identifier-safe L1 rendering or omits the entry. L2 free text uses the same safe rendering. No generic redactor or language model supplies a substitute. Stored type describes the source; a rendered entry's type describes the actual rendering (for example text for L0 or an approved override).

Safety and special-category values cannot be inferred. Advertising is limited to person-confirmed viewing.genre_affinity, reading.genres and music.genres, with the additional A6.7 controls. The vocabulary's closed lists deliberately exclude broad free text from that lane.

All other keys from earlier proposals, including clinical coding, account/loyalty details and arbitrary extensions, remain candidates outside this release. Import must report unsupported values before committing. This is an explicit first-release boundary, not a permissive catch-all schema. No semantic compatibility with IPS, SNOMED, ISO 24751 or other domain standards is claimed without a separately reviewed mapping.

Checks: DISC-01, ADS-01, CONTRIB-01, PORT-01.

Vocabulary 1.1 additions

introduced_in records the first vocabulary version containing each key. The original 27 keys remain version 1.0 keys with unchanged value and disclosure semantics. Vocabulary versions are independent of wire version 1.0 and document version 1.0-draft-1.

• agent.always_do is a single preference containing 1-1024 characters of explicitly confirmed instruction text. It is not inferable. L0 is agent_context; L1/L2 require the person's approved identifier-safe rendering; L3 is the saved text. It grants no permission and cannot override safety rules or consent. Conflicting positive and negative instructions require the person's resolution; positive wording is not higher authority.
• agent.explanation_depth has values overview (main point), reasons (main point and why) and walkthrough (explain the steps). It controls explanation depth/structure, while agent.verbosity controls length. It neither requests nor promises private model reasoning. L0 is agent_context; L1-L3 return the exact enum value.
• communication.spelling has values en-GB and en-US and applies only to English replies. It explicitly overrides an English language tag's spelling convention; it does not choose the reply language. Without it, the language tag and recipient's ordinary conventions apply. It does not rewrite quotations, proper names or code. L0 is communication_context; L1-L3 return the exact enum value.

All three are single-cardinality ordinary preferences, support L0-L3 and ordinary temporal overlays, and are not safety-critical, special-category or advertising-eligible. The two enums are inferable under the existing provenance rules; always_do is not. Free text can nevertheless contain sensitive details or identifiers. Absence creates no default stored preference. Freshness follows A4.3's 365-day confirmation rule.

A provider MUST NOT widen an existing grant merely because its vocabulary catalogue gains keys. It MUST retain the vocabulary version approved for that grant and the version supported by the recipient, and expose only their supported, authorised intersection. Missing version evidence means the original 1.0 key set. This restriction applies at every level, including L0, and to dependencies and temporal deadlines. Grant approval and recipient support for 1.1 must both be established before returning a new key. The reference library accepts these as trusted internal snapshot inputs; no new discovery or token field is implied. Runtime negotiation, consent persistence and cross-surface verification remain release gates.

Checks: VOCAB-1.1-01 to VOCAB-1.1-09, DISC-01, TEMP-01 to TEMP-03. Synthetic entries are included under pilot_vocabulary in protocol examples.

References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.