Vocabulary collision ledger
Type: types/note.md
The vocabulary invariant says no unqualified term carries two load-bearing senses across artifacts that can co-load; the rationale is in load-bearing vocabulary collisions should be prevented or visibly scoped at write time. Not every double sense is load-bearing. This ledger records the ones judged weak enough to tolerate, so that a writer choosing a term reads the decision instead of re-deriving it, and so that the corpus audit the collision note names as its detection instrument has a list of suspects.
A row is added when a workshop, review, or write finds two senses and decides not to rename. A row is removed when the term is renamed, defined, or retired; the commit that does so says why. The write-time collision controls proposal leaves open whether reservation should be graded; this ledger is the hand-curated form of the graded rows until a registry exists.
| Term | Senses and where each lives | Why the collision is weak | Decision for new text | Escalation trigger | Recorded |
|---|---|---|---|---|---|
| worker | Delegation: an agent that receives a packet and works inside a parent's authority (AGENTS.md Delegation, kb/types/instruction.md, skills). Ordinary: any resource-bounded person or agent doing work. |
The senses sit on surfaces that rarely co-load (operating instructions versus theory), and the sentence usually disambiguates. | Use "worker" only in the delegation sense. For the ordinary sense write "actor" or the specific noun. | An instruction or theory note needs the ordinary sense as a load-bearing noun, or a misresolution is observed in a run. Renaming the delegation sense to "sub-agent" is not the fallback: an inventory (2026-10-30) found the delegation sense spans harness sub-agents and headless processes that ADR 086 and ADR 118 define as not sub-agents, with about 450 live lines, code identifiers and frozen worker: keys. A fallback needs a role word distinct from both. |
2026-10-30, kb/work/open-ended-work-economics |
| allocation | Function allocation: which decision-bearing functions humans or computation supply (reallocation note). Search allocation: distributing search across branches (allocation note). Effort allocation: dividing effort among investments. | All three allocate something, and naming the object disambiguates. | Always name the object: "function allocation", "search allocation", "effort allocation". | A bare "allocation" appears in a title, definition, or frontmatter description with one sense assumed. | 2026-10-30, same workshop |
| provisional | Technical: the status of a branch choice that backtracking can revoke (backtracking note). Everyday: hesitant or temporary, which the tentative theory definition excludes from "tentative". | The technical use predicates a search judgment and is linked at its source. | Use "provisional" only of search judgments. Theories are "tentative"; retained commitments take no adjective. | "Provisional" is predicated of a theory or a retained commitment in a library note. | 2026-10-30, same workshop |
| operational | Lineage: operationalized-from, the methodology-to-procedure edge (ADR 054). External: programming-language operational semantics, rules specifying program transitions (Plotkin); operationalism, meaning by measuring operations (operationalism). Ordinary: making something usable in practice. |
The formal link label occupies a declared slot; external senses name their discipline. None supplies the Commonplace criterion for symbolic form. | Use operationalized-from only as a link label; gloss external senses on first mention with the ingest. For symbolic membership use representational form, and for the move use codification, following ADR 124. Do not use bare "operational" as an unregistered technical synonym for either. |
A reader confuses the symbolic membership criterion with programming-language operational semantics or measurement operations. | 2026-11-02 |
| projection | Ordinary: an executor's silent collapse of a permitted set to one outcome, formerly the central term of progressive constraining and its neighbours, now reworded there. Context view: the active-context projection in context-operation interface. LLM-call projection in the select/call lemma. Skill projection: installed copies of skills in install docs. Mathematical: linear and idempotent maps onto a subspace. | The executor sense was defined only in a note since deleted, and its uses read as metaphor; the other senses name their object. | Keep projection as ordinary language. For the relation between a permitted set and an artifact inside it use program refinement; for an executor's unchecked output write "candidate refinement". Do not write "projection model" or "valid projection". | A note relies on a mathematical property of projection, such as linearity or idempotence, to carry an argument. | 2026-11-04, kb/work/prompt-semantics-rewrite |
| refinement | Technical, compound only: program refinement, the ordering under which one artifact's permitted behaviors lie inside another's. Ordinary: prompt refinement, note refinement, in-place refinement, meaning iterative improvement, in about forty-five library files. Theory refinement: the EITHER and FORTE repair line cited by addressable theory. | The technical sense is always written as the compound, and iteration is never called "program refinement". | Write "program refinement" or "refinement step" for the technical relation and never the bare word. Bare "refinement" stays ordinary English for iteration. | A bare "refinement" is used for the narrowing relation in a title, definition or description, or "program refinement" is used for editing toward a better artifact. | 2026-11-04, same workshop |