Consistency Standards and Enforcement

technical-writing

consistency

style-guides

terminology

automation

quality-assurance

Establish and enforce documentation consistency across terminology, structure, tone, formatting, and cross-references through glossaries, style decision logs, audit checklists, and automated tooling

Author

Dario Airoldi

Published

January 14, 2026

Consistency Standards and Enforcement

Transform consistency from an aspiration into a measurable, enforceable standard across your documentation

🎯 Introduction
📊 Dimensions of consistency
📖 Building a project terminology glossary
📝 Style decision log
📋 Consistency audit checklist
🤖 Automated consistency enforcement
🔗 Cross-document consistency patterns
🔄 Handling consistency during migration and evolution
📌 Applying consistency standards to this repository
✅ Conclusion
📚 References

🎯 Introduction

“Consistency” appears throughout documentation best practices—but what does it actually mean? It’s more than using the same word twice. It’s a multi-dimensional quality that spans terminology, structure, tone, formatting, and cross-references. Without a systematic approach, consistency degrades naturally as documentation grows, authors change, and conventions evolve.

This article covers:

Consistency dimensions — The five levels where inconsistency hides
Terminology glossaries — How to build and maintain a shared vocabulary
Style decision logs — Recording choices with rationale so they stick
Audit checklists — Structured approaches to finding inconsistencies
Automated enforcement — Tools that catch problems before readers do
Cross-document patterns — Keeping consistency across article boundaries
Migration strategies — Maintaining consistency during documentation evolution

Why consistency matters: Inconsistent documentation erodes trust. When readers encounter “endpoint” in one paragraph and “API route” in the next, they wonder whether you’re describing two different things—or simply weren’t careful. Consistency reduces cognitive load and lets readers focus on content, not decoding variations.

Prerequisites: Familiarity with writing style principles, structure and information architecture, and validation and quality assurance provides useful context.

📊 Dimensions of consistency

Consistency isn’t a single thing—it’s five distinct dimensions, each requiring different strategies to manage.

Terminology consistency

Terminology consistency means using the same word or phrase for the same concept throughout your documentation. This is the most visible and most frequently broken dimension.

Common violations:

Inconsistency type	Example	Impact
Synonyms	“endpoint” vs. “API route” vs. “URL”	Readers wonder if these are different things
Casing	“GitHub” vs. “Github” vs. “github”	Looks careless; brand names have specific casing
Abbreviations	“MCP” vs. “Model Context Protocol” vs. “the protocol”	First use should expand; subsequent uses should be consistent
Drift	Article 1 says “validation”; article 5 says “verification”	Creates confusion about whether processes differ

Strategy: Build and maintain a terminology glossary as the single source of truth.

Structural consistency

Structural consistency means articles that serve similar purposes follow similar patterns. Readers develop expectations—when those expectations break, comprehension slows.

What to standardize:

Section ordering — Introduction → Body → Conclusion → References (always)
Heading levels — H2 for main sections, H3 for subsections, never skip levels
Code block format — Always specify language; use consistent comment style
List formatting — Bullet points for unordered items, numbered lists for sequences
Conclusion pattern — Same structure: summary paragraph + key takeaways + next steps

Measurement: Compare article outlines side by side. Structural inconsistency is visible at the heading level before you read a single paragraph.

Tonal consistency

Tonal consistency means maintaining the same voice and register across your documentation. A conversational tutorial followed by an austere reference guide feels jarring if readers move between them.

Key tonal elements to standardize:

Person — Second person (“you”) throughout, or third person if that’s your convention
Formality level — Contractions (it’s, you’ll, don’t) signal conversational tone
Directness — “Configure the settings” vs. “You might want to consider configuring the settings”
Empathy markers — How you handle errors and warnings

The Microsoft voice uses warm and relaxed, crisp and clear, ready to lend a hand. If that’s your standard, every article should reflect it—not just the ones written on a good day.

Formatting consistency

Formatting consistency covers the visual presentation patterns that readers internalize unconsciously. When formatting shifts, readers notice—even if they can’t articulate why.

Elements to standardize:

Emphasis patterns — Bold for key terms, italic for definitions, <mark> for concepts to remember
Code references — Backticks for inline code: functionName(), config.json
Link styling — Descriptive text (never “click here”), consistent relative paths
Table design — Introduction before tables, headers in sentence case, concise cells
Emoji usage — Consistent reference classification markers (📘📗📒📕), H2 heading prefixes
Punctuation — Oxford commas, em-dashes without spaces, one space after periods

Cross-reference consistency

Cross-reference consistency means links between documents follow predictable patterns and don’t break when files move.

Standards to enforce:

Link format — Relative paths: [Article Title](filename.md), not absolute URLs
Prerequisites — Each article states what readers should know first
Navigation — Conclusion includes “Next article” and “Related” links
Terminology alignment — When article A introduces a term, article B uses the same term (not a synonym)
Series awareness — Articles reference their position in the series and maintain forward/backward links

📖 Building a project terminology glossary

A terminology glossary is your single source of truth for how concepts are named and described. Without one, consistency depends on memory—a fragile foundation.

What belongs in a glossary

Include terms that meet any of these criteria:

Multiple valid names exist — Choose one and document it (e.g., “endpoint” not “API route”)
Abbreviations are used — Define the expanded form and abbreviation (e.g., “MCP (Model Context Protocol)”)
Brand-specific casing matters — Record exact casing (e.g., “GitHub”, “macOS”, “VS Code”)
Domain jargon — Terms readers might not know (e.g., “Flesch Reading Ease”)
Internal conventions — Terms you’ve coined or redefined (e.g., “validation dimension” in this series)

Glossary format

A practical glossary balances detail with usability. Here’s a recommended format:

## Terminology Glossary

| Term | Use This | Don't Use | Notes |
|------|----------|-----------|-------|
| API endpoint | endpoint | API route, URL, path | "Endpoint" for the concept; "URL" only for actual addresses |
| Diátaxis | Diátaxis | Diataxis, diataxis | Always with accent; proper noun |
| GitHub Copilot | GitHub Copilot | Copilot, copilot, GH Copilot | Full name on first use; "Copilot" acceptable after |
| MCP | Model Context Protocol (MCP) | the protocol, MCP protocol | Expand on first use per article |
| validation dimension | validation dimension | validation criteria, check type | "Dimension" is the series term |

Maintaining the glossary

A glossary that isn’t maintained is worse than no glossary—it gives false confidence.

Maintenance practices:

Review during article creation — Check the glossary before writing; add new terms as you encounter them
Update during reviews — Flag terms that don’t match the glossary during peer review
Audit quarterly — Scan all articles for terms not in the glossary; add or standardize
Version the glossary — Track changes so you can see when and why terms were modified

Glossary automation

For larger projects, automate glossary enforcement:

# Example Vale rule: flag non-standard terminology
# .vale/styles/ProjectTerms/endpoint.yml
extends: substitution
message: "Use 'endpoint' instead of '%s'."
level: warning
swap:
  API route: endpoint
  api route: endpoint
  API path: endpoint

📝 Style decision log

A style decision log records the choices you’ve made about your documentation style—and, critically, why you made them. It’s the institutional memory that prevents revisiting the same debates.

Why you need one

Without a decision log:

New contributors re-raise settled questions (“Should we use Oxford commas?”)
Decisions get reversed accidentally during reviews
Style drift accumulates as contributors make different assumptions
Auditors can’t distinguish intentional choices from mistakes

Decision log format

Record each decision with enough context to be useful months later:

## Style Decision Log

### SD-001: Oxford comma (REQUIRED)
- **Decision:** Always use the Oxford comma in lists of three or more items
- **Date:** 2026-01-14
- **Rationale:** Eliminates ambiguity in complex lists; aligns with Microsoft Writing Style Guide
- **Example:** ✅ "Red, white, and blue" — ❌ "Red, white and blue"
- **References:** [Microsoft Style Guide - Commas](https://learn.microsoft.com/style-guide/punctuation/commas)

### SD-002: Contractions (REQUIRED)
- **Decision:** Use contractions consistently throughout all articles
- **Date:** 2026-01-14
- **Rationale:** Projects warm, conversational tone per Microsoft voice principles
- **Example:** ✅ "it's, you'll, don't" — ❌ "it is, you will, do not"
- **References:** Article 01, Section "Voice and Tone"

### SD-003: Heading capitalization (sentence case ONLY)
- **Decision:** Use sentence-style capitalization in all headings
- **Date:** 2026-01-14
- **Rationale:** Easier to apply consistently; reduces decision fatigue; matches Microsoft standard
- **Example:** ✅ "Getting started with Azure" — ❌ "Getting Started With Azure"

### SD-004: Reference classification markers
- **Decision:** All references use emoji classification: 📘 Official, 📗 Verified Community, 📒 Community, 📕 Unverified
- **Date:** 2026-01-14
- **Rationale:** Communicates source reliability at a glance without requiring readers to evaluate each source
- **References:** Article 06, Section "The Reference Classification System"

When to add entries

Add a style decision entry when:

You’re choosing between two or more valid approaches
A reviewer questions a stylistic choice
You discover an inconsistency and resolve it
A new tool or framework introduces new terminology

🤖 Automated consistency enforcement

Manual review catches inconsistencies—but not reliably. Automation scales consistency enforcement and catches issues before they reach readers.

Vale: prose linting

Vale is an open-source prose linter that enforces style rules programmatically. It’s the most practical tool for documentation consistency enforcement.

Setup:

# .vale.ini (project root)
StylesPath = .vale/styles
MinAlertLevel = suggestion

[*.md]
BasedOnStyles = Vale, ProjectTerms, Microsoft

Custom rule examples:

# .vale/styles/ProjectTerms/contractions.yml
# Enforce contractions per SD-002
extends: substitution
message: "Use contraction '%s' per SD-002."
level: warning
swap:
  it is: it's
  you will: you'll
  do not: don't
  does not: doesn't
  cannot: can't
  will not: won't

# .vale/styles/ProjectTerms/heading-case.yml
# Enforce sentence case in headings per SD-003
extends: capitalization
message: "Use sentence-style capitalization in headings."
level: error
match: $sentence
scope: heading

# .vale/styles/ProjectTerms/oxford-comma.yml
# Detect missing Oxford comma per SD-001
extends: existence
message: "Consider adding an Oxford comma before 'and' or 'or'."
level: warning
raw:
  - '\w+,\s\w+\s(?:and|or)\s'
scope: sentence

Markdown linting

markdownlint enforces structural consistency in Markdown files:

// .markdownlint.json
{
  "MD001": true,       // Heading levels increment by one
  "MD003": { "style": "atx" },  // ATX-style headings only
  "MD013": false,      // Allow long lines (common in tech docs)
  "MD024": { "siblings_only": true },  // No duplicate headings among siblings
  "MD033": false,      // Allow inline HTML (<mark> tags)
  "MD040": true,       // Code blocks must specify language
  "MD047": true        // Files must end with newline
}

CI/CD integration

Enforce consistency automatically in your publishing pipeline:

# .github/workflows/consistency-check.yml
name: Documentation Consistency
on:
  pull_request:
    paths: ['**/*.md']

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Vale prose lint
        uses: errata-ai/vale-action@v2
        with:
          files: '03.00-tech/'
      - name: markdownlint
        uses: nosborn/github-action-markdown-cli@v3
        with:
          files: '03.00-tech/'

Custom consistency scripts

For project-specific rules that Vale can’t express, write custom scripts:

# scripts/check-terminology.ps1
# Scan articles for glossary violations

param(
    [string]$GlossaryPath = ".vale/glossary.yml",
    [string]$ContentPath = "03.00-tech/40.00-technical-writing/"
)

$violations = @()
$articles = Get-ChildItem -Path $ContentPath -Filter "*.md" -Recurse

foreach ($article in $articles) {
    $content = Get-Content $article.FullName -Raw
    
    # Check for non-standard terms
    $terms = @{
        "API route"   = "endpoint"
        "click here"  = "descriptive link text"
        "Github"      = "GitHub"
        "Diataxis"    = "Diátaxis"
    }
    
    foreach ($wrong in $terms.Keys) {
        if ($content -match [regex]::Escape($wrong)) {
            $violations += [PSCustomObject]@{
                File = $article.Name
                Found = $wrong
                Expected = $terms[$wrong]
            }
        }
    }
}

if ($violations.Count -gt 0) {
    $violations | Format-Table -AutoSize
    Write-Warning "$($violations.Count) terminology violation(s) found."
} else {
    Write-Host "No terminology violations found." -ForegroundColor Green
}

🔗 Cross-document consistency patterns

Consistency within a single article is necessary but not sufficient. Documentation series—like this one—require consistency across articles.

The terminology handoff pattern

When article A introduces a term, all subsequent articles should use the same term without redefining it.

Pattern:

Introducing article — Define the term with <mark> tags and explanation: “A validation dimension is a measurable aspect of documentation quality.”
Subsequent articles — Use the term directly: “Apply the validation dimensions from Article 05.” Don’t redefine, don’t use synonyms.
Cross-reference — If a reader might have skipped the introducing article, link back: “…the validation dimensions…”

The structural echo pattern

Articles within a series should echo each other’s structure where it makes sense. Readers develop expectations from one article and carry them to the next.

In this series, every main article follows:

YAML frontmatter
---
# H1 Title
> Blockquote subtitle
## Table of Contents
## Introduction
  - "This article covers:" bullet list
  - Prerequisites with links
## Body Sections (H2 + H3)
## Applying [topic] to This Repository
## Conclusion
  - Summary paragraph
  ### Key Takeaways
  - **Bold takeaway** — Em-dash explanation
  ### Next Steps
  - **Next article:** link — description
  - **Related:** link — description
## References
  - Grouped by category
  - 📘📗📒📕 classification markers
<!-- Validation Metadata -->

When a new article breaks this pattern, consistency auditing should catch it immediately.

The reference alignment pattern

Cross-references between articles should be bidirectional and consistent:

If article 06 links to article 05 as a prerequisite, article 05’s “Next Steps” should mention article 06
If article 03 defines a concept used in article 07, both articles should agree on the term
Series navigation should be complete—no orphaned articles

Acceptable redundancy across articles

Not all cross-article overlap is a problem. Some concepts benefit from coverage in multiple articles—provided the overlap is intentional, documented, and differentiated.

When redundancy is acceptable:

Pattern	Example	Why it’s OK
Survey → deep dive	Art. 01 surveys readability formulas with practical targets; Art. 09 provides mathematical foundations and comprehension context	Different purpose (what vs. why); readers access different articles for different needs
Definition → application	Art. 00 defines quality criteria; Art. 05 operationalizes them into validation dimensions	Progressive depth; readers need both perspectives at different stages
Brief recap → full explanation	Art. 09 briefly recalls functional vs. deep quality from Art. 00 before extending the concept	Less than 100 words of recap that avoids forcing readers back to the original

When redundancy is a problem:

Identical content in two articles with no differentiation—consolidate to one location and cross-reference
Contradictory treatments that give different advice for the same scenario—resolve and align
Drifting coverage where both articles evolve independently, creating inconsistencies over time

Required documentation for intentional overlap:

When two articles deliberately cover the same concept, both articles MUST include a callout explaining the overlap:

> **On deliberate overlap with Article [N]:** This article covers [topic]
> as a [purpose A]. Article [N] covers the same topic as a [purpose B].
> Both perspectives are intentional; see [Article 08](08-consistency-standards-and-enforcement.md
> #acceptable-redundancy-across-articles) for the series redundancy policy.

This prevents future editors from “fixing” intentional overlap and ensures readers understand why the same topic appears in multiple places.

Building a concept coverage matrix

A concept coverage matrix maps which articles cover which concepts, making gaps and redundancies visible at a glance. Without one, coverage gaps only surface when a reader asks “where do I find guidance on X?” and nobody can answer.

Matrix structure:

Concept	Primary article	Secondary coverage	Gap?
Diátaxis framework	Art. 00	Art. 02 (progressive disclosure), Art. 05 (validation by type)	No
Readability formulas	Art. 01 (survey)	Art. 09 (analytical depth)	No — documented overlap
Functional vs. deep quality	Art. 00 (definition)	Art. 09 (measurement implications)	No — documented overlap
Documentation testing	Art. 05	—	No
Series planning	Art. 02	—	No

How to build one:

Extract concepts — Read each article’s TOC and introduction; list every distinct concept taught
Assign primary ownership — Each concept gets exactly one “home” article that provides the authoritative treatment
Map secondary coverage — Note articles that reference or recap the concept
Classify overlap — Use the acceptable redundancy criteria to determine if overlap is intentional or problematic
Identify gaps — Concepts that appear in no article’s primary coverage represent content gaps

Maintenance cadence: Review the coverage matrix whenever you add, remove, or significantly restructure an article. Include it as an item in the series-level audit checklist.

Where to store it: The matrix can live in a dedicated document outside the series (this repository uses 99.00-temp/ for working documents) or as a section in the series’ anchor article. The important thing is that it exists and is regularly updated—not where it lives.

🔄 Handling consistency during migration and evolution

Documentation isn’t static. Terminology changes, structures evolve, and tools get replaced. Managing consistency during change is harder than establishing it initially.

Migration strategies

When you need to change an established term or pattern:

1. Document the change in the style decision log

### SD-015: Rename "API route" to "endpoint"
- **Decision:** Replace all occurrences of "API route" with "endpoint"
- **Date:** 2026-03-15
- **Rationale:** Aligns with industry-standard terminology; reduces confusion with URL paths
- **Migration:** Full find-and-replace across all articles; completed 2026-03-15
- **Previous term:** SD-007 originally allowed "API route"

2. Use search-and-replace systematically

Don’t change terms article by article—you’ll miss occurrences. Use grep_search across all files, then apply changes in one pass.

3. Update the glossary simultaneously

The glossary, style decision log, and article content must change together. If they get out of sync, the glossary becomes untrustworthy.

Versioned consistency

Sometimes you need to support multiple versions of documentation simultaneously. In this case:

Tag each article with a version in the validation metadata
Maintain separate glossaries if terminology differs between versions
Document version-specific decisions in the style decision log
Automate version checks — A CI rule can verify that all articles in a version use consistent terminology

Handling organic growth

As documentation grows organically, consistency naturally degrades. Combat this with:

Regular audits — Run the consistency audit checklist quarterly
New-author onboarding — Point new contributors to the glossary and style decision log first
Pre-publication review — Every article gets a consistency review before publishing
Automation — Vale and markdownlint catch common issues without human effort

📌 Applying consistency standards to this repository

This series uses consistency standards throughout. Here’s how the principles in this article apply to the Technical Documentation Excellence series:

Repository terminology glossary

Key terms standardized across this series:

Term	Standard usage	First defined
Diátaxis	Always with accent mark	Article 00
Validation dimension	Not “validation criteria” or “check type”	Article 05
Reference classification	The 📘📗📒📕 system	Article 06
Sentence-style capitalization	Not “sentence case” alone	Article 01
Oxford comma	“Serial comma” is acceptable but “Oxford comma” is preferred	Article 01

Structural consistency in this series

All thirteen main articles follow the structural echo pattern described above. The five Microsoft Writing Style Guide sub-articles follow a different but internally consistent pattern, formally documented below.

Sub-series structural variation: Microsoft Writing Style Guide articles

The five MS sub-articles (microsoft-writing-style-guide/00-*.md through 04-*.md) are a thematic sub-series—a focused deep dive on a single external source that supplements the main series without replacing any of its articles. Their structural pattern intentionally diverges from the main series template:

YAML frontmatter
---
# H1 Title
> Blockquote subtitle
## Table of Contents
## Introduction
  - Scope bullets
  - Prerequisites with links to parent series
## Body Sections (H2 + H3)
  - Title Case headings
  - <mark> tags on key concepts in headings
  - No emoji prefixes
## Series Navigation
  - 5-article navigation table
  - Current article bolded
  - Related articles from parent series
## References
  - Grouped by category
  - 📘📗📒📕 classification markers

Key differences from the main series template:

Element	Main series (Art. 00–12)	MS sub-series (MS-00–04)	Reason
H2 emoji prefixes	Required on every H2	Not used	Sub-series predates the convention; internal consistency takes priority over retrofitting
Heading capitalization	Sentence case	Title Case	Matches the formal, reference-oriented tone of the sub-series
“Applying [topic]” section	Required	Absent	Sub-articles analyze an external guide, not repository-specific practices
Conclusion section	Required (Key Takeaways + Next Steps)	Absent	`## Series Navigation` serves as the closing section with both navigation and context
`<mark>` in headings	Not used in headings	Used for key concepts	Highlights the specific Microsoft terminology being analyzed
Navigation style	“Next Steps” within Conclusion	Dedicated `## Series Navigation` table	Sub-series is self-contained with its own 5-article navigation

When this variation is acceptable:

A sub-series MAY deviate from the main structural echo pattern when ALL of these conditions are met:

Internal consistency — All articles within the sub-series follow the same alternate pattern
Clear scope boundary — The sub-series covers a distinct, self-contained topic (e.g., analysis of one external guide)
Parent connection — Each sub-article links back to relevant main-series articles via cross-references
Documented deviation — The structural variation is formally documented (as it is here)

If a future sub-series is added, apply these same criteria before deciding whether to use the main template or define a new variation.

Automation in this repository

This repository uses:

IQPilot MCP server — 16 tools for content validation, metadata management, and gap analysis
Validation prompts — Structured prompts in .github/prompts/ for grammar, readability, structure, and fact-checking reviews
Link checking — PowerShell scripts in scripts/ that detect broken cross-references
MetadataWatcher — Automatically syncs filename changes to validation metadata

What’s not yet automated (and should be)

Vale prose linting for terminology enforcement (configured but not yet in CI)
markdownlint for structural consistency (available but not integrated)
Automated glossary violation detection across the series
Cross-reference bidirectionality checking

✅ Conclusion

Consistency isn’t a property that documentation either has or lacks—it’s a multi-dimensional quality that requires deliberate systems to achieve and maintain. Terminology glossaries, style decision logs, audit checklists, and automated tooling work together to enforce consistency at scale.

Key takeaways

Recognize five dimensions — Terminology, structural, tonal, formatting, and cross-reference consistency each require different strategies
Build a terminology glossary — A shared vocabulary prevents synonym drift and casing inconsistencies across your documentation
Log style decisions with rationale — Record not just what you decided but why, so future contributors don’t re-debate settled questions
Audit systematically — Use checklists at both article and series level; don’t rely on memory or intuition
Automate where possible — Vale, markdownlint, CI pipelines, and custom scripts catch inconsistencies before readers do
Plan for change — Migration strategies, versioned consistency, and regular audits prevent degradation as documentation evolves

Next steps

Next article: 00-foundations-of-technical-documentation.md — Return to foundations for a refresher on documentation principles
Related: 01-writing-style-and-voice-principles.md — The voice and style decisions that consistency enforcement protects
Related: 05-validation-and-quality-assurance.md — Validation frameworks that measure consistency as a quality dimension

📚 References

Consistency and style guides

Microsoft Writing Style Guide 📘 [Official]
The authoritative source for Microsoft documentation standards. Establishes voice, tone, mechanics, and accessibility rules that consistency enforcement protects.

Google Developer Documentation Style Guide 📘 [Official]
Complementary guidance on developer-facing documentation. Strong emphasis on consistent terminology, punctuation, and formatting.

Red Hat Documentation Style Guide 📗 [Verified Community]
Open-source documentation standards. Excellent example of a community-maintained style guide with terminology standardization.

Linting and automation

Vale - Prose Linter 📗 [Verified Community]
Open-source prose linter supporting custom rules. The most practical tool for automated terminology and style enforcement in documentation.

Vale Styles Repository 📗 [Verified Community]
Pre-built Vale style packages for Microsoft, Google, and other style guides. Accelerates initial setup.

markdownlint 📗 [Verified Community]
Markdown linting library with configurable rules. Enforces structural consistency across Markdown files.

markdownlint-cli2 📗 [Verified Community]
Command-line interface for markdownlint. Integrates into CI/CD pipelines for automated structural checks.

Terminology management

ISO 704:2022 - Terminology Work 📘 [Official]
International standard for terminology principles and methods. Defines systematic approaches to term management.

Write the Docs - Style Guides 📗 [Verified Community]
Curated collection of style guide resources. Includes guidance on building custom style guides and terminology standards.

Repository-specific documentation

Documentation Instructions [Internal Reference]
This repository’s formatting, structure, and reference standards.

Article Writing Instructions [Internal Reference]
Comprehensive writing guidance: voice, tone, Diátaxis patterns, accessibility, and mechanical rules.

Validation Criteria [Internal Reference]
Seven validation dimensions used for quality assessment across the series.

IQPilot MCP Server [Internal Reference]
This repository’s MCP server providing automated validation tools.

Consistency Standards and Enforcement

Table of Contents

🎯 Introduction

📊 Dimensions of consistency

Terminology consistency

Structural consistency

Tonal consistency

Formatting consistency

Cross-reference consistency

📖 Building a project terminology glossary

What belongs in a glossary

Glossary format

Maintaining the glossary

Glossary automation

📝 Style decision log

Why you need one

Decision log format

When to add entries

📋 Consistency audit checklist

Pre-publication checklist

Series-level audit

🤖 Automated consistency enforcement

Vale: prose linting

Markdown linting

CI/CD integration

Custom consistency scripts

🔗 Cross-document consistency patterns

The terminology handoff pattern

The structural echo pattern

The reference alignment pattern

Acceptable redundancy across articles

Building a concept coverage matrix

🔄 Handling consistency during migration and evolution

Migration strategies

Versioned consistency

Handling organic growth

📌 Applying consistency standards to this repository

Repository terminology glossary

Structural consistency in this series

Sub-series structural variation: Microsoft Writing Style Guide articles

Automation in this repository

What’s not yet automated (and should be)

✅ Conclusion

Key takeaways

Next steps

📚 References

Consistency and style guides

Linting and automation

Terminology management

Repository-specific documentation