Terminology

A project glossary answers three questions per concept: which name the project uses, what it means here, and what others call it. It is a short lookup table, not a writing guide. Terms stay in the field's standard language, usually English; meanings are written in the reader's language.

Lookup is the ordinary path: read the glossary and apply it. It is cheap, writes nothing, and never starts a source survey. Curation is the second path and runs only under the conditions in "When to curate" below.

Lookup

Read root terminology.md and only the topic files the task touches. Use each adopted name with its recorded meaning in answers, documents, and code explanations. Keep confirmed local names for their recorded audience, and honor wording decisions within their scope and exceptions. Quotations, code identifiers, APIs, and data labels keep their original form.

When the user asks about a term, answer with the adopted name, its meaning here, what other sources call it, and the reference.

A field term with no row is usually undisputed: use it in its standard sense and move on. When the task needs a name the glossary does not settle, describe the thing plainly, and keep an unconfirmed local name as observed without asserting its meaning. A project without terminology.md has nothing to look up; curation creates one only when a curation condition holds.

When to curate

Curate only when the current task needs the name and one of these holds: