The policies it ships with

People and their agents follow these when they record in a collection made from this template. Its owners can change them.

1. A node belongs in a glossary when it defines exactly one term. Each Reference is one entry: its prose is the headword (the word being defined) and its `definition` gives the meaning. PASS when the candidate names and defines a single concept a reader of this domain would look up. FAIL only when it bundles several unrelated terms into one entry, is a passing note, task, or decision record rather than a definable term, or carries no definable concept at all.
2. Only Reference and Principal belong in a glossary. Each term is a Reference — its prose is the headword and its `definition` carries the meaning; Principals are the stewards who own terms. A process step, decision record, or free-form note belongs in its own collection.
3. Only these edge types may be used in a glossary: `relates_to` (see-also between related terms), `has_parent` (place a narrower term under its broader term or category), `replaces` (a preferred term supersedes a deprecated one), and `attributed_to` (name the Principal who stewards the term). A term cites its source inline in its `locator`, not via an edge.
4. Every committed (`queued` or `active`) term carries a `definition` — a headword with no meaning is not yet an entry. A `drafting` stub may capture the word first and fill in the definition later.
5. Check the term's `definition`. PASS when it is a concise, self-contained explanation of the concept (roughly one to three sentences) in plain language: it states what the concept *is* — its category and what distinguishes it — and could stand in for the headword in a sentence. FAIL with a reason when the definition is circular (it defines the term using the term itself), is merely an example or a bare synonym rather than an explanation, is empty or a placeholder, or rambles well beyond a few sentences.
6. Keep one entry per concept. Give each concept a single canonical entry under its preferred term, and do not create a second entry for the same idea. When two words mean the same thing, keep the preferred one as the entry and record the others as synonyms on it.
7. Record synonyms and deprecated variants as `alternatives` on the canonical entry, not as separate terms. Each alternative is `{ name, note }` (or `{ name, rejected_because }` to mark a form readers should stop using), so a reader who looks up a synonym still lands on the one real definition.
8. Keep the headword bare: put only the term in the prose and the meaning in `definition`. Don't restate the term inside its own definition (no circular definitions), and don't fold the part of speech, pronunciation, or source into the headword.
9. Cross-reference related concepts with `relates_to`, and place a narrower term under its broader term or category with `has_parent`, so the glossary reads as a connected vocabulary rather than a flat list of isolated words.
10. When a new preferred term replaces an old one, retire the old entry (lifecycle `retired`) and link the new term to it with a `replaces` edge (the `supersede` changeset op creates the replacement and the edge together), so a reader who looks up the old word is redirected to the current term instead of finding two live definitions.
11. Cite where a definition comes from when it is drawn from an external standard, contract, or document: put the citation in the term's own `locator` (a URL, standard number, or document id). Source provenance is a property of the entry, not a separate node.
12. Name a steward by attributing a term — or the glossary's anchor terms — to a Principal with an `attributed_to` edge, so there is a clear owner accountable for reviewing and approving changes. A glossary is a living document; it needs someone to keep it current.
13. Walk a term through the lifecycle as it matures: `drafting` while you are still capturing or wording it, `queued` once it is ready for review, `active` when it is the approved, in-force definition, and `retired` when it is deprecated or superseded. Completeness and quality rules apply once a term is committed (`queued` or `active`); a `drafting` stub may be incomplete.
14. Agents: read `GET /<handle>/api/authoring-contract.json` and write entries with `POST /<handle>/api/changesets.json` — create each term as a Reference with its `definition` (and any `alternatives`, plus a `locator` when citing a source), and add its `relates_to` / `has_parent` / `attributed_to` edges in the same changeset rather than as disconnected nodes.