Process & Registry

Amoleo Terminology

The family glossary — the shared brand vocabulary for words that shouldn't drift between products, or between two people writing about the same product. Each entry follows the structure in TerminologyTemplate.md; read that doc first for the shape of an entry and the rules for what earns one.

This is a working list, not a finished one. The first pass (8 Sept 2026) swept every repo's docs against the inclusion rules; the entries below are the ones confirmed since, including two that needed an actual brand decision rather than just documentation (Connections' "board" vs. "map," and the family's standard content-curation role name).

Amoleo · Registry

Entry

Product: Amoleo Registry (the canonical record — referenced from Editions, Collections, Upnext, Reviews, and Worldbook) Category: Product noun

Correct usage:

• "Search the Registry for the Entry you want, then add one of its Editions to your Collection."
• "Every Registry Entry can have multiple Editions catalogued under it in Amoleo Editions."

Incorrect usage:

• "Search for the title you want to add." — the deprecated form; see Notes.

Notes: Renamed from Title on 8 Sept 2026, specifically to stop colliding with "title" the everyday word for a work's own name — under the old name, a sentence like "search by title for the Title" was unreadable. Capitalize when referring to the Registry entity. Amoleo-Registry's own docs/Architecture.md still says "Title" as of this rename — propagating the rename into that doc (and anywhere else it's used the old term) is an open follow-up, not yet done.

Amoleo · Editions

Edition

Product: Amoleo Editions (the entity the product manages — also referenced from Amoleo Collections and Amoleo Upnext) Category: Product noun

Correct usage:

• "A UK 2020 UHD Blu-ray and a US 2019 Blu-ray of the same film are two Editions catalogued in Amoleo Editions."
• "Add this Edition to your Collection."

Incorrect usage:

• "Add this edition of the film to your collection." — lowercase, reads as the generic English word rather than the specific entity.

Notes: Capitalize when referring to the entity. Keep "an Edition" (one specific release) visibly distinct from "Amoleo Editions" (the product) — the product name always carries the full Amoleo Editions form, never a bare "Editions" standing in for the entity's plural.

Amoleo · Collections

Collection

Product: Amoleo Collections Category: Product noun

Correct usage:

• "Add this Edition to your Collection."
• "A user's Collection holds the Editions they've marked as owned."

Incorrect usage:

• "Add this to your collection on Amoleo · Collections." — redundant prefix, and lowercase.

Notes: Capitalized, possessive ("your Collection", "a user's Collection") — same idiom as Worldbook below: one Collection per user account, never pluralized for a single user's own holdings. Drop the Amoleo prefix once inside the product's own copy, same rule every other product follows.

Amoleo · Upnext

Backlog

Product: Amoleo Upnext Category: Product noun

Correct usage:

• "Every user gets a system-provisioned {user}'s Backlog — the Video Games list."

Incorrect usage:

• "Check the backlog for what's next." — reads as the generic word, or as one of the family's own GitHub Projects backlog boards.

Notes: Capitalized, possessive, and specific to Upnext's own Video Games list — the counterpart to Watchlist below for Film/TV. This is the most collision-prone term in the family: nearly every repo already has its own engineering "backlog" (lowercase, an unrelated GitHub Projects board). Never capitalize that one; always capitalize this one.

Watchlist

Product: Amoleo Upnext Category: Compound phrase

Correct usage:

• "TV and Film are separate lists — {user}'s Film Watchlist and {user}'s TV Watchlist — not one shared Watchlist."

Incorrect usage:

• "Your watch list." — two words, and drops the media-type qualifier the design deliberately keeps split.

Notes: One word, capitalized, always paired with a media-type qualifier and a possessive owner ({user}'s ___ Watchlist) — never a single combined "Watchlist" spanning media types.

Amoleo · Worldbook

Worldbook

Product: Amoleo Worldbook Category: Product noun (branded replacement for a generic word)

Correct usage:

• "Add this character to your Worldbook."
• "A user's Worldbook holds both their public and private entries."

Incorrect usage:

• "A user's workspace on Amoleo · Worldbook."
• "Your Worldbook workspace."
• "Your Amoleo Worldbook collection."

Notes: Always capitalized, never used with an article the way a generic noun would be ("a Worldbook" only in the general/plural sense — referring to one specific user's own, it's always possessive: "your Worldbook", "a user's Worldbook", never "the Worldbook"). Not pluralized for one user's content — a user has one Worldbook, not several. Drop the Amoleo family prefix once inside product copy or when speaking from the user's point of view, the same rule every other product follows in its own UI (Pets doesn't say "the Amoleo Pets app" inside Pets itself).

Written Work

Product: Amoleo Worldbook Category: Product noun (branded replacement for a generic word)

Correct usage:

• "Write a new story" (the UI verb, fine as ordinary English) but "This Written Work has 3 published versions" (the entity name).

Incorrect usage:

• "Add a new Story to your Worldbook." — the exact drift this entry exists to prevent.

Notes: Capitalized as a two-word compound when naming the entity. Chosen over "Story" specifically to encompass scripts, novellas, and other forms a single "story" wouldn't cover. The underlying schema's own storyType field name is an internal mismatch and should never leak into user-facing copy.

Public Worldbook / Private Worldbook

Product: Amoleo Worldbook Category: Compound phrase

Correct usage:

• "Browse public Worldbooks" (general/plural sense) vs. "This Worldbook is public" (a state) vs. "a Public Worldbook" (the curated, editor-managed category).

Incorrect usage:

• Treating "public"/"private" as a plain adjective on "Worldbook" without the compound's specific meaning — a Public Worldbook is curated by editors; a Private Worldbook is user-owned original work. Neither is just an access-level toggle.

Notes: Both words capitalized when naming the type of Worldbook — distinct from the lowercase visibility field, which has its own finer states (public-listed, public-unlisted, private).

Amoleo · Connections

board

Product: Amoleo Connections Category: Product noun

Correct usage:

• "Your board is wherever you sign in."
• "Save changes to your board."

Incorrect usage:

• "Make my map public." — a stray, inconsistent term for the same object, still live in Connections' own sharing-settings copy as of this decision (8 Sept 2026).

Notes: Lowercase by existing convention — unlike Worldbook's capitalized style, Connections' own copy already reads "your board" throughout, not "your Board." Decided over "map" because it was already the dominant usage (3–4 occurrences vs. one). Amoleo-Connections' sharing-settings copy still says "map" as of this decision — fixing that one line to match is an open follow-up, not yet done.

Family · Roles

Editor

Product: Family (standard role name — Amoleo Upnext, Amoleo Worldbook, Amoleo Editions; referenced from Amoleo Reviews' approval flow) Category: Role/persona name

Correct usage:

• "Editors decide what lists get published." (Upnext)
• "Editors can create and modify content but cannot delete the Worldbook." (Worldbook)
• "An Editor can create and edit Edition/SpecialFeature/SyncPoint records." (Editions, renamed from Contributor 8 Sept 2026)

Incorrect usage:

• "Contributor" for this same role — Amoleo Editions used this name until 8 Sept 2026; its own docs/Architecture.md has been updated to match.

Notes: Decided 8 Sept 2026 over "Contributor" for two reasons: it was already the majority usage (Upnext, Worldbook, and Reviews' own "Editor-approved reviews" all independently landed on it), and it better matches the permission actually being described everywhere — direct authority to create/modify/publish, restricted from deletion or admin control, not a submission that waits on someone else's approval (which is what "Contributor" usually implies). This is the standard name for this role family-wide. A product is still free to have genuinely specialist roles of its own beyond this one (e.g. Editions' separate "additional moderator tier," still an open question in its own doc) — standardizing the common role doesn't require flattening every role a product needs.

Cross-Product Phrases

In My Collection / Add to Collection

Product: Family (Amoleo Editions ↔ Amoleo Collections) Category: Compound phrase

Correct usage:

• "A page should show 'In My Collection' instead of 'Add to Collection' if the signed-in user already owns the specific Edition being viewed."

Incorrect usage:

• "Already Owned" / "You have this." — paraphrases that break the exact-string pairing the cross-product contract depends on.

Notes: Fixed strings, not to be paraphrased — one is the designed toggle-state replacement for the other, and Editions and Collections must render the exact same pair. Edition-specific, not Entry-level: owning one release doesn't hide the button on a different release's page. See Amoleo-Editions/docs/Architecture.md and Amoleo-Collections/docs/Architecture.md, both under "In My Collection."

Status

No checker exists for this doc yet — same idiom as family-seo.md and family-accessibility.md: the policy is written down before the tooling to enforce it exists. Until one does, treat this list as the reference to check new copy against by hand, and add an entry here the moment a term meets the inclusion rules in TerminologyTemplate.md — the earlier a term is recorded, the fewer places its generic, un-styled form has already spread to.

The template

Terminology Template

The family glossary (docs/terminology.md) is a flat list of terms, but every entry follows this structure — the same idea as MissionStatementTemplate.md: one shape, applied consistently, so a term is quick to look up and quick to add.

Entry Structure

Term

The exact styled form of the word or phrase, as it should appear in copy — capitalization included. This is the heading of the entry.

Example: Worldbook

Product

Which repo the term belongs to, or Family if it applies across more than one product (e.g. a naming pattern, not a single product's own noun).

Example: Amoleo Worldbook

Category

One of:

• Product noun — a generic-sounding word we've deliberately replaced with the product name itself (a user's workspace becomes a user's Worldbook).
• Feature name — a named feature inside a product, distinct from the product noun above (e.g. a specific tool or view within an app).
• Compound phrase — a fixed multi-word phrase that shouldn't be paraphrased (e.g. always "In My Collection", never "Already Collected").
• Role/persona name — what we call a type of user or contributor (e.g. "editor" vs "curator" vs "contributor" — if a product distinguishes these, the distinction is a glossary entry, not tribal knowledge).

Correct Usage

One or two example sentences showing the term used the way we want it.

Example: "Add this character to your Worldbook."

Incorrect Usage

The mistake this entry exists to prevent — the generic or over-literal phrasing someone would reach for without the entry.

Example: "Add this character to your workspace on Amoleo · Worldbook."

Notes

Anything a writer would otherwise have to guess: capitalization rules, whether the term takes a possessive ("a user's Worldbook", not "the Worldbook of a user"), whether it's ever pluralized, whether the Amoleo family prefix is dropped once inside that product's own copy (it usually is — we don't say "the Amoleo Pets app" inside Pets' own UI), and any article rule ("a Worldbook" vs "the Worldbook").

Rules for Inclusion

Not every noun a product uses needs a glossary entry. A term earns one when at least one of these is true:

1. It's a branded replacement for a generic word. We've decided to use the product name itself in place of an ordinary English word for the same concept (workspace → Worldbook). Without a written rule, half the copy in the family will drift back to the generic word, because it's the more natural thing to type.
2. It has a non-obvious styling rule. Capitalization, possessive form, hyphenation, pluralization, or when to keep vs. drop the Amoleo prefix — anything a writer could reasonably get wrong without being told.
3. It's used in more than one piece of copy. A word used exactly once, in one place, doesn't need a shared rule — there's nothing to keep in sync. (If it later shows up a second time, that's the moment to add it.)
4. It collides with an everyday English word and needs disambiguation. E.g. "Collection" the Amoleo Collections feature vs. "collection" the ordinary noun — copy that mixes the two without a rule reads as sloppy or confusing.

What doesn't qualify: internal-only engineering names — variable names, service names, database collection names, internal API routes — that never reach user-facing copy. Those belong in that repo's own docs (its Architecture.md or equivalent), not the family glossary. The glossary is for words a user reads, not words a developer reads in the codebase.

Why This Structure

• Term + Product + Category make an entry findable and scoped — a reader can tell at a glance whether a rule applies to the phrase they're about to write.
• Correct / Incorrect usage side by side is the fastest way to transfer a styling rule — faster than a paragraph of prose, and it's the same before/after idiom docs/family-docs-pointer.md and the docs-site itself already use for other specs.
• Notes catches the residue that doesn't fit the other fields — possessives and articles are exactly the kind of small thing that's easy to get right once and then drift on the next paragraph someone else writes, the same failure mode this whole repo exists to catch.

A term without this structure is just a comment in someone's memory. The first time two people write about the same feature and pick different words for it is the moment this doc exists to prevent.

Generated from docs/terminology.md + docs/TerminologyTemplate.md. Edit there and re-run npm run build in docs-site-src/ — never hand-edit a page.