Unity–Variety Balancing

batch: First Iteration/Batch 11

aliases: controlled variation around an invariant core

alias_records: controlled variation around an invariant core

slug: modularity

slug: composition

slug: invariance

slug: variability

slug: interoperability

slug: tolerance

components:
Invariant Core
Variation Zone
Variation Rule
Compatibility Check
Review Rule
Template Structure
Variation Boundary
Coherence Metric
Local Context Signal
Exception Pathway
Versioning Rule
Exemplar Set

mechanisms:
Design System
Brand Guideline System
Product Platform Variant Architecture
Common Core / Local Variation Policy
Curriculum Core Plus Electives
Modular Product Family
Pattern Library
Variant Review Board

essence_one_line: Preserve enough coherence for recognition and coordination while allowing enough variation for adaptation, novelty, and fit.

compression_statement: When a system risks either rigid uniformity or chaotic fragmentation, define the stable elements that must remain common, the zones where variation is allowed, the rules that constrain variation, and the review criteria that keep variation useful rather than disintegrating.

core_intuition: A living system usually needs both sameness and difference. Sameness lets people recognize, coordinate, reuse, trust, and compose the system. Difference lets the system adapt to context, explore alternatives, express identity, and avoid brittle one-size-fits-all behavior. The archetype works by making the line between invariant and variable explicit instead of leaving it to accident, habit, or personal taste.

canonical_formula: Unity–Variety Balancing = invariant core + governed variation zones + compatibility checks + review criteria. Too much core produces rigidity; too much unconstrained shell produces fragmentation.

structural_problem: A system is pulled toward two failure states. In one direction, excessive standardization makes it monotonous, brittle, unresponsive, or unable to fit local context. In the other direction, excessive variation makes it incoherent, hard to coordinate, hard to recognize, hard to maintain, or impossible to compare. The structural problem is not simply that there is variety; it is that the system lacks an explicit architecture for deciding what must remain common and what may vary.

condition: Both common identity and contextual adaptation matter.

rationale: The archetype is relevant only when neither pure uniformity nor unconstrained variety is acceptable. If either side can be sacrificed without real loss, a simpler standardization or customization pattern may suffice.

condition: Local units, audiences, users, teams, or contexts have meaningfully different needs.

rationale: Variation is useful when contexts differ enough that a single identical expression, process, product, or rule would misfit important situations.

condition: Coordination, recognition, comparability, or compatibility still depends on shared structure.

rationale: Unity matters because stakeholders need to know that different instances belong to the same system, interoperate with one another, or satisfy the same promise.

condition: Unclear boundaries between fixed and variable elements are producing drift or conflict.

rationale: The archetype becomes urgent when people repeatedly dispute whether a change is permitted, when customizations break compatibility, or when standards block legitimate adaptation.

condition: The system must evolve over time without losing continuity.

rationale: Unity–variety balancing is especially useful when a product, institution, curriculum, brand, or process has to keep changing while remaining legible as itself.

condition: The cost of either over-control or under-control is visible.

rationale: Over-control can suppress learning and local fit; under-control can create maintenance burden, confusion, quality variance, and identity fragmentation.

symptom: Everything looks or behaves the same even where contexts differ.

diagnostic_meaning: The system may have unity without enough variety. Users may work around rules, local teams may ignore central standards, or innovation may stall because variation has no legitimate channel.

symptom: Every instance is customized, but the whole no longer feels like one system.

diagnostic_meaning: The system may have variety without enough unity. Common identity, comparability, integration, quality control, or reuse may be collapsing.

symptom: Teams repeatedly ask what they are allowed to change.

diagnostic_meaning: The boundary between invariant core and variable shell has not been made operational.

symptom: Local adaptations solve immediate problems but create downstream incompatibility.

diagnostic_meaning: Variation is occurring without compatibility checks, versioning, or shared review criteria.

symptom: Central standards are defended as consistency even when they no longer serve important contexts.

diagnostic_meaning: The invariant core may be too large, too old, or insufficiently linked to the actual invariants that must be preserved.

symptom: Stakeholders disagree about whether divergence is creativity, noncompliance, localization, or drift.

diagnostic_meaning: Variation lacks naming, zones, rules, and review criteria that distinguish good adaptation from harmful fragmentation.

root_tension: The system needs enough sameness to be recognizable, maintainable, fair, interoperable, and trustworthy, but enough difference to be context-sensitive, adaptive, expressive, and resilient. The tension becomes destructive when the system treats sameness and difference as an all-or-nothing choice instead of a governed balance.

case: A single universal standard is sufficient and context differences are negligible.

why_not: Use straightforward standardization, compliance design, or quality control. Unity–variety balancing adds unnecessary governance when variation has no meaningful value.

case: Each local instance can be completely independent with no need for shared identity or compatibility.

why_not: Use local autonomy or decentralization. The balancing problem requires a reason for unity to remain valuable.

case: The issue is only visual attractiveness or stylistic polish.

why_not: A style guide or aesthetic coherence mechanism may help, but the archetype requires a structural balance between invariant and variable elements, not just surface consistency.

case: The main task is to decompose a system into modules.

why_not: Use modular_decomposition when the primary intervention is partitioning into bounded units. Unity–variety balancing may use modular boundaries, but its central problem is controlled diversity around shared identity.

case: The main task is to substitute different items into predefined slots.

why_not: Use slot_template_design when the relevant pattern is a stable template with interchangeable slots. Unity–variety balancing is broader and asks which elements should be common or variable in the first place.

case: The system simply needs more response capacity against external disturbances.

why_not: Use requisite_variety_matching if the primary issue is matching internal response variety to environmental complexity rather than preserving coherence while permitting variation.

structural_intervention: Define the nonnegotiable common core, locate legitimate variation zones, specify the rules and boundaries that govern those zones, test variation for compatibility with the core, and review the balance over time as contexts and system goals change.

action: Name what unity is for.

logic: Identify what must remain recognizable, interoperable, comparable, trustworthy, fair, or coordinated. Unity should be tied to concrete purposes, not defended as tradition or taste.

action: Name what variety is for.

logic: Identify the contexts, users, risks, opportunities, expressions, or experiments that require legitimate difference. Variety should be tied to adaptation, learning, fit, or expressiveness, not treated as random exception.

action: Separate invariant core from variable zones.

logic: Specify which elements are fixed, which are variable, which are conditionally variable, and which require review before change. Make the boundary visible enough that participants can act without constant permission.

action: Define variation rules and tolerance bands.

logic: For each variation zone, define allowed ranges, substitution rules, local decision rights, compatibility constraints, versioning needs, and exception criteria.

action: Install compatibility and coherence checks.

logic: Test whether a local variation still fits the core promise, works with other parts, preserves quality, and remains legible to users or participants.

action: Review the balance over time.

logic: Treat the core and the variation envelope as design decisions that can become stale. Promote useful repeated variations into standards, retire harmful variations, and reopen overly rigid core elements when context changes.

rule: Preserve an element as core only if changing it would break identity, safety, compatibility, fairness, comparability, or essential function.

implication: This prevents the core from becoming an accumulation of preferences or legacy habits.

rule: Permit variation when context differences are meaningful and the variation can be bounded, explained, and evaluated.

implication: This prevents customization from becoming arbitrary drift.

rule: Escalate a variation for review when it crosses a core boundary, affects other units, changes the user promise, or creates incompatibility.

implication: This keeps local autonomy from silently damaging the shared system.

rule: Promote a repeated successful variation into the shared system when it solves a recurring problem better than the current standard.

implication: This keeps unity from freezing learning at the center.

rule: Retire or constrain variations that add maintenance burden without improving fit, learning, expression, or resilience.

implication: This keeps variety from becoming ornamental complexity.

invariant: Recognizable identity

description: Stakeholders can still tell that different instances belong to the same system or fulfill the same promise.

invariant: Functional compatibility

description: Varied instances still interoperate, compose, compare, or coordinate where necessary.

invariant: Core quality and safety

description: Variation does not undercut the minimum quality, reliability, safety, fairness, or accountability standards that justify the shared system.

invariant: Legitimate adaptation space

description: Local actors retain meaningful room to adapt rather than being forced into brittle compliance.

invariant: Reviewability

description: The system can tell whether the current balance is working, drifting, or becoming obsolete.

outcome: Coherent diversity

description: Instances can differ in ways that serve context while still remaining recognizably part of the same system.

outcome: Reduced conflict over customization

description: Participants understand which elements are fixed, variable, conditionally variable, or review-only.

outcome: Higher local fit without uncontrolled fragmentation

description: Teams can adapt to context without breaking shared standards, identity, or interoperability.

outcome: Reusable learning from variation

description: Useful local experiments can be compared, selected, and incorporated into the core or into named variants.

outcome: Lower maintenance burden than unguided variation

description: Variation is channeled through zones, rules, and reviews rather than creating unbounded bespoke versions.

prose_essence:
Unity–Variety Balancing is the intervention pattern for systems that need to stay recognizably one thing while legitimately becoming many things. It is not a compromise slogan. It is a design structure: decide what must stay invariant, decide where difference is allowed, define rules for that difference, and keep reviewing whether the balance is still serving the system.

The archetype is useful whenever pure sameness becomes brittle and pure difference becomes incoherent. A curriculum needs common learning outcomes and local examples. A product family needs a shared platform and variant features. A governance system needs common protections and local implementation. A brand needs a stable promise and contextual expression. In each case, the solution is not simply “more consistency” or “more flexibility”; it is a governed boundary between the two.

prose_when_to_use:
Use this archetype when stakeholders are pulled between standardization and adaptation, and both sides are genuinely valuable. The signal is usually a repeated argument over what must be common and what may differ. Some people defend consistency because they need reliability, fairness, comparability, safety, or recognition. Others defend variation because they need fit, accessibility, local legitimacy, creativity, or experimentation.

It is especially appropriate when local workarounds are accumulating, when central rules are resisted as tone-deaf or brittle, when many variants exist without a variant inventory, or when different versions share a name but no longer interoperate. It is also appropriate when a system is growing: early improvisation may need a core, but mature standardization may need renewed variation zones.

Do not use this archetype when there is no meaningful need for either side. If context does not differ, standardization may be enough. If shared identity or compatibility does not matter, decentralization may be enough.

prose_structural_problem:
The structural problem is a two-sided failure surface. On one side, over-standardization makes the system rigid. The system becomes easy to recognize but hard to adapt. It may exclude local realities, suppress learning, or force people into hidden exceptions. On the other side, over-variation makes the system fragmented. The system becomes locally expressive but hard to coordinate, compare, maintain, audit, or trust.

The deeper problem is usually that the system has not separated invariants from variables. Current practice treats all inherited features as core, or all local preferences as acceptable, or every deviation as an exception requiring political negotiation. Without a named core and named variation zones, every change becomes a fight over identity.

prose_intervention_logic:
The intervention begins by asking what unity is for. Unity may preserve identity, safety, interoperability, fairness, comparability, quality, or trust. Each invariant should earn its place in the core by serving one of those purposes.

Then the intervention asks what variety is for. Variety may support local fit, user choice, cultural adaptation, experimentation, resilience, personalization, or specialized performance. Each variation zone should be tied to a real contextual difference or learning opportunity.

After that, the pattern creates a boundary. Some elements are fixed. Some are variable. Some are variable only within tolerances. Some require review. Compatibility checks ensure variations do not break the shared promise. Review rules keep the system from freezing or drifting: useful repeated variations can become part of the standard, while low-value variation can be retired.

prose_key_components:
### Invariant Core

The invariant core is the part of the system that must remain stable across variants. It might include a safety requirement, a brand promise, a technical interface, a learning outcome, a legal right, a quality threshold, or a shared data definition. The core should be smaller than “everything we currently do.” It should include only what would cause real breakage if changed casually.

### Variation Zone

A variation zone is a place where difference is intentionally permitted. It gives local actors legitimate room to adapt rather than forcing every contextual need into a workaround. Variation zones can appear in implementation details, examples, feature configurations, modules, tone, timing, staffing, channels, or elective pathways.

### Variation Rule

A variation rule says how variation may happen. It can define allowed ranges, substitution rules, conditional permissions, approval thresholds, or review requirements. Without variation rules, the phrase “you may adapt this” is too vague to be safe or useful.

### Compatibility Check

The compatibility check asks whether a variation still works with the core and with other parts of the system. In a technical system, this may mean interface compatibility. In policy, it may mean rights, safety, or reporting compatibility. In education, it may mean shared outcomes. In communication, it may mean recognizable voice or meaning.

### Review Rule

The review rule keeps the balance alive. It decides when variants should be inspected, promoted, retired, merged, renamed, or constrained. This is what prevents standards from becoming fossilized and prevents local variation from becoming unmanaged sprawl.

### Template Structure

A template structure makes the fixed and variable positions visible. It is often helpful but not always required. A template can show which fields, modules, sequence steps, visual regions, or policy clauses are fixed and which can be adapted.

### Supporting Components

Variation boundaries, coherence metrics, local context signals, exception pathways, versioning rules, and exemplar sets make the pattern easier to operate at scale. They help participants see when a difference is legitimate, when it crosses a boundary, and how the system should learn from repeated variation.

prose_common_mechanisms:
### Design Systems

A design system implements Unity–Variety Balancing by defining shared components, tokens, patterns, and accessibility rules while allowing teams to compose them differently for different products or contexts. The design system is a mechanism, not the archetype. The archetype is the structural choice to preserve common design invariants while allowing governed design variation.

### Brand Guideline Systems

A brand guideline system keeps a voice, promise, or identity recognizable while allowing local imagery, examples, tone adjustments, and channel-specific expression. It becomes this archetype only when it distinguishes true identity invariants from permitted expression, rather than merely listing style preferences.

### Product Platform Variant Architectures

A product platform variant architecture preserves a shared core, service model, or technical base while allowing variants for different markets, prices, or use cases. This mechanism is powerful but boundary-sensitive because platform-core design may also belong to a distinct architecture family.

### Common Core / Local Variation Policy

A Common Core / Local Variation Policy defines minimum shared obligations while letting local units adapt implementation. It is common in governance, franchises, multi-site operations, education, and healthcare. It works when local discretion is real but does not excuse violation of the shared core.

### Curriculum Core Plus Electives

A curriculum core plus electives mechanism preserves common outcomes while allowing varied pathways, examples, pacing, projects, or specializations. It is a clean educational example of the archetype: common enough to compare and trust, varied enough to fit learners and contexts.

### Modular Product Family and Pattern Library

A Modular Product Family and a Pattern Library allow repeated elements to be reused while local instances differ. They are especially useful when the cost of totally bespoke variation would be too high, but a single fixed product or pattern would not fit enough contexts.

### Variant Review Boards or Review Processes

A variant review board, architecture review process, curriculum review committee, or standards council maintains the balance over time. Its job is not to block variation by default; it is to distinguish useful adaptation from drift, promote repeated improvements, and protect true invariants.

prose_failure_modes:
A frozen core occurs when legacy preferences are treated as invariants. The mitigation is to require every core element to justify itself by identity, safety, compatibility, fairness, quality, or essential function.

Unbounded customization occurs when variation zones exist without rules, compatibility checks, or review. The mitigation is to define allowed ranges, examples, escalation thresholds, and retirement criteria.

Hollow unity occurs when instances share names or symbols but diverge in actual function. The mitigation is to include behavioral, functional, and quality invariants, not just surface markers.

Pseudo-variety occurs when the system claims to allow adaptation but permits only cosmetic differences. The mitigation is to connect variation zones to real local context signals and decision rights.

Exception creep occurs when every special case becomes permanent. The mitigation is to create expiration dates, exception reviews, variant inventories, and promotion-or-retirement decisions.

Coherence policing occurs when central actors use unity language to suppress legitimate difference. The mitigation is transparent invariant criteria and review participation from affected contexts.

prose_neighbor_distinctions:
**Invariant Core with Variable Shell** is the closest subtype. It emphasizes a stable center and variable periphery. Unity–Variety Balancing is broader because it includes review, variant promotion, coherence metrics, and multiple possible balance structures.

**Slot-Template Design** is about stable templates with interchangeable slots. It often implements this archetype, but it is narrower. Unity–Variety Balancing decides what should be fixed or variable before a template is chosen.

**Modular Decomposition** breaks a system into bounded units. It can support this archetype, but decomposition alone does not decide how much unity or variety should exist across module instances.

**Standard Interface Composition** preserves interoperability through shared interfaces. It is a useful neighbor or mechanism, not the whole pattern.

**Platform Core / Extension Design** is an architecture-specific neighbor. It should not be silently absorbed here because reconciliation controls place it in a separate platform/modular architecture review zone.

**Requisite Variety Matching** asks whether the system has enough internal response variety to handle environmental variety. Unity–Variety Balancing asks how much variation can be allowed while preserving coherence.

prose_cross_domain_examples:
In design systems, shared components and accessibility standards preserve unity while layout, content, and flow vary by product. The balance works when product teams can adapt without breaking accessibility, brand recognition, or component compatibility.

In education, common outcomes and assessment criteria preserve comparability while examples, projects, pacing, and electives vary. The balance works when teachers can respond to learners without losing the shared learning promise.

In governance, common rights, reporting obligations, or safety standards preserve fairness and accountability while local implementation varies. The balance works when local discretion is transparent and does not undermine the shared protections.

In product platforms, a shared technical base supports many models or configurations. The balance works when variants deliver market fit without multiplying maintenance beyond control.

In healthcare, a standard care pathway can preserve safety-critical steps while clinicians adapt communication, timing, and supportive interventions to patient context. The balance works when clinical judgment is bounded by core safety invariants.

In brand communication, a global identity can remain recognizable while examples, imagery, and language vary across audiences. The balance works when local expression serves context without contradicting the core promise.

prose_non_examples:
A central rulebook that forbids meaningful local adaptation is not Unity–Variety Balancing. It is standardization.

A set of local practices with no shared core, no comparability, and no review is not Unity–Variety Balancing. It is fragmentation or decentralization.

A style guide that only lists colors, fonts, and preferred wording is not the archetype. It may be a mechanism if it supports a deeper core/variation structure.

A modular architecture that only partitions responsibilities is not the archetype unless it also governs how modules or instances remain unified while varying.

A customization free-for-all is not the archetype. Variation must be legitimate, bounded, and reviewable.

prose_tradeoffs:
The central tradeoff is coherence versus local fit. Tight unity helps coordination, but too much tightness produces rigidity. Wide variety improves fit, but too much variety produces fragmentation.

There is also a governance tradeoff. Review processes protect the system from drift, but they can become slow, political, or controlling. Autonomy helps local actors respond quickly, but it can hide incompatibility or quality variance.

A third tradeoff is continuity versus evolution. A stable core builds trust, but a core that never changes becomes obsolete. Promoting local learning into the core keeps the system alive, but too-frequent changes can destabilize users and maintainers.

prose_invariants_to_preserve:
The invariant core should preserve recognizable identity, functional compatibility, minimum quality, safety, fairness, and the promise that makes the system one system. These invariants should be explicit enough that people can test proposed variations against them.

The archetype should also preserve legitimate adaptation space. A system that claims to allow variation but makes every meaningful adaptation impossible has failed the variety side of the pattern. Finally, it should preserve reviewability: the organization or system must be able to tell whether the current balance is working.

prose_target_outcomes:
A good Unity–Variety Balance produces coherent diversity. Different instances can fit local needs while still being recognizable, compatible, comparable, or trustworthy. It reduces arguments over whether something is a deviation because the fixed and variable zones are visible.

It also improves learning. Local adaptations can be compared instead of hidden. Successful repeated variations can become new standards or named variants. Harmful variations can be retired without treating all variation as bad.

A mature balance lowers maintenance burden compared with unguided customization while avoiding the brittleness of one-size-fits-all standardization.

prose_parameter_dimensions:
The most important tuning dimension is core size. A larger core increases consistency and reuse but can suppress fit. A smaller core increases local freedom but may reduce recognition and compatibility.

The second dimension is variation breadth: how many zones can vary and how far. Broad variation supports context-sensitive adaptation, but each additional variant adds documentation, maintenance, training, testing, and communication burden.

A third dimension is review strictness. Strict review reduces harmful drift but can create bureaucracy. Loose review encourages experimentation but can allow incompatible versions to proliferate.

Other tuning dimensions include who owns the core, who may authorize variation, how often the balance is reviewed, whether variants expire, how successful variants are promoted, how exceptions are named, and how coherence is measured.

prose_variants_and_near_names:
The main captured subtype is **Invariant Core with Variable Shell**. It should remain under this parent unless future review finds distinct cross-domain machinery that merits a full draft.

A governance variant is **Common Core with Local Variation**, where shared obligations remain fixed while local implementation adapts. A communication variant is **Identity System with Governed Expression**, where a stable identity or meaning system permits contextual expression. A platform-oriented candidate variant is **Variant Family Platform**, but it needs careful boundary review against platform architecture archetypes.

Near names include flexible standardization, standardization–customization balance, coherence–variation balance, controlled diversity, and stable core with governed variation. Mechanism names such as style guide and design system should point to this archetype or to a relevant variant, not become standalone archetype drafts here.

Invariant Core with Variable Shell

variant_type: subtype

short_definition: Protect a stable core while allowing peripheral features, expressions, or implementations to vary.

distinctive_feature: It makes the core/shell distinction the main named pattern rather than the broader balancing process.

distinct_from_parent: The parent archetype includes multiple balancing configurations, review criteria, coherence metrics, variant promotion, and governance of variety; this subtype emphasizes a stable center with a variable periphery.

still_same_parent_because: It still solves the same structural problem: preserving unity while allowing controlled variety.

use_when: A system needs a clearly protected core identity, interface, rule set, or function.

use_when: Most adaptation can happen in peripheral, contextual, or implementation-layer elements.

use_when: The key design question is the boundary between nonnegotiable core and variable shell.

Invariant Core

role: Defines the protected center.

Variation Boundary

role: Marks where shell variation begins and where review is required.

Compatibility Check

role: Ensures shell variation does not break the core.

Core/Periphery Architecture

mechanism_type: template

example_domains:
product platforms
policy localization
brand systems
curriculum design

domain: Curriculum

example: Core learning outcomes are fixed while elective modules and local examples vary.

domain: Brand

example: The promise and voice remain stable while imagery and campaign examples vary by region.

failure_modes: The shell becomes so constrained that variation is nominal only.

failure_modes: The shell is allowed to alter core promises without being reviewed.

Common Core with Local Variation

short_definition: Define common obligations or outcomes while letting local units adapt implementation to context.

distinctive_feature: The recurring governance structure of common requirements plus local implementation autonomy.

distinct_from_parent: It is specifically about policy, governance, and practice localization rather than all forms of structural variation.

still_same_parent_because: It uses invariant obligations, local variation zones, compatibility checks, and review criteria.

source_primes: unity_and_variety constraint boundary

use_when: A central system must preserve minimum standards but local conditions differ.

use_when: Local actors need legitimate discretion without abandoning shared accountability.

Minimum Standard

role: Defines the common floor.

Local Context Signal

role: Justifies adaptation.

Exception Pathway

role: Handles unusual variations.

Local Adaptation Policy

mechanism_type: protocol

Implementation Guidance

mechanism_type: document

example_domains:
public policy
franchise operations
multi-site services
clinical pathways

domain: Governance

example: Common rights protections remain fixed while delivery mechanisms vary by locality.

failure_modes: Local adaptation becomes unequal treatment without transparent rationale.

name: Identity System with Governed Expression

short_definition: Keep a shared identity or meaning system stable while governing expressive variation across contexts.

distinctive_feature: The balance is applied to identity, communication, and symbolic expression rather than product or governance structure.

distinct_from_parent: It is a domain-leaning variant focused on representation and expression.

still_same_parent_because: It still distinguishes invariant identity from permitted variation and uses review to prevent drift.

use_when: Recognition, trust, voice, or meaning must remain consistent across many surfaces.

use_when: Expression must vary by audience, culture, channel, or situation.

Identity Core

role: Defines the stable meaning or promise.

Expression Zone

role: Defines permitted variation in tone, imagery, examples, or channel.

Message Pattern Library

mechanism_type: artifact

example_domains:
branding
campaigns
editorial systems
public communication

example: Voice and promise stay fixed while regional examples and imagery vary.

failure_modes: The identity becomes so rigid that local communication sounds artificial or tone-deaf.

Variant Family Platform

short_definition: Use a shared platform, architecture, or base model to support multiple governed variants.

distinctive_feature: The balance is mediated through platform architecture and configurable variants.

distinct_from_parent: It is one platform-oriented implementation of the more general balance.

still_same_parent_because: It relies on stable core, variation zones, compatibility checks, and variant review.

use_when: A product, service, or technical system must support several market or use-case variants.

use_when: Reuse and compatibility matter, but variant-specific fit also matters.

Shared Platform Core

role: Provides common reusable infrastructure.

Configuration Zone

role: Provides governed places for product differences.

example_domains:
product families
software platforms
service packages
hardware variants

domain: Product

example: Multiple models share a chassis and safety architecture while feature sets vary.

failure_modes: Variant complexity overwhelms the reuse benefits of the platform.

near_names:
Flexible Standardization
Standardization–Customization Balance
Coherence–Variation Balance
Stable Core with Governed Variation
Style Guide
Design System
Brand Consistency with Local Adaptation


Use-Time Precondition Binding

type: archetype

source: generated

batch: Batch 06

slug: verification

slug: latency

slug: transaction

slug: concurrency

slug: authentication

slug: attestation

slug: traceability

slug: versioning

slug: constraint

slug: coupling

slug: time

slug: observability

slug: resilience

slug: accountability

slug: transparency

slug: threshold

slug: uncertainty

slug: backtracking

slug: consistency

slug: idempotence

slug: commitment

components:
Checked Precondition Claim
Use-Action Boundary
Check–Use Gap Window
Use-Time State Evidence
Validity Window or Lease
State Version or Freshness Token
Atomic or Exclusive Use Boundary
Use-Time Revalidation Rule
Invalidation and Revocation Signal
Conflict, Abort, and Retry Policy
Check–Use Audit Trace
Stale-Authority Escape Path
Risk-Tiered Gap Budget
Reservation or Hold Record
Compensation or Rollback Path

mechanisms:
Final Revalidation Before Commit
Compare-and-Swap Version Token
Lease-Bound Capability Token
Lock or Hold Until Use
Reservation–Commit Protocol
Stale Data Revalidation Gate
Revocation Status Check at Use
Timestamp and Freshness Badge
Snapshot-Pinned Decision
Abort-and-Retry After State Mismatch
Confirmation Dialog with State Refresh
Two-Phase Commit with Freshness Check

essence_one_line: Act on a precondition only when the condition is still bound to the state at the moment of use, not merely when it was true during an earlier check.

compression_statement: Identify the checked precondition, the later action it authorizes, the gap in which relevant state may change, the freshness or validity evidence needed at use time, and the abort, retry, reservation, lease, lock, transaction, or revalidation rule that prevents stale precondition evidence from authorizing an unsafe action.

core_intuition: A check is not a durable permission by default. Between checking a file, account, credential, consent state, resource balance, custody record, or safety condition and using it, the world may change. The solution is to make the action consume a state that is still current: either collapse check and use into one protected operation, reserve the condition, carry a freshness token, revalidate at the point of use, or abort when the old check no longer binds.

canonical_formula: Authorize(A) only if valid_at_use(P, S_t_use, scope(A)) is true, where P is the checked precondition, S_t_check is the observed state at check time, G = [t_check, t_use] is the check-use gap, and S_t_use must either equal the bound state version, be protected by a reservation/lease/lock, or pass a use-time revalidation rule before action A commits.

structural_problem: A system verifies a precondition at one time and later treats that verification as permission to act, but the relevant identity, state, authority, resource, custody, consent, balance, hazard, or evidence condition can change before the action occurs. The defect is not simply an absent check and not simply a bad action; it is a broken temporal binding between the check and the use.

trigger_conditions: A later action depends on an earlier precondition check, status lookup, eligibility decision, resource availability result, credential validation, or safety assessment.

trigger_conditions: The checked state can change, expire, be revoked, be substituted, be consumed by another actor, drift out of sync, or become ambiguous before use.

trigger_conditions: There is a nonzero delay, queue, workflow, actor handoff, network latency, physical transfer, human confirmation step, or asynchronous callback between checking and acting.

trigger_conditions: False acceptance after a state change can cause security, safety, financial, evidential, fairness, or integrity harm.

trigger_conditions: The system has enough observability or control to use a version marker, lease, lock, reservation, timestamp, final recheck, or abort rule.

trigger_conditions: The action cannot safely rely on a stale snapshot unless it explicitly commits to acting on that snapshot and its scope.

symptoms: An operation first checks that a resource exists, but a later open, transfer, publish, delete, or consume acts on a different or changed resource.

symptoms: A credential, permission, consent, hazard status, or eligibility result is valid when checked but revoked or expired by the time it is used.

symptoms: Users see “available” or “approved” states that become invalid during checkout, dispatch, scheduling, or final confirmation.

symptoms: Audit logs show separate check and action events but cannot show that the action consumed the same state version that was checked.

symptoms: Systems add repeated manual confirmations, but the confirmation does not refresh the relevant state.

symptoms: Concurrency controls are present in some layers, yet stale state moves across a boundary into another layer that treats it as current.

symptoms: Failures are hard to reproduce because the harmful change occurs during a narrow timing window.

root_tension: Designers want to reduce friction by checking once and acting later, but the authority conferred by the check decays as the checked world changes. Strong binding reduces stale-action risk but can increase locking, latency, contention, disclosure, user friction, and failure-to-proceed rates.

anti_signatures: The action is fully reversible and explicitly intended to operate on the old snapshot rather than the current state.

anti_signatures: The precondition is timeless for the relevant scope, such as a mathematical invariant unaffected by elapsed time or external events.

anti_signatures: The main problem is simultaneous resource contention across many actors, with no special stale-precondition authorization issue; use Concurrency Control.

anti_signatures: The main problem is making a group of operations all-or-nothing after they start; use Transactional Atomicity.

anti_signatures: The main problem is generic delay calibration in a feedback loop rather than a precondition that authorizes action; use Coupling Latency and Time-Delay Effects.

anti_signatures: The main problem is deciding what preconditions should be checked in the first place; use Guarded State Transition, Functional Specification, or Transition Readiness Assessment.

structural_intervention: Turn the earlier check into a bounded, auditable, use-time-valid authority relation by either eliminating the check-use gap, protecting the checked state during the gap, carrying a comparable freshness token, or requiring revalidation immediately before the action commits.

action_logic: Name the action that will consume the precondition and identify what harm occurs if the precondition changes before use.

action_logic: Decompose the precondition into checkable state claims and identify which claims are time-sensitive, revocable, substitutable, consumable, or versioned.

action_logic: Measure or classify the check-use gap: duration, actors, queues, systems, event channels, custody transfers, and change opportunities.

action_logic: Choose a binding strategy: atomic transaction, exclusive lock, reservation/hold, validity window, lease-bound capability, version token, final revalidation, snapshot pinning, or abort-and-retry.

action_logic: Propagate invalidation signals such as revocation, state update, custody break, resource consumption, hazard change, or authority handoff to any pending action.

action_logic: At use time, compare the current state, bound snapshot, token, lease, or revocation epoch against the action scope.

action_logic: Proceed only if the use-time binding rule passes; otherwise abort, refresh, retry, escalate, compensate, or obtain new authority.

action_logic: Record the check, gap, state evidence, binding decision, action, and exception route for later audit and learning.

decision_rules: If the action changes or consumes an external state, the precondition must be revalidated or protected at commit/use time.

decision_rules: If the state can be consumed by another actor, use reservation, isolation, locking, or version compare-and-swap rather than a bare prior lookup.

decision_rules: If authorization can be revoked, check revocation or epoch status at use, not only when the authorization was issued.

decision_rules: If the action is irreversible or high-impact, require a lower gap budget, stronger freshness evidence, and an explicit abort/rollback path.

decision_rules: If exact current-state validation is unavailable, either bind the action to a named snapshot and accept snapshot risk, or defer/escalate rather than imply current validity.

decision_rules: If a mismatch is detected, do not silently continue; classify it as stale, conflicted, revoked, expired, changed-subject, or inconclusive.

target_invariants: The action consumes the same state, authority, resource, identity, custody, or evidence condition that authorized it, or explicitly consumes a named snapshot.

target_invariants: No stale precondition evidence can silently grant broader authority than its declared validity window and scope.

target_invariants: State changes that invalidate prior checks are observable to pending actions or make those actions fail closed.

target_invariants: Abort, retry, and compensation paths preserve integrity more reliably than partial proceed.

target_invariants: Audit records can reconstruct check time, use time, state version, actor, authority scope, and invalidation events.

expected_outcomes: Fewer stale-permission, stale-resource, stale-consent, stale-safety, stale-custody, and stale-authentication incidents.

expected_outcomes: Clearer distinction between “was valid when checked,” “reserved for this use,” “still valid now,” and “explicitly using an old snapshot.”

expected_outcomes: Reduced race-window exploitation and accidental check-use drift.

expected_outcomes: Better incident diagnosis because the gap and state binding are recorded.

expected_outcomes: More appropriate use of atomicity, locking, leasing, versioning, revocation, and final revalidation without forcing every action into the heaviest transaction model.

Atomic Check–Use Binding

short_definition: Collapses the check and the use into a single atomic or exclusive operation so the checked state cannot change before consumption.

distinctive_feature: The gap is eliminated or protected rather than merely measured.

distinct_from_parent: The parent covers several binding strategies; this variant relies specifically on atomicity, isolation, or exclusivity.

still_same_parent_because: It solves the same check-use temporal authority problem.

use_when: The relevant state can be locked, transacted, or exclusively held.

use_when: The cost of contention is acceptable for the risk tier.

use_when: The action requires strong consistency rather than eventual correction.

domain: filesystem

example: Open a checked file by stable handle rather than by a path that can be swapped.

Version-Checked Use

short_definition: Allows action only when the state version observed at check time still matches the state version at use time.

distinctive_feature: Uses comparable state identity rather than physical exclusion.

distinct_from_parent: The parent includes locking, leases, revalidation, and snapshot pinning; this variant centers compare-before-commit semantics.

still_same_parent_because: It is still a method for binding the checked state to the consuming action.

use_when: State can change but carries a comparable version marker.

use_when: Optimistic concurrency is preferred to exclusive locking.

use_when: Abort and retry are acceptable on mismatch.

domain: API

example: Update proceeds only if the submitted ETag still matches the current record.

failure_modes: false confidence in coarse version markers

Lease-Bound Authority

short_definition: Turns a verified authorization or resource state into a scoped, expiring, revocable lease that can be consumed only within its validity window.

distinctive_feature: Preserves authority for a bounded window instead of assuming the original check remains valid indefinitely.

distinct_from_parent: The parent covers all check-use binding; this variant specifically uses temporary delegated authority.

still_same_parent_because: A lease is one way to keep the check valid until use.

use_when: A resource, identity claim, or permission can be reserved or tokenized.

use_when: The action can be scoped by subject, action, audience, and expiry.

use_when: Revocation or expiry must be honored at use.

example: A signed URL permits one download only until its expiry and intended audience match.

failure_modes: long leases become durable overpermission

Snapshot-Bound Action

short_definition: Makes explicit that the action consumes a named historical snapshot rather than claiming current-state validity.

distinctive_feature: It resolves the gap by changing the claim from current-state use to declared snapshot use.

distinct_from_parent: Most parent cases seek current validity; this variant makes stale state explicit and acceptable.

still_same_parent_because: It prevents the earlier check from falsely masquerading as use-time validity.

use_when: Acting on the current state is impossible or unnecessary.

use_when: The snapshot can be named, timestamped, and bounded.

use_when: Downstream users will not mistake snapshot validity for present validity.

domain: analytics

example: A dashboard action is labeled as based on the 09:00 snapshot rather than live inventory.

failure_modes: downstream systems recast snapshot as current fact

near_names:
TOCTOU
TOCTTOU
Stale Precondition Guard


Use-Time Referent Validation

batch: Batch 09

aliases:
use-time precondition validation
referent validity guard
just-in-time existence check
stale reference guard
check-and-use binding
use-moment validation
referent existence gate
time-of-use precondition guard
stale handle protection
TOCTOU-aware precondition validation

slug: verification

slug: validation

slug: dependency

slug: transaction

slug: boundary

slug: closure

slug: monitoring

slug: logging

slug: authentication

slug: latency

essence_one_line: Verify that the thing an action depends on still exists and is valid at the moment of use, then bind, use, or fail safely.

compression_statement: Use-Time Referent Validation applies when an action is about to operate on something named, selected, cached, promised, authorized, reserved, or remembered earlier. The intervention makes the presumed referent explicit, checks its current existence, identity, validity, authority, and freshness immediately before use, and closes the gap between check and action by binding, locking, snapshotting, leasing, versioning, or atomically coupling the check with the use. If the referent is absent, changed, revoked, expired, ambiguous, or no longer authorized, the action aborts, refreshes, retries, escalates, or moves to a safe fallback rather than proceeding on a stale assumption.

core_intuition: A precondition is only useful if it is true when the action actually relies on it. Earlier evidence, cached identity, stale status, or assumed availability can become false in the interval before use. The safe move is not merely to ask “was this valid?” but to ask “is this exact referent valid now, for this action, under this binding?”

canonical_formula: For action A on referent R at time t_use, proceed only if valid(R, A, t_use) is verified and bound to A; otherwise abort, refresh, retry, or route to fallback.

structural_problem: A system or workflow treats a reference, resource, record, identity, condition, or dependency as still present and valid because it was expected, selected, checked, or true earlier. At the moment of use, the referent may be missing, revoked, replaced, expired, moved, consumed, concurrently modified, no longer authorized, or semantically ambiguous. Without use-time validation, the action executes against the wrong thing, no thing, an unsafe state, or an authority condition that no longer holds.

trigger_conditions: An action depends on a resource, object, record, permission, identity, inventory item, state, or external service being present or valid.

trigger_conditions: The referent was identified, cached, checked, reserved, promised, or inferred before the action actually uses it.

trigger_conditions: Time, concurrency, distributed propagation, human handoff, or external update can change referent state between check and use.

trigger_conditions: Missing, stale, or changed referents create correctness, safety, security, legal, financial, or reputational harm.

trigger_conditions: A null, missing, expired, revoked, or moved referent is currently handled by implicit assumptions, silent defaults, or late failure.

trigger_conditions: The workflow has repeated retries, ghost records, stale approvals, inventory mismatches, expired tokens, broken links, dangling references, or race-window incidents.

trigger_conditions: Stakeholders need a reliable distinction among valid-now, missing-now, unknown, changed, unauthorized, and fallback cases.

symptoms: Actions fail late because the object or resource assumed to exist is no longer present.

symptoms: A prior check passes but the state changes before the action uses the result.

symptoms: Cached identifiers point to records that have been merged, deleted, superseded, or repurposed.

symptoms: Permissions or approvals are used after revocation, expiry, role change, or context change.

symptoms: Inventory, slots, seats, funds, or capacity appear available when selected but disappear at commit time.

symptoms: Distributed components disagree about whether a referent exists or which version is current.

symptoms: A workflow proceeds with placeholder, null, default, or inferred data where a current existence check was required.

symptoms: Failures are explained as edge cases even though they come from a recurring check/use gap.

symptoms: Audit trails show a check event but do not prove the checked referent was the one actually used.

root_tension: Action needs continuity: it wants a named thing to remain the same long enough to use it. Reality is dynamic: things can expire, move, be consumed, be revoked, be edited, or be replaced. The tension is between low-friction action on assumptions and safe action on currently verified, action-bound referents.

anti_signatures: The issue is only defining valid input and output types in a static interface; use domain_codomain_delimitation.

anti_signatures: The issue is a broad go/no-go assessment before a phase transition, launch, or migration; use transition_readiness_assessment.

anti_signatures: The issue is general state-change authorization rather than existence or validity of a specific referent at use time; use guarded_state_transition.

anti_signatures: The issue is rolling back a multi-step operation after partial failure; use transactional_atomicity.

anti_signatures: The referent is immutable, single-owner, and already bound atomically to the action, so no check/use gap exists.

anti_signatures: Proceeding on stale or missing referents is harmless and explicitly accepted as a performance tradeoff.

anti_signatures: The problem is primarily reconstructing drift after it has already occurred; use reconciliation_after_drift or data_integrity_preservation.

structural_intervention: Convert implicit referent assumptions into explicit use-time gates. Name the referent and action dependency, define the current-validity predicate, observe the referent as close as possible to action, bind the validated referent to the action through a lock, lease, snapshot, version, capability, transaction, or atomic check-use operation, and define safe semantics for missing, changed, stale, revoked, ambiguous, or unknown referents.

action_logic: Identify the action and the exact referent it depends on.

action_logic: State the precondition as a current-validity predicate rather than an earlier assumption.

action_logic: Record what counts as same referent, acceptable version, authority, freshness, and availability.

action_logic: Locate the gap between earlier selection/check and actual use.

action_logic: Choose the narrowest validation moment: immediately before use or atomically with use where possible.

action_logic: Bind the checked referent to the action by lock, lease, reservation, version token, snapshot, capability, or transaction boundary.

action_logic: Differentiate absent, changed, unauthorized, expired, ambiguous, unavailable, and unknown states.

action_logic: Abort, refresh, retry, compensate, escalate, or use a safe fallback when the predicate fails or cannot be observed.

action_logic: Log the check, binding, use, and failure semantics so audit can connect the validation to the actual action.

action_logic: Tune validation cost, freshness window, and fallback latency according to risk and volatility.

decision_rules: If the referent can change between check and use, either check at use time or bind it so the checked state cannot silently diverge.

decision_rules: If identity matters, validate sameness by an explicit identity test, version, or authority claim rather than by name alone.

decision_rules: If availability matters, treat reservation/lease/lock expiry as invalid unless refreshed under a declared rule.

decision_rules: If current validity cannot be observed, return unknown, delay, or route to review rather than treating unobserved as valid.

decision_rules: If the cost of late failure is low and the operation is idempotent, retry may be acceptable; if harm is high, fail safe before use.

decision_rules: If concurrent actors can consume or alter the referent, prefer atomic check-and-use, compare-and-swap, or transaction boundaries.

decision_rules: If stale referents are deliberately tolerated for performance, disclose the staleness budget and downstream consequences.

target_invariants: The action never treats missing-now as present-now.

target_invariants: The action never treats checked-earlier as valid-now without an accepted freshness or binding rule.

target_invariants: The referent used is the same referent, version, or authority condition that was validated.

target_invariants: Revoked, expired, superseded, or ambiguous referents do not silently pass as valid.

target_invariants: Unknown or unobservable status is distinct from valid status.

target_invariants: Failure paths preserve safety, consistency, auditability, and appropriate user recovery.

expected_outcomes: Fewer null, stale-handle, broken-link, dangling-reference, and missing-resource failures.

expected_outcomes: Reduced time-of-check-to-time-of-use race incidents.

expected_outcomes: Clearer handling of expired, revoked, changed, or unavailable referents.

expected_outcomes: Better audit linkage between checks and actual actions.

expected_outcomes: Safer defaults when preconditions cannot be observed.

expected_outcomes: More honest contracts around freshness, availability, identity, and authority.

Atomic Check-Use Binding

short_definition: Combines validation and action inside one atomic or isolated operation so the referent cannot change between check and use.

distinctive_feature: The temporal gap is removed rather than merely shortened.

distinct_from_parent: The parent also covers leases, preflight checks, human confirmations, and fallback semantics; this variant uses atomicity or isolation as the primary closure method.

still_same_parent_because: It still validates current referent validity and binds that validation to the action.

use_when: Concurrent actors can alter the referent.

use_when: A stale check would create security, integrity, or safety harm.

use_when: An atomic primitive, transaction, or isolation boundary is available.

example: Update a row only if the version observed during validation is still current.

failure_modes: The operation is called atomic but still consults stale external state.

failure_modes: The isolation boundary omits a dependency outside the transaction.

Lease-Bound Availability Guard

short_definition: Allows action only while a reservation, lease, hold, or token keeps the referent available and unexpired.

distinctive_feature: The validation result is carried by a temporary binding whose validity ends at a defined event or time.

distinct_from_parent: The parent can validate directly at the instant of use; this variant validates by maintaining an explicit availability lease.

still_same_parent_because: The action proceeds only if the referent remains valid for the use moment under the lease rule.

use_when: Availability can be reserved temporarily.

use_when: The action may happen after a short delay.

use_when: Expiry and refresh semantics can be stated explicitly.

domain: ticketing

example: A seat can be purchased only while the reservation hold remains unexpired.

failure_modes: Lease renewal hides contention or starvation.

Stale-Reference Invalidation Guard

short_definition: Blocks use of cached handles, links, approvals, or records after the referent has been deleted, superseded, revoked, merged, or repointed.

distinctive_feature: The main hazard is not absence alone but stale continuity: something appears to remain valid because the reference still exists.

distinct_from_parent: The parent covers all use-time referent validation; this variant centers invalidating old references and approvals.

still_same_parent_because: It still asks whether the action-critical referent is valid now for this use.

use_when: References persist longer than the referents or permissions they name.

use_when: Caches, links, handles, or approvals are reused across time.

use_when: The system can publish invalidation, tombstone, or version-change signals.

example: A cached role approval is rejected after the role has been revoked.

failure_modes: Tombstones are garbage-collected before all users see them.

failure_modes: Aliases or redirects mask a material identity change.

Human Use-Point Confirmation

short_definition: Uses a deliberate human confirmation at the action point to verify identity, availability, consent, or readiness of the referent.

distinctive_feature: The validation channel is human perception, confirmation, or checklist discipline at the moment of action.

distinct_from_parent: The parent is channel-neutral; this variant handles checklist fatigue, rubber-stamping, and confirmation authority.

still_same_parent_because: It still gates action on current referent validity.

use_when: Automation cannot fully observe the referent.

use_when: The action is high-stakes or irreversible.

use_when: A human actor can inspect the relevant state immediately before action.

example: A team confirms patient identity and procedure site immediately before incision.

failure_modes: Confirmation becomes ritualized and misses the actual referent check.

failure_modes: Authority gradients suppress a failed check.

near_names:
Use-Time Precondition Check
Referent Existence Guard
Stale Reference Guard
TOCTOU Guard
Null Reference Guard


Use-Time Source Attribution Calibration

batch: Batch 11

canonical_family: Sampling, Inference & Statistical Bias

aliases: Reality-Monitoring Source Attribution Guardrail

alias_records: Reality-Monitoring Source Attribution Guardrail

slug: classification

slug: provenance

slug: evidence

slug: representation

slug: calibration

slug: traceability

slug: observability

slug: screening

components:
Source Class Schema
Commingled Item Inventory
Source-Cue Feature Set
Use-Time Attribution Rule
Source Confidence Annotation
Source/Content Separation
Corroboration Escalation Gate
Source Attribution Error Profile
Downstream Language Policy
Provenance Backlink or Trace
Decision Stakes Tier
Attribution Feedback Loop
Unknown-Source Holding State
Borrowed Material Credit Path
Generated Output Source Label
Source-Cue Decay Monitor

mechanisms: Source-Label Preserving Summary Template

essence_one_line: Before using a commingled memory, note, claim, trace, or generated output, classify where it came from and how certain that attribution is.

compression_statement: Use-Time Source Attribution Calibration applies when information items from different source classes share the same store, workspace, model, memory, or record system, but downstream action depends on whether a given item was perceived, inferred, imagined, copied, generated, observed, reported, or reconstructed. The archetype builds a use-time attribution gate: recover source-correlated cues, compare them against source-class criteria, attach confidence, preserve uncertainty, and route high-stakes or low-confidence items to corroboration before they are treated as evidence.

core_intuition: A system can remember or store content without remembering how the content arrived. That is useful because ideas, observations, inferences, and simulations can all inform action. It is dangerous because the same fluent item can later feel equally available whether it came from observation, imagination, hearsay, model completion, or copied work. The intervention does not ban internal generation; it makes source status explicit enough that the item receives the right evidential weight.

canonical_formula: commingled_item_store + source_cues + use_time_source_classification + confidence_annotation + corroboration_gate -> source_appropriate_weighting; fluent_trace - source_discrimination -> hallucination_intrusion_or_borrowed-source_misattribution

structural_problem: Items from multiple source classes are accumulated in a common store, but their provenance markers are incomplete, decayed, implicit, or unavailable at the moment of use. Downstream users then treat internally generated material as externally perceived evidence, external material as their own idea, reconstruction as observation, or low-confidence inference as settled fact. The error is not merely missing metadata; it is the failure to reconstruct and act on source class when the item is retrieved or applied.

condition: Commingled information store

description: Memories, notes, documents, claims, traces, model outputs, or observations from different source classes are stored together or surfaced through the same interface.

condition: Use depends on source class

description: The evidential weight, attribution, rights, responsibility, or permissible action differs depending on whether the item was perceived, inferred, simulated, copied, generated, reported, or reconstructed.

condition: Source cues are indirect or degraded

description: Source status must be inferred from perceptual detail, metadata, custody traces, production signatures, cognitive-operation markers, confidence, or contextual records rather than from a perfectly preserved label.

condition: Fluency can masquerade as evidence

description: Familiar, coherent, or easy-to-retrieve content may be mistaken for externally grounded content even when it was internally produced or reconstructed.

condition: Errors have downstream consequences

description: Misattribution can create false evidence, hallucinated facts, plagiarism or credit loss, mistaken responsibility assignment, poor clinical or legal judgment, or corrupted records.

condition: Corroboration is possible for important cases

description: At least some source attributions can be tested against records, independent witnesses, custody trails, metadata, external measurements, or repeat observation.

symptom: Confident but untraceable claims

signal: Users can state the content but cannot identify whether it was observed, inferred, heard, copied, imagined, or generated.

symptom: Internal content treated as external evidence

signal: Draft ideas, simulations, predictions, mental images, or model completions are cited as if they were observations or records.

symptom: Borrowed material treated as original

signal: A user or system repeats language, ideas, or judgments from another source while experiencing them as self-generated.

symptom: Observation and reconstruction collapse

signal: Later backfill, summarization, or narrative smoothing makes original traces indistinguishable from interpretation.

symptom: Missing confidence marks

signal: The source label, if present, travels without uncertainty, cue basis, or reason for source attribution.

symptom: Source disputes recur late

signal: Teams repeatedly revisit whether a claim came from data, witness report, expert inference, AI output, prior template, or assumption only after decisions have been made.

symptom: High-stakes use without source recheck

signal: Reports, diagnoses, investigations, publications, or automated decisions use uncertain items without reopening the source-attribution question.

root_tension: A shared store improves integration because content from perception, inference, memory, simulation, and external reports can interact. But the more integrated and fluent the store becomes, the easier it is to lose source distinctions that determine evidential weight, ownership, accountability, and action. Over-labeling every item can slow cognition and work; under-labeling lets source errors propagate as facts.

anti_signatures: Use canonical_classification when the main problem is designing stable categories for many entities, not reconstructing the source class of a retrieved item.

anti_signatures: Use source_provenance_triangulation when the main problem is assessing external accounts by origin, proximity, perspective, corroboration, and reliability.

anti_signatures: Use appearance_vs_reality_distinction_audit when the main problem is separating experience or appearance from claims about underlying reality.

anti_signatures: Use cautious_pattern_completion when the main problem is filling missing content while marking inference, not deciding the source class of a content item.

anti_signatures: Use state_estimation when the main problem is inferring a hidden system state from signals, not assigning provenance/source class to a trace.

anti_signatures: Do not use this archetype when all items already carry trusted immutable provenance and downstream action does not depend on source class.

anti_signatures: Do not use this archetype as a blanket distrust rule against imagination, simulation, inference, or generated content; those sources can be useful when correctly labeled and weighted.

structural_intervention: Install a use-time source-attribution gate around commingled information: define source classes, preserve or reconstruct source cues, score attribution confidence, route low-confidence or high-stakes items to corroboration, attach source-and-confidence annotations to downstream use, and feed confirmed attribution errors back into cue design and storage practice.

action_logic: Define the source classes that matter for the domain, such as directly observed, externally reported, copied, inferred, simulated, internally generated, model-generated, reconstructed, or unknown.

action_logic: Identify which source-correlated cues are available: perceptual detail, timestamp, custody path, production signature, metadata, citation lineage, cognitive-operation record, context, medium, and confidence history.

action_logic: Set a use-time attribution rule that classifies the item from cues rather than from fluency, familiarity, authority, or desired conclusion alone.

action_logic: Attach a confidence annotation and cue basis to the attribution, not just a binary source label.

action_logic: Route low-confidence or high-stakes items through external grounding, provenance lookup, independent corroboration, or controlled re-observation before they are used as evidence.

action_logic: Preserve uncertainty in downstream language: observed, inferred, remembered, reported, generated, reconstructed, or source unknown should remain distinguishable.

action_logic: Track false externalization, false internalization, borrowed-source loss, and reconstruction-as-observation errors as separate error modes.

action_logic: Backtest disputed or later-corrected attributions to improve storage metadata, cue capture, prompts, training examples, interface warnings, and decision thresholds.

action_logic: Protect legitimate internal generation by giving it a labeled route into reasoning rather than forcing it to masquerade as evidence or be discarded.

rule: Increase source-attribution strictness as action stakes rise.

rationale: Low-stakes brainstorming can tolerate weak source labels; publication, diagnosis, legal judgment, safety decisions, and automated action require stronger source grounding.

rule: Treat fluency as a weak cue, not a source proof.

rationale: Ease of recall or coherence can arise from repetition, imagination, model completion, or reconstruction as well as perception.

rule: Separate content confidence from source confidence.

rationale: A claim can be true but misattributed, or correctly sourced but weakly supported.

rule: Prefer reversible uncertainty over premature source certainty.

rationale: Marking source unknown preserves a path to corroboration; a false source label tends to propagate unnoticed.

rule: Use independent corroboration when source class changes evidential weight.

rationale: If an item is only usable as external evidence, self-report, original idea, or official record under certain source classes, verify before relying on it.

rule: Track symmetric errors.

rationale: The system should notice both internal-to-external intrusions and external-to-internal borrowing, not only one culturally salient error type.

target_invariants: Source class remains distinguishable from content truth, content quality, and user confidence.

target_invariants: Unknown or low-confidence source status can travel downstream without being silently normalized into fact.

target_invariants: Internally generated, simulated, or inferred material can be used, but only under a label appropriate to its warrant.

target_invariants: External records, borrowed ideas, and copied material retain enough attribution to support credit, accountability, and verification.

target_invariants: High-stakes use triggers stronger corroboration than low-stakes exploration.

target_invariants: Attribution-error feedback updates cue capture and decision thresholds instead of merely correcting one item.

expected_outcomes: Fewer hallucinated, imagined, reconstructed, or inferred items treated as observations.

expected_outcomes: Fewer borrowed or externally supplied ideas treated as self-generated original material.

expected_outcomes: Clearer evidence weighting because source class and confidence travel with the item.

expected_outcomes: Earlier detection of degraded, missing, or ambiguous provenance before downstream use.

expected_outcomes: Better audit trails for disputed claims, decisions, reports, and generated outputs.

expected_outcomes: Improved calibration of source-attribution rules through feedback from known errors.

expected_outcomes: More productive use of simulations, hypotheses, and generated content because they are labeled rather than suppressed.

name: Internal Content Externalization Guardrail

short_definition: Prevents imagined, simulated, inferred, or model-completed material from being used as if it were externally observed evidence.

distinctive_feature: Focuses on false externalization errors.

distinct_from_parent: Narrower than the parent because it handles one directional error: internal-to-external misattribution.

still_same_parent_because: It uses the same source-class cue, confidence, and corroboration gate.

use_when: Generated or internally reconstructed material enters evidence channels.

use_when: Fluency or vividness can be mistaken for observation.

Borrowed Source Recognition Check

short_definition: Detects when externally supplied ideas, phrases, or judgments are being experienced or presented as self-generated.

distinctive_feature: Focuses on false internalization and credit loss.

distinct_from_parent: Narrower than the parent because the relevant source-class distinction is external-origin versus self-origin.

still_same_parent_because: It is still a use-time source-attribution error control.

use_when: Authorship, originality, credit, or responsibility depends on recognizing an external source.

use_when: Repeated exposure makes another source feel self-generated.

Generated Output Reality Monitoring

short_definition: Marks and checks AI-generated or automated content before it is treated as retrieved fact, human analysis, or external evidence.

distinctive_feature: Handles model-generated content entering human or organizational records.

distinct_from_parent: Domain-specific to AI and automation contexts.

still_same_parent_because: It retains the parent’s source-class cue and confidence logic.

use_when: Model outputs are blended into notes, reports, decisions, or memory stores.

use_when: Users may confuse generation, retrieval, and observation.

Reconstructed Record Source Check

short_definition: Differentiates original observations from later backfill, summary, reconstruction, or interpretation when records are used.

distinctive_feature: Emphasizes temporal decay and reconstruction-as-observation errors.

distinct_from_parent: Narrower because its key cue problem is time-delayed record reconstruction.

still_same_parent_because: It still applies source-class attribution at the moment of use.

use_when: Delay or transformation has degraded evidence fidelity.

use_when: Reports or records contain mixtures of observation and reconstruction.

Source-Unknown Holding Variant

short_definition: Preserves a usable but non-evidence-grade holding state for items whose source class cannot yet be attributed confidently.

distinctive_feature: Makes unknown source status operational rather than a failure to classify.

distinct_from_parent: Implementation variant focused on the unknown-source state and action permissions.

still_same_parent_because: It is governed by source attribution confidence and downstream use thresholds.

use_when: Forcing a source label would create false certainty.

use_when: The item may still be useful for hypothesis generation or exploration.

near_names:
Reality Monitoring Design
Source Discrimination Gate
Internal/External Source Check
Provenance at Use Time