Distilling Domain Language

The workshop, not the maintenance habit. Run an intensive interrogation to decide what a domain concept should be called - whether you are naming it for the first time or reopening a word the domain has outgrown - then hand the verdict to the domain-modeling skill to write into CONTEXT.md. That sibling owns the steady-state glossary and ADRs; do not write CONTEXT.md yourself here.

This is a grilling protocol: you drive it with named moves, one question at a time. But talk alone reaches false agreement - people nod at a word while meaning different things. So the instant a term resists, externalise the fight into a small forcing artifact (a scenario table, a hotspot register, a Given/When/Then). The artifact makes the contradiction impossible to hand-wave.

When to run

• A new concept, feature or project needs its language chosen before names harden into code, schema and copy.
• A term fights its own definition ("a group invited together - but some are friends, not a household").
• Several words compete for one concept and nobody has decided.
• A glossary has bloated; terms feel loosely related.

The same moves serve both entry points: a brand-new coinage earns the exact grilling a disputed veteran does - it just starts with a clean sheet instead of a fight. Targets are not only nouns: verbs, states and lifecycle words (submit, pending, reopened) are domain language too and take the same grilling. Nor need the domain be a codebase - the same workshop distils the language of a business process, a policy or a book.

Ground rules