Consistency maintained by shared components and a unified vocabulary survives; consistency maintained by documentation erodes over time

What it is

Whether internal consistency lasts depends on where the constraint lives. Shared components, APIs, templates, and terminology tables put the rule into the production path, so new screens inherit it by default. Rules kept only in documents, slide decks, or review memory decay through staff turnover, schedule pressure, and exceptions introduced for new features.

Why it happens

Shared artifacts supply a consistent expression at every creation point: a vocabulary feeds copy validation, a component encapsulates behavior and accessible state, a template inherits structure, and type definitions constrain field names. Documentation depends on someone actively finding, interpreting, and applying it; it cannot prevent copying an old page, creating a near-equivalent component, or bypassing process during an urgent fix. As time and contributors increase, the execution-cost gap widens, and documented consistency becomes consistency of a past version.

Where it stops holding

Shared components are not automatically good design. A library with too many variants, copied branches, or local overrides propagates inconsistency at scale, while excessive closure can block legitimate work. A unified vocabulary also needs maintenance: if concept changes update the document but not keys, APIs, and component labels, the system keeps generating new interfaces with old expressions.

Applying it

• Make the vocabulary for core objects and actions a build-time-checkable data source; copy, routes, logs, and tests should read the same keys.
• Provide one component entry point for common actions, constrain risky variants, and forbid hand-built equivalents in code review.
• When a concept changes, update components, vocabulary, migration scripts, and examples together rather than revising a PDF or web page first.
• Automatically scan for hand-built buttons, synonyms, and state labels; register new exceptions as migration debt instead of accepting them by default.

Related

• Same group: B2.23.1 Internal consistency is judged by whether the same meaning always uses the same expression · B2.23.3 Every locally optimal difference accumulates into overall inconsistency · B2.23.4 The benefits of internal consistency grow with product scale and frequency of use
• Nearby: B2.10 Consistency · R1 Design Systems
• Search terms: shared components · design tokens · terminology governance