Skip to content

Brand Voice and Editorial Style

Terminology Decision Log

Record an approved term, definition, audience, context, variants, rationale, source authority, owner, localization notes, and reconsideration trigger.

Free editable Markdown · Terminologists, technical writers, and editorial teams ·

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Concept and evidence

Decision ID
[Durable identifier]
Concept
[What requires a term?]
In scope
[Included meanings]
Out of scope
[Excluded meanings]
Audience
[Who encounters it?]
Contexts
[Interface, help, legal, technical, campaign, or another]
Current confusion
[Observed problem]
Authoritative sources
[Links and dates]
Decision owner
[Role]

Term decision

Approved term
[Preferred form]
Definition
[Plain, testable meaning]
First-use treatment
[Definition, expansion, or none]
Abbreviation
[Allowed form and context]
Capitalization and forms
[Plural, possessive, verb, or another]
Discouraged variants
[Term and reason]
Required formal term
[If plain language must appear beside it]
Context exception
[Where another form is correct]
Rationale
[Accuracy, recognition, consistency, or risk]

Language and implementation

Localization note
[Concept, constraints, and terms not to translate literally]
Regional note
[Different meaning or accepted form]
Pronunciation or spoken use
[If relevant]
Affected locations
[Interfaces, pages, schema, training, and assets]
Migration owner
[Role and due date]
  • Historic quotations and external proper names are handled correctly.
  • Search-and-replace will not alter unrelated meanings.
  • Translators can access concept and context, not only the English label.

Approval and review

Approved by
[Qualified owner]
Effective date
[YYYY-MM-DD]
Adoption evidence
[Audit or sample]
Open issue
[Question and owner]
Review trigger
[Product, policy, community, or language change]
Superseded decision
[Previous log ID or None]

How to use this template

  1. Describe the underlying concept, scope, ambiguity, and source authority before comparing candidate terms.
  2. Evaluate candidates for accuracy, audience recognition, context, connotation, accessibility, and translation.
  3. Record the approved term, definition, forms, discouraged variants, exceptions, rationale, and approver.
  4. Map affected interfaces, pages, systems, localization assets, and migration ownership.
  5. Publish examples, verify adoption, and reopen the decision when its documented trigger occurs.

Define the concept before choosing the label

Start with the thing, state, action, or relationship that needs a name. Record what belongs inside and outside the definition and where confusion currently occurs. Teams often debate synonyms while holding different concepts in mind. Link the authoritative product, policy, domain, or community source and note its effective date. If no authority exists, label the definition as an editorial convention rather than a universal fact. Separate the official term used in a contract or interface from a plain-language explanation readers may recognize more easily.

Decide by context and audience

One term may be appropriate in an interface label, technical reference, customer explanation, search metadata, or legal notice but not all of them. Record the audience’s prior knowledge, the cost of misunderstanding, space constraints, translation, pronunciation, accessibility, and regional connotation. Include accepted abbreviations, capitalization, plural, verb forms, and first-use treatment. Discouraged variants need reasons: ambiguity, inaccuracy, stigma, collision with another feature, or obsolescence. A do-not-use ruling without an explanation invites workarounds and makes future reconsideration harder.

Give the decision a lifecycle

Name who approves the term, where it must be updated, and what happens to old content. Search for interface strings, help pages, schemas, campaign assets, training, and localization memories that depend on it. Define whether historic quotations or external names remain unchanged. Communicate the decision with examples, then check actual usage rather than assuming publication of the log creates adoption. Reconsider after product changes, community guidance, legal updates, repeated reader confusion, or localization feedback. Preserve earlier decisions and effective periods instead of silently rewriting the record.

See the fields in context

Fictional example: “workspace”

Lantern Draft is an invented collaboration product.

  • Concept: The top-level fictional container that holds projects, members, and billing settings.
  • Approved term: “Workspace”; define it on first use in administrator help.
  • Discouraged variant: “Account,” because an individual account can belong to several workspaces.
  • Interface exception: The legal billing document uses the formal “service organization” defined by the fictional contract.
  • Review trigger: Reconsider if personal projects become available outside a workspace.

Frequently asked questions

Is the most common term always the best choice?

No. Familiarity matters, but a common term may be ambiguous, inaccurate, stigmatizing, or incompatible with a required definition. Document the tradeoff and use a plain explanation beside a necessary formal term.

Should old content be updated immediately?

Prioritize by consequence, reach, search confusion, and dependency. Critical interfaces and canonical explanations may need coordinated release; low-risk archives can follow a migration plan. Preserve quotations and historic titles where alteration would be misleading.

Can one global termbase cover every language?

It can preserve concepts and relationships, but each locale needs reviewed terms, grammar, connotation, and usage examples. Do not force a literal English label where another language expresses the concept differently.

Who should approve identity-related terminology?

Consult current guidance and people with relevant lived and professional context, while following applicable editorial and legal duties. Record scope and date because preferred language can vary and evolve.

File details

File name
terminology-decision-log.md
Format
Markdown (.md)
Size
3 KB
Designed for
Terminologists, technical writers, and editorial teams

Usage note: Use this log for decisions that affect repeated public or internal language, not every ordinary word choice. Confirm regulated, legal, scientific, product, and identity-related terms with qualified owners. A preferred English term is not automatically an approved translation; keep language-specific decisions and regional context visible.