Lexicon

Maintain a small, opinionated vocabulary for concepts humans and agents must understand consistently. Treat terminology disagreements as possible disagreements about the domain model, not merely word choice.

Prevent terminology drift, invented vocabulary, obsolete conceptual framings, and synonym bloat.

Invariants

• One term per concept: Keep one canonical term; reject generic terms and speculative synonyms. Never invent a compromise name that fuses competing alternatives.
• Evidence-based: Admit terms grounded in code, documentation, schemas, project history, or relevant external sources.
• Terminology authority: The lexicon governs terminology. Ground definitions in established project meaning; do not use entries to introduce or adjudicate architecture, implementation choices, or project status. Surface unresolved domain decisions to the user.
• Boundaries, not specs: Include only the facts needed to identify a concept and distinguish easily confused neighbors; do not turn entries into procedures or miniature specifications. Link to authoritative documentation for implementation, operational details, and decision history.
• Definition test: Could this fact change while the term still meant the same thing? If so, omit it from the definition and link to its authoritative source when useful. Retain conditions, relationships, or lifecycle facts only when necessary to distinguish the concept.
• User authority: Let the user adjudicate conceptual conflicts. Never silently pick a winner or reopen explicit decisions.

Workflows

Select based on user intent (ask if ambiguous):