Brand Voice and Editorial Style
Editorial Style Exception Log
Document a justified exception to house style with its context, scope, rationale, authority, examples, localization impact, expiry, and reconsideration trigger.
Free editable Markdown · Copy chiefs, editors, and localization teams ·
Accessible HTML preview
Blank template
The downloaded file contains the same fields in editable Markdown.
Exception identity
- Log ID
- [Durable identifier]
- Style guide and version
- [Link and date]
- Normal rule
- [Quote briefly]
- Conflict context
- [Where it fails]
- Reader or workflow effect
- [Why the departure matters]
- Requester
- [Name or role]
- Style owner
- [Authorized decision role]
Scoped decision
- Exception
- [Approved departure]
- Applies to
- [Asset, channel, product, term class, or locale]
- Does not apply to
- [Boundary]
- Correct example
- [Use in context]
- Incorrect expansion
- [What remains disallowed]
- Rationale
- [Clarity, accuracy, respect, usability, or another]
- Effective period
- [Start and expiry]
Implementation
- Existing content action
- [Keep, migrate, or audit]
- Localization impact
- [Language-specific treatment]
- Automated check impact
- [Rule suppression or message]
- Communication
- [Audience and channel]
- Migration owner
- [Role and due date]
- The exception does not alter a mandatory external requirement.
- Related terminology and naming decisions are linked.
- Contributors can find it using likely search words.
Review
- Approved by
- [Name or role]
- Approval date
- [YYYY-MM-DD]
- Audit result
- [Sample and finding]
- Review trigger
- [Confusion, recurrence, guide update, or locale feedback]
- Outcome
- [Close / Renew / Narrow / Formal policy change]
How to use this template
- Cite the current rule and demonstrate the specific context in which it creates a material problem.
- Confirm that the authorized style owner—not an unrelated requester—owns the decision.
- Define the smallest useful scope, examples, exclusions, effective period, and affected content.
- Record approval, localization and tooling implications, communication, and migration work.
- Audit use and either close, renew, narrow, or convert the exception into a formal guide revision.
Identify the real conflict
Quote the current style rule and show the exact context where applying it would reduce clarity, accuracy, usability, respect, or required consistency. Confirm that the issue is truly style rather than terminology, product naming, legal wording, or a technical limitation owned elsewhere. Include a before-and-after example. “It sounds better” is weak evidence; explain the reader or workflow effect. A vendor’s capitalization, a community’s self-identification, a compact interface, or a translated grammar pattern may justify a scoped exception without weakening the general standard.
Choose the right level
Decide whether the exception applies to one asset, a content type, a channel, a product, a language, or a defined class of terms. Avoid granting a global departure to solve one edge case. Record when it starts, whether existing content changes, and how editors should handle related but unlisted situations. If the conflict recurs broadly, propose a style-guide revision instead of accumulating exceptions. Link related decisions so contributors do not interpret several narrow approvals as an unwritten replacement rule.
Make the exception discoverable
Add approved and incorrect examples, search terms, tags, owner, expiry, and review trigger. Tell affected editors and localization teams where the exception lives. Automated checks should suppress or explain the flagged case rather than forcing contributors to ignore every warning. Audit a sample after adoption. If writers apply it too widely, clarify the boundary; if no one can follow the normal rule anymore, review the rule. Preserve expired decisions so older content can be interpreted.
See the fields in context
Fictional example: lowercase vendor command
“nimbus sync” is an invented command and vendor convention.
- Normal rule: Product names use title case.
- Conflict: The fictional command is case-sensitive and officially appears as `nimbus sync`.
- Exception: Preserve lowercase in code and command references; use “Nimbus” for the surrounding fictional product.
- Boundary: Marketing headings still follow the normal product-name rule.
- Trigger: Close the exception if the command syntax changes.
Frequently asked questions
How is this different from an editorial policy exception?
This log handles house-style presentation decisions. A policy exception addresses a broader operational or standards requirement and may need risk controls. Escalate when the issue affects more than style.
Can an editor approve their own exception?
Only if governance explicitly grants that authority. Recurring or cross-channel exceptions should normally go to the style owner so decisions remain consistent and visible.
Should an exception have an expiry date?
Yes, or at least a concrete review trigger. Product, platform, language, and guide changes can remove the original need. An indefinite exception still requires an owner and scheduled review.
What if localization needs a different rule?
Create a language-specific decision with local examples and qualified review. Do not treat natural grammatical differences as errors against English style, and do not generalize one locale’s exception globally.