Source-of-Truth Assignment

batch: First Iteration/Batch 08

aliases:
Single Source of Truth
Authoritative Source Assignment
System-of-Record Assignment
Truth Source Governance

alias_records:
Single Source of Truth
Authoritative Source Assignment
System-of-Record Assignment
Truth Source Governance

related_primes: delegation_of_authority representation versioning accountability access_control interoperability closure function set_and_membership cardinality invariance boundary hierarchy legitimacy

slug: relation

slug: representation

slug: versioning

slug: accountability

slug: interoperability

slug: closure

slug: function

slug: cardinality

slug: invariance

slug: boundary

slug: hierarchy

slug: legitimacy

components:
Represented Subject
Competing Representation Inventory
Authoritative Source
Authority Boundary
Precedence Rule
Update Rights
Synchronization Rule
Conflict Resolution Rule
Stewardship Owner
Audit Trail
Exception Rule
Canonical Identifier
Alias Mapping
Version Record
Deprecation Path
Reconciliation Report
Access-Control Rule

mechanisms:
System-of-Record Designation
Master Data Management
Canonical Registry
Official Record Policy
Source-Control Main Branch
Authoritative Policy Repository
Golden Record Consolidation
Access and Update Rights Matrix
Synchronization Job
Conflict Resolution Workflow
Change Log and Audit Trail
Deprecation and Forwarding Notice

essence_one_line: Assign authoritative status to one representation or system so conflicting versions can be resolved consistently.

compression_statement: When multiple representations claim to describe the same thing but disagree, designate the representation that governs for a defined scope, define update rights and conflict rules, and propagate or qualify dependent copies so decisions remain consistent and accountable.

core_intuition: A conflict among representations is not solved by adding another copy. It is solved by making the authority relation explicit: who or what gets believed, for which field or decision, under which update process, and how other representations must defer, synchronize, challenge, or retire.

canonical_formula: competing_representations + authority_boundary + authoritative_source + update_and_conflict_rules → reliable_governing_state

structural_problem: Multiple records, systems, actors, documents, models, versions, or repositories claim to represent the same subject, but they disagree and no governed rule determines which representation controls action.

trigger_conditions: Different systems report conflicting values, statuses, obligations, permissions, definitions, or versions for the same subject.

trigger_conditions: Actors choose records opportunistically, locally, or historically because no precedence rule is accepted.

trigger_conditions: The same policy, asset, identity, model, contract, or decision appears in many places with different update histories.

trigger_conditions: Downstream work depends on a stable answer but receives inconsistent inputs from parallel representations.

trigger_conditions: Copies, caches, extracts, summaries, or dashboards are mistaken for governing sources.

trigger_conditions: Disputes require knowing which source controls and who may correct it when it is wrong.

symptoms: Teams make different decisions because they consult different records or repositories.

symptoms: A stale copy overrides a current record because it is more visible or easier to access.

symptoms: Conflicting versions circulate without a deprecation signal or redirect to the governing source.

symptoms: Corrections happen in local systems but never reach the source that downstream systems trust.

symptoms: Audits cannot reconstruct why a particular value, policy, status, or decision was treated as official.

symptoms: Arguments focus on whose spreadsheet, memory, branch, or document is “real” rather than on a governed authority rule.

symptoms: A record appears authoritative but no owner, update process, or challenge path exists.

root_tension: Systems need multiple representations for local usefulness, speed, translation, historical memory, reporting, and resilience, but decisions need a reliable governing representation when those copies diverge. Too little authority creates inconsistency; too much centralized authority creates bottlenecks, stale truth, and suppressed local knowledge.

anti_signatures: The problem is only that relationships among entities are unknown; use relation_mapping or dependency_exposure first.

anti_signatures: The issue is creating evidence or change links among artifacts rather than choosing which representation governs; use traceability_linking.

anti_signatures: The issue is preserving general data accuracy, completeness, or provenance across a lifecycle; compare data_integrity_preservation.

anti_signatures: The issue is making equivalent variants share treatment without selecting a governing representation; use equivalence_class_consolidation or equivalence_normalization.

anti_signatures: The issue is merely naming or identifying the same thing consistently; compare canonical_naming_and_reference rather than source-of-truth assignment.

anti_signatures: The issue is validating relationship structure, such as cardinality or compatibility; use relation_constraint_enforcement.

structural_intervention: Designate a scoped authoritative source, define what it governs, assign update and stewardship rights, specify conflict and exception rules, and govern how dependent representations synchronize, defer, challenge, or retire.

action_logic: Identify the represented subject and the representations that currently claim or imply authority over it.

action_logic: Determine the decision scope: which fields, statuses, definitions, policy statements, versions, or obligations need an authoritative answer.

action_logic: Select or construct the authoritative source using legitimacy, evidence quality, stewardship capacity, accessibility, update reliability, and downstream impact.

action_logic: Define the authority boundary so the chosen source governs only the cases and attributes it can validly represent.

action_logic: Specify update rights, approval paths, correction rights, override conditions, and stewardship obligations.

action_logic: Define precedence and conflict-resolution rules for disagreements among authoritative, secondary, cached, historical, or derived representations.

action_logic: Define synchronization, publication, deprecation, and redirect paths so secondary copies do not silently become competing sources of truth.

action_logic: Record authority changes, overrides, disputes, and corrections in an audit trail and review them when conflicts recur.

decision_rules: Assign authority only for a defined scope; avoid treating one source as globally authoritative for every attribute or context.

decision_rules: Prefer the source with the strongest stewardship, correction path, and legitimate update process, not simply the most complete or convenient source.

decision_rules: Treat secondary copies as useful views only when they clearly identify their dependency on the authoritative source and their possible staleness.

decision_rules: Allow challenge when the authoritative source is stale, corrupt, out of scope, updated by an invalid process, or contradicted by higher-order authority.

decision_rules: Separate read authority from update authority when many actors need access but few should change governing state.

decision_rules: Make exceptions visible, bounded, justified, and reviewed so emergency overrides do not become shadow authority.

decision_rules: Retire, redirect, or label outdated copies rather than letting multiple “truths” persist by default.

target_invariants: Every governed conflict has a defined precedence rule or escalation path.

target_invariants: The authoritative source is scoped, stewarded, challengeable, and auditable.

target_invariants: Update rights are explicit enough to prevent unauthorized or accidental authority changes.

target_invariants: Historical records remain interpretable without being mistaken for current governing state.

target_invariants: Exceptions do not erase the normal authority structure; they create reviewable records.

expected_outcomes: Reduced decision inconsistency caused by conflicting records, versions, or repositories.

expected_outcomes: Clearer accountability for who maintains governing state and who may change it.

expected_outcomes: Faster conflict resolution because actors know which source governs and how to challenge it.

expected_outcomes: Improved data integrity, policy reliability, auditability, and interoperability across systems.

prose_essence:
Source-of-Truth Assignment is the pattern of turning a conflict among representations into a governed authority relation. It does not simply create a repository, dashboard, or table. It asks: which representation controls action when several plausible records, versions, systems, or actors disagree, and under what conditions can that governing source be updated, challenged, synchronized, or superseded?

The pattern is especially important when many copies are useful but only one answer can safely govern a decision. A dashboard may be useful; a policy PDF may be convenient; a local spreadsheet may be close to the work; a branch may be experimental. The archetype clarifies which of these is allowed to settle conflict for a defined scope.

prose_when_to_use:
Use this archetype when the practical failure is not absence of information but conflict among representations that all appear plausible or official.

- There are repeated conflicts among representations that claim to describe the same subject.
- Downstream action depends on a consistent answer rather than merely knowing all versions exist.
- A legitimate steward, owner, governance body, or update path can maintain the authoritative source.
- Secondary representations can be synchronized, labeled, deprecated, redirected, or kept as non-authoritative views.
- Users or systems can access the authoritative source or a trustworthy reflection of it when needed.
- The organization can tolerate some central coordination in exchange for consistency and accountability.

Do not use it merely because a team wants a neater filing system. Use it when decisions, obligations, permissions, identities, states, or versions need a governing source.

prose_structural_problem:
The structural problem is competing representation without accepted precedence. Multiple artifacts claim to describe the same underlying subject, but no governed relationship says which one controls. The subject might be a customer, asset, patient, policy, contract, codebase, dataset, decision, role assignment, or operational state.

This creates a characteristic failure: everyone can point to evidence, but the system cannot decide which evidence governs. The result is local truth, stale truth, shadow truth, and informal authority. People make different decisions because they consult different repositories, or because they treat the most convenient copy as if it were current.

prose_intervention_logic:
The intervention is to designate a scoped authoritative source and make the consequences of that designation operational. First identify the represented subject and the competing representations. Then define the authority boundary: what exactly does the chosen source govern, and where does it not govern? Next define update rights, stewardship, conflict resolution, synchronization, exceptions, and audit.

The important move is not centralization for its own sake. The move is making the authority relation explicit enough that downstream systems and people know whether they are reading governing state, derived state, cached state, historical state, or local interpretation.

A useful shorthand is:

`competing representations + scoped authority + update rights + conflict rules → reliable governing state`

prose_key_components:
- **Represented Subject (`represented_subject`): Identifies the thing, person, policy, asset, obligation, state, or decision that multiple records or representations claim to describe. The subject must be clear enough that competing representations can be recognized as claims about the same underlying object or state rather than merely similar items.
- **Competing Representation Inventory (`competing_representation_inventory`): Lists the records, systems, actors, repositories, models, documents, or branches that currently claim authority or appear to represent the same subject. Without this inventory, a source-of-truth choice may be symbolic: conflicts remain hidden in systems that were not included in the assignment.
- **Authoritative Source (`authoritative_source`): Designates the representation whose value, statement, state, or decision governs when other representations disagree. The authoritative source is not automatically the oldest, most detailed, most convenient, or most visible representation; it is the one explicitly given precedence for a defined scope.
- **Authority Boundary (`authority_boundary`): Defines the scope within which the selected source is authoritative and the cases where its authority does not apply. A record may be authoritative for identity but not payment status, for current policy but not historical interpretation, or for operational execution but not legal meaning.
- **Precedence Rule (`precedence_rule`): States how conflicts among representations are resolved when the authoritative source, secondary records, cached copies, derived views, or human claims disagree. Precedence rules prevent actors from choosing whichever representation is convenient in the moment and make conflict resolution repeatable.
- **Update Rights (`update_rights`): Specifies who or what may create, edit, approve, override, retire, or restore authoritative state. Update rights convert authority from a label into a governed relation among actors, records, workflows, and change conditions.
- **Synchronization Rule (`synchronization_rule`): Defines how authoritative state is propagated, mirrored, transformed, or withheld from dependent systems and downstream representations. Synchronization rules are needed because source-of-truth assignment rarely eliminates all other representations; it governs how they should align or explicitly remain secondary.
- **Conflict Resolution Rule (`conflict_resolution_rule`): Defines what happens when disagreement is detected: accept the authoritative source, investigate, reconcile, quarantine, escalate, or correct the source itself. The rule must allow the authoritative source to be challenged when it is stale, corrupt, out of scope, or updated by an invalid process.
- **Stewardship Owner (`stewardship_owner`): Assigns responsibility for maintaining the authoritative source, resolving disputed cases, reviewing exceptions, and updating authority boundaries as conditions change. A source of truth without stewardship decays into an abandoned artifact that still carries apparent authority.
- **Audit Trail (`audit_trail`): Records changes, overrides, synchronization events, conflict resolutions, and authority transfers so authoritative state remains accountable and interpretable. The audit trail protects against silent rewrites and helps downstream actors understand why a value, policy, or decision became authoritative.
- **Exception Rule (`exception_rule`): Defines when secondary evidence, emergency override, legal requirement, local context, or domain expert review may temporarily supersede the normal source-of-truth rule. Exception rules preserve flexibility without dissolving authority into ad hoc preference. They should include owner, duration, justification, and review path.

These components are mutually reinforcing. The authoritative source is weak without an authority boundary. The boundary is weak without update rights. Update rights are unsafe without audit and challenge. Synchronization is misleading without precedence rules. Exception handling preserves flexibility without letting every exception become a new shadow source of truth.

prose_common_mechanisms:
Mechanisms implement the archetype in specific domains. They should not be mistaken for the archetype itself; a repository, registry, branch, or master record becomes part of Source-of-Truth Assignment only when it carries scoped authority and is governed by update, synchronization, conflict, stewardship, and exception rules.

- **System-of-Record Designation (`system_of_record_designation`): This is a governance_and_information_architecture implementation. Names one system as the governing record for a defined subject, field, workflow, or decision scope. It implements the archetype only when it is tied to scoped authority, update rights, conflict handling, and stewardship.
- **Master Data Management (`master_data_management`): This is a software_and_governance_process implementation. Coordinates authoritative data, stewardship, synchronization, and duplicate-resolution rules across many applications or business units. It implements the archetype only when it is tied to scoped authority, update rights, conflict handling, and stewardship.
- **Canonical Registry (`canonical_registry`): This is a registry_or_repository implementation. Maintains an official list of entities, identifiers, statuses, permissions, assets, policies, or definitions that other systems reference. It implements the archetype only when it is tied to scoped authority, update rights, conflict handling, and stewardship.
- **Official Record Policy (`official_record_policy`): This is a policy_and_records_governance implementation. Specifies which document, filing, repository, or register is authoritative for legal, operational, historical, or compliance purposes. It implements the archetype only when it is tied to scoped authority, update rights, conflict handling, and stewardship.
- **Source-Control Main Branch (`source_control_main_branch`): This is a version_control_workflow implementation. Treats a branch, trunk, release tag, or reviewed merge path as authoritative for code, configuration, content, or model state. It implements the archetype only when it is tied to scoped authority, update rights, conflict handling, and stewardship.
- **Authoritative Policy Repository (`authoritative_policy_repository`): This is a knowledge_repository implementation. Collects current policy statements in one governed location so outdated copies, summaries, or local interpretations can be resolved against it. It implements the archetype only when it is tied to scoped authority, update rights, conflict handling, and stewardship.
- **Golden Record Consolidation (`golden_record_consolidation`): This is a data_governance_method implementation. Builds or designates a consolidated record that resolves duplicates and conflicting fields into an authoritative view. It implements the archetype only when it is tied to scoped authority, update rights, conflict handling, and stewardship.
- **Access and Update Rights Matrix (`access_and_update_rights_matrix`): This is a governance_artifact implementation. Maps actors, systems, fields, or states to allowed viewing, editing, approval, override, and publication rights. It implements the archetype only when it is tied to scoped authority, update rights, conflict handling, and stewardship.
- **Synchronization Job (`synchronization_job`): This is a automation implementation. Propagates authoritative values, statuses, or versions into dependent systems while recording lag, transformation, and failure conditions. It implements the archetype only when it is tied to scoped authority, update rights, conflict handling, and stewardship.
- **Conflict Resolution Workflow (`conflict_resolution_workflow`): This is a process implementation. Routes detected disagreements among representations through review, correction, escalation, or authoritative override. It implements the archetype only when it is tied to scoped authority, update rights, conflict handling, and stewardship.
- **Change Log and Audit Trail (`change_log_and_audit_trail`): This is a recordkeeping_mechanism implementation. Preserves who changed authoritative state, when, why, under what right, and with what downstream propagation. It implements the archetype only when it is tied to scoped authority, update rights, conflict handling, and stewardship.
- **Deprecation and Forwarding Notice (`deprecation_and_forwarding_notice`): This is a lifecycle_mechanism implementation. Marks obsolete representations as non-authoritative and directs users or systems to the current authoritative source. It implements the archetype only when it is tied to scoped authority, update rights, conflict handling, and stewardship.

prose_failure_modes:
- **false_global_authority**: One source is treated as authoritative for every field, context, or time period even though its authority should be scoped. Mitigation: Define authority boundaries at field, state, domain, role, jurisdiction, version, or lifecycle level.
- **stale_authoritative_source**: The official source is harder to update than local copies, so it falls behind while still being treated as governing. Mitigation: Assign stewardship, update service-level expectations, correction paths, and visible freshness indicators.
- **shadow_source_of_truth**: Users rely on unofficial spreadsheets, chats, caches, or local repositories because the authoritative source is inaccessible or unhelpful. Mitigation: Improve access, usability, synchronization, and deprecation signals; audit recurring shadow-source use.
- **authority_without_accountability**: A source is designated as authoritative but no steward owns errors, disputes, updates, or exceptions. Mitigation: Assign stewardship owner, review cadence, audit trail, and escalation path before treating the source as governing.
- **synchronization_mistaken_for_authority**: A downstream copy appears current and official, so actors treat it as authoritative even when it is delayed or transformed. Mitigation: Label copied state, expose synchronization freshness, and define precedence when copied state disagrees with the source.
- **uncorrectable_truth**: Authority is treated as infallibility, so contradictory evidence cannot trigger review or correction. Mitigation: Include conflict resolution and challenge rules that allow the authoritative source itself to be corrected.
- **ambiguous_authority_transfer**: A new repository, branch, or policy version is introduced without retiring or redirecting the old one. Mitigation: Use deprecation paths, forwarding notices, version records, and publication rules for authority transfer.
- **power_capture**: A group designates its own representation as authoritative to suppress other valid perspectives or local evidence. Mitigation: Require legitimacy criteria, stakeholder review, appeal channels, and external audit for high-stakes authority assignments.

These failure modes often arise when the label “source of truth” is applied to an artifact without giving it the maintenance structure needed to deserve that authority.

prose_neighbor_distinctions:
- **Data Integrity Preservation (`data_integrity_preservation`): Data integrity preservation protects accuracy, consistency, provenance, and completeness across a lifecycle. Source-of-Truth Assignment specifically resolves disagreement by assigning governing authority to a representation or source within a defined scope.
- **Traceability Linking (`traceability_linking`): Traceability links origins, requirements, decisions, implementations, and outcomes. Source-of-Truth Assignment decides which linked representation governs when linked artifacts disagree.
- **Relation Mapping (`relation_mapping`): Relation mapping makes associations explicit. Source-of-Truth Assignment changes governance by giving one representation precedence over competing representations.
- **Relation Constraint Enforcement (`relation_constraint_enforcement`): Relation constraint enforcement defines valid relationship states. Source-of-Truth Assignment defines which representation has authority when states or records conflict.
- **Equivalence Class Consolidation (`equivalence_class_consolidation`): Equivalence class consolidation groups variants for shared treatment. Source-of-Truth Assignment may use equivalence to identify competing records, but its core act is choosing or constructing the governing representation.
- **Equivalence Normalization (`equivalence_normalization`): Equivalence normalization standardizes representation. Source-of-Truth Assignment establishes precedence and update rights among representations that may remain distinct.
- **Canonical Naming and Reference (`canonical_naming_and_reference`): Canonical naming creates stable names or identifiers. Source-of-Truth Assignment determines which record, repository, branch, actor, or policy governs conflict, even when naming is already canonical.
- **Bidirectional Consistency Mapping (`bidirectional_consistency_mapping`): Bidirectional consistency mapping maintains correspondence between two representations. Source-of-Truth Assignment may intentionally make synchronization asymmetric because one side governs the other.
- **Source Provenance Triangulation (`source_provenance_triangulation`): Source provenance triangulation evaluates evidence quality, proximity, and corroboration. Source-of-Truth Assignment gives a source governing status for decisions after or alongside that evaluation.
- **Versioned Evolution (`versioned_evolution`): Versioned evolution preserves and manages successive states over time. Source-of-Truth Assignment decides which current or historical version is authoritative for a given action or interpretation.

The main boundary to preserve is this: Source-of-Truth Assignment chooses or constructs the governing representation. It may use traceability, equivalence, naming, synchronization, or relation constraints, but those supporting patterns are not the same as the authority assignment.

prose_cross_domain_examples:
- **customer_data**: The customer master governs legal customer identity, while marketing and support platforms hold synchronized or local views.
- **policy_governance**: The compliance portal supersedes emailed policy PDFs; old documents must redirect to the current governed version.
- **software_delivery**: The main branch and release tag define deployable code; feature branches are proposals until merged through review.
- **healthcare**: The medication list in the clinical record governs active medications, while pharmacy claims provide supporting evidence and discrepancy triggers.
- **asset_management**: The asset registry governs equipment ownership and status; local spreadsheets are secondary reports.
- **research**: A published dataset release governs analysis replication, while notebooks and extracts are derivative views.
- **governance**: Approved minutes and decision records govern over personal notes when reconstructing organizational decisions.

Extended example: A company has customer information in a CRM, billing system, support tool, marketing database, and local account spreadsheets. Each system contains some correct values and some stale values. Instead of asking employees to decide case by case which value to trust, the company assigns source-of-truth status by field: the CRM governs legal name and account owner, billing governs outstanding balance and payment terms, support governs open case status, and the customer identity service governs canonical identifiers. Update rights are assigned to specific roles and workflows. Secondary systems receive synchronized values, show freshness where lag matters, and route conflicts through a reconciliation workflow. Old spreadsheets are not deleted immediately, but they are labeled non-authoritative and redirected. The result is not a single database containing all reality; it is a governed authority structure across multiple representations.

prose_non_examples:
- **A team creates a dashboard that shows the latest value it can fetch from several systems.** The dashboard is a view; without authority, update rights, and conflict rules, it does not assign a source of truth.
- **A glossary defines a preferred label for a concept.** This is canonical naming unless the glossary is also the authoritative repository for governing decisions.
- **A requirements matrix links requirements to tests.** This is traceability linking; it shows relationships but does not necessarily make one representation governing.
- **Two databases are synchronized both ways with last-write-wins conflict handling.** This is closer to bidirectional consistency mapping unless one representation or rule is explicitly authoritative.
- **A manager says “trust my spreadsheet” without scope, update rights, audit, or challenge process.** That is an informal assertion of authority, not a governed source-of-truth assignment.

prose_tradeoffs:
- Consistency improves, but local flexibility can decline when secondary sources must defer to a governing representation.
- Central authority reduces conflict, but it can create bottlenecks if update rights and stewardship capacity are too narrow.
- A single governing source simplifies decisions, but overly broad scope can erase legitimate contextual differences.
- Synchronization makes dependent systems coherent, but it introduces lag, transformation errors, and integration maintenance.
- Auditability improves, but maintaining logs, version records, challenge paths, and exception reviews adds overhead.
- Authority assignment can improve accountability, but it can also concentrate power if correction and appeal paths are weak.

The archetype is therefore not a blanket argument for centralization. It is a governance pattern for preserving consistency while still allowing local views, historical records, derived reports, and exceptions.

prose_invariants_to_preserve:
- Every governed conflict has a defined precedence rule or escalation path.
- The authoritative source is scoped, stewarded, challengeable, and auditable.
- Update rights are explicit enough to prevent unauthorized or accidental authority changes.
- Secondary representations remain linked to, synchronized with, or explicitly distinguished from the source of truth.
- Historical records remain interpretable without being mistaken for current governing state.
- Exceptions do not erase the normal authority structure; they create reviewable records.
- Downstream systems know whether they are reading authoritative state, derived state, cached state, or local interpretation.

The central invariant is that conflict among representations has a defined resolution path. The authoritative source may be corrected, but it should not be bypassed silently.

prose_target_outcomes:
- Reduced decision inconsistency caused by conflicting records, versions, or repositories.
- Clearer accountability for who maintains governing state and who may change it.
- Faster conflict resolution because actors know which source governs and how to challenge it.
- Improved data integrity, policy reliability, auditability, and interoperability across systems.
- Lower risk that stale copies, local spreadsheets, informal memories, or old branches override current governing state.
- More reliable synchronization because dependent systems have a defined authority relation rather than equal competing claims.

A successful implementation makes disagreements easier to detect, easier to route, and easier to resolve. It also makes it clearer when a user is looking at a current governing source versus a useful but secondary representation.

prose_parameter_dimensions:
Key tuning dimensions include the scope of authority, the granularity of field-level authority, the strictness of precedence, the number of actors with update rights, the allowed synchronization lag, the visibility of freshness indicators, the strength of audit requirements, and the ease of challenging the authoritative source.

A narrow authority boundary reduces overreach but can make coordination complex. A broad authority boundary reduces confusion but can erase local context. Automated synchronization improves consistency but can spread errors quickly. Manual stewardship can preserve judgment but may become a bottleneck.

prose_variants_and_near_names:
- **System-of-Record Assignment (`system_of_record_assignment`): Designate one operational system as authoritative for a defined entity, field, state, or transaction class. Its distinct feature is that the authoritative source is a system in an information architecture rather than a single policy, person, or document.
- **Golden Record Assignment (`golden_record_assignment`): Create or designate a consolidated record that resolves duplicates and conflicting attributes into a governing representation. Its distinct feature is that the source of truth is a consolidated representation produced from multiple inputs, not merely one preexisting repository.
- **Authoritative Policy Repository (`authoritative_policy_repository`): Designate one governed repository as the current authority for policies, procedures, standards, or rule interpretations. Its distinct feature is that the represented subject is a rule, standard, procedure, or obligation rather than an entity record.
- **Official Record Assignment (`official_record_assignment`): Identify which document, filing, register, or archive entry has official standing when informal, draft, duplicate, or historical records conflict. Its distinct feature is that the authority is tied to official status, record custody, acceptance criteria, and retention obligations.
- **Branch Authority Assignment (`branch_authority_assignment`): Designate a branch, trunk, release, or reviewed merge path as authoritative among many evolving versions. Its distinct feature is that authority is temporal and versioned; a source can be authoritative now, superseded later, or authoritative only for a release line.
- **Decision Authority Source Assignment (`decision_authority_source_assignment`): Identify which actor, role, committee, rule, or decision record governs when competing interpretations or approvals exist. Its distinct feature is that the authoritative source may be an accountable role or decision body, not only a data repository.

Near names include **single source of truth**, **system of record**, **authoritative source selection**, **golden record**, **master record**, **official record**, **authoritative repository**, and **main branch**. These names should point to the parent or to a named variant unless the case lacks authority boundaries, update rights, and conflict rules.

System-of-Record Assignment

short_definition: Designate one operational system as authoritative for a defined entity, field, state, or transaction class.

distinctive_feature: The authoritative source is a system in an information architecture rather than a single policy, person, or document.

distinct_from_parent: It narrows the parent to operational information systems and their fields, integration paths, and synchronization rules.

still_same_parent_because: It still assigns authoritative status and resolves disagreement among representations by precedence and update rights.

use_when: Different software systems hold conflicting values for the same entity or transaction.

use_when: Downstream action requires a reliable answer about which system governs a particular field or state.

use_when: Copies, caches, extracts, or reports are useful but should not override the governing record.

example: The customer master is authoritative for legal name while the billing platform is authoritative for outstanding balance.

example: The electronic medical record governs active medication status while the patient portal is a secondary display.

failure_modes: A system is declared authoritative for too broad a scope and overrides domain-specific sources it should not govern.

failure_modes: Synchronization lag makes a secondary system appear wrong even though it has not yet received the authoritative update.

Golden Record Assignment

distinctive_feature: The source of truth is a consolidated representation produced from multiple inputs, not merely one preexisting repository.

distinct_from_parent: It adds equivalence, deduplication, and consolidation logic to the parent authority-selection pattern.

still_same_parent_because: The consolidated record becomes governing only because it is assigned authority and maintained through update and conflict rules.

use_when: Multiple records refer to the same entity but disagree on key attributes.

use_when: A canonical operational view is needed without deleting every local or historical copy.

use_when: Equivalence and identity resolution must feed an authoritative record used downstream.

example: Duplicate customer records are merged into a golden record that governs service eligibility.

example: Many local asset listings are reconciled into one authoritative inventory record.

failure_modes: Consolidation suppresses legitimate local differences under a single record.

failure_modes: The golden record is trusted even after its matching rules become stale.

Authoritative Policy Repository

distinctive_feature: The represented subject is a rule, standard, procedure, or obligation rather than an entity record.

distinct_from_parent: It narrows the parent to knowledge and rule governance where publication, interpretation, and version retirement are central.

still_same_parent_because: The pattern still designates an authoritative representation and governs downstream copies, updates, and exceptions.

use_when: Policy copies, slide decks, local instructions, or informal summaries diverge from each other.

use_when: Actors need to know which statement governs compliance, operations, or training.

use_when: Outdated policy versions continue to circulate and produce inconsistent action.

domain: compliance

example: The governed policy portal supersedes PDFs attached to old emails.

example: Only the current procedure library is authoritative for factory shutdown steps.

failure_modes: The repository is current but users continue to act from cached documents.

failure_modes: Policy authority is assigned without clarifying who may interpret ambiguous clauses.

Official Record Assignment

distinctive_feature: The authority is tied to official status, record custody, acceptance criteria, and retention obligations.

distinct_from_parent: It specializes the parent for records governance, where custody, filing status, and formal standing matter.

still_same_parent_because: It remains an authority-assignment intervention across conflicting representations of the same subject.

use_when: Legal, administrative, scientific, or historical action depends on record standing.

use_when: Drafts, copies, extracts, minutes, and local files contain inconsistent information.

use_when: The organization needs a repeatable way to decide which record governs a dispute.

example: The filed contract governs over draft versions in shared folders.

example: Approved minutes govern over attendees’ notes when reconstructing a decision.

failure_modes: Official status is confused with factual correctness; a record may need correction even if it is official.

failure_modes: Retention and access rules prevent affected actors from checking the official record.

Branch Authority Assignment

short_definition: Designate a branch, trunk, release, or reviewed merge path as authoritative among many evolving versions.

distinctive_feature: Authority is temporal and versioned; a source can be authoritative now, superseded later, or authoritative only for a release line.

distinct_from_parent: It emphasizes version lineage, merge rules, release states, and branch hierarchy.

still_same_parent_because: It still resolves conflict by assigning governing status and update rights to a defined representation or path.

source_primes: versioning data_integrity hierarchy

use_when: Multiple branches, drafts, releases, or forks diverge and actors need to know which version governs.

use_when: Changes can be proposed in many places but only certain paths make them authoritative.

use_when: Rollback, release, or compatibility decisions depend on current authoritative version state.

example: The reviewed main branch is authoritative for deployable code; experimental branches are not.

example: The published version governs public guidance while drafts remain internal proposals.

failure_modes: Local forks acquire de facto authority because the official branch is difficult to update.

failure_modes: A branch is authoritative for one release line but mistakenly used for another.

Decision Authority Source Assignment

distinctive_feature: The authoritative source may be an accountable role or decision body, not only a data repository.

distinct_from_parent: It applies the parent logic to organizational decision authority, where role legitimacy and escalation matter strongly.

still_same_parent_because: It still turns contested representation or interpretation into a governed authority relation with conflict resolution.

use_when: Several actors or documents can plausibly claim decision authority.

use_when: The cost of conflicting approvals, overrides, or interpretations is high.

use_when: Decision rights need to be linked to records, roles, and escalation paths.

example: The incident commander’s current decision log governs over scattered chat opinions.

example: The roadmap owner’s accepted decision record governs over older prioritization spreadsheets.

failure_modes: Authority is assigned to a role without clear evidence or publication channels.

failure_modes: Decision authority is used to suppress legitimate dissent or correction.

near_names:
Single Source of Truth
System of Record
Authoritative Source Selection
Golden Record
Master Record
Canonical Registry
Official Record
Authoritative Repository
Main Branch
Truth Owner Assignment


Source Provenance Triangulation

type: archetype

source: generated

batch: First Iteration/Batch 45

aliases:
Evidence Triangulation
Source Criticism
Provenance-Based Source Review
Source Reliability Triangulation

alias_records:
Evidence Triangulation
Source Criticism
Provenance-Based Source Review
Source Reliability Triangulation

proposed_primes: evidence traceability provenance

components:
Source Type Classification
Provenance Record
Event Proximity
Perspective Bias Profile
Interpretive Layer Map
Corroboration Check
Confidence Label
Source Gap Register
Reliability Weighting Rule
Dissent Record
Source Update Trigger

mechanisms:
Source Criticism Protocol
Evidence Provenance Log
Triangulation Matrix
Audit Trail Review
Chain of Custody Record
Witness / Source Comparison
Citation Lineage Review
Confidence Annotation Rubric
Conflicting Source Table

essence_one_line: Evaluate an account by tracing source type, origin, proximity, perspective, corroboration, and confidence before treating its claims as settled.

compression_statement: When reconstructing events or conditions from mixed sources, Source Provenance Triangulation prevents evidentiary flattening by classifying source type, recording provenance, assessing proximity and bias, checking independent corroboration, and attaching confidence labels to claims.

core_intuition: Sources do not speak with equal evidentiary force. A claim becomes more usable when reviewers can see where each source came from, what it could know, what it might distort, which other sources support or challenge it, and how much confidence the current source base warrants.

canonical_formula: claim confidence = f(source type, provenance, proximity, perspective, independence, corroboration, unresolved gaps)

structural_problem: An account relies on sources as if they were interchangeable proof, without exposing whether they are firsthand, derivative, interpretive, biased, edited, distant from the event, mutually dependent, or independently corroborated.

condition: mixed evidence base

explanation: The account draws from logs, documents, interviews, memories, reports, datasets, commentary, or artifacts with different evidentiary positions.

condition: conflicting accounts

explanation: Sources disagree, emphasize different facts, or reconstruct the same event from incompatible perspectives.

condition: high reuse risk

explanation: The account will be cited, institutionalized, used for decisions, or preserved as memory, so weak provenance could become durable error.

condition: derivative consensus

explanation: Many sources appear to agree, but they may all depend on the same original source or interpretive layer.

condition: sensitive accountability context

explanation: The account affects responsibility, reputation, safety, legal exposure, public memory, or institutional learning.

symptom: generic citations

meaning: References are listed without explaining what kind of source they are or how they support specific claims.

symptom: overconfident narrative

meaning: A coherent story is treated as settled even though source proximity, independence, or perspective diversity is unclear.

symptom: copied certainty

meaning: Multiple accounts repeat the same claim, but citation lineage shows dependence on one unverified origin.

symptom: single-vantage reconstruction

meaning: The account reflects one role, institution, team, class, or stakeholder perspective while other relevant perspectives are absent.

symptom: missing uncertainty markers

meaning: Strongly and weakly supported claims are written with the same confidence.

root_tension: Useful reconstruction requires synthesis, but synthesis can hide the differences among sources that determine what can responsibly be inferred.

case: purely procedural source collection

reason: If the task is only to gather or store sources without evaluating claim support, this is a source-listing or archive mechanism, not the archetype.

case: already authoritative single record with low consequence

reason: If one verified record is sufficient and the claim is low-stakes, full triangulation may add unnecessary overhead.

case: decision is about choosing an official canonical record

reason: Source-of-truth assignment is the closer archetype when the main problem is authority among systems rather than evidentiary confidence.

case: problem is preserving data through transformations

reason: Data integrity preservation is the closer archetype when the main challenge is preventing corruption rather than interpreting sources.

structural_intervention: Turn evidence use into a disciplined claim-support map: classify each source, document provenance, assess proximity and perspective, test corroboration and independence, preserve contradictions, and attach a reasoned confidence label to each claim.

logic: State the claim or account that needs source support before collecting evidence indiscriminately.

logic: Classify each source by type, role, mediation, and relationship to the event or condition under review.

logic: Record source provenance, including origin, authorship or producer, custody path, transformations, access conditions, and unresolved gaps.

logic: Assess event proximity across time, place, role, access, and mediation instead of relying on broad primary/secondary labels alone.

logic: Profile perspective and bias by asking what the source could know, why it might distort, and which standpoints are missing.

logic: Compare sources for independent corroboration, contradiction, silence, and shared dependence.

logic: Attach confidence labels and uncertainty reasons to claims, then update those labels when provenance or corroboration changes.

rule: Do not infer confidence from source count alone.

rationale: Ten derivative sources can be weaker than two independent sources with clear provenance.

rule: Treat primary-source status as a starting classification, not proof of reliability.

rationale: Firsthand sources can be mistaken, selective, constrained, self-protective, or edited.

rule: Require independence before treating agreement as corroboration.

rationale: Shared citation lineage, shared institutional incentives, or common data origins can create apparent agreement without independent support.

rule: Separate explanation of source position from endorsement of the source claim.

rationale: Understanding a source's standpoint should improve interpretation without laundering false or harmful claims.

rule: Carry uncertainty forward with the claim.

rationale: Users of the account need to know which claims are settled, provisional, contested, or weakly sourced.

invariant: claim-source linkage

why_it_matters: Every material claim should remain connected to the sources and source properties that support or challenge it.

invariant: source-type distinction

why_it_matters: Firsthand, derivative, interpretive, and summary sources should not collapse into an undifferentiated citation pool.

invariant: provenance visibility

why_it_matters: Origin, custody, transformation, and access gaps must remain visible because they condition what the source can support.

invariant: corroboration independence

why_it_matters: Agreement only increases confidence when sources are not merely copying or sharing the same hidden origin.

invariant: confidence humility

why_it_matters: Confidence labels should reflect source limits, contradictions, missing perspectives, and unresolved uncertainty.

outcome: more reliable reconstruction

description: Accounts become better grounded in the properties and relationships of their supporting sources.

outcome: visible uncertainty

description: Readers can distinguish strong claims from provisional, contested, derivative, or poorly sourced claims.

outcome: reduced evidentiary laundering

description: Derivative citations, inherited assumptions, and copied certainty become easier to detect.

outcome: better revision path

description: Future evidence can update specific claims because the account records source dependencies and confidence reasons.

outcome: fairer interpretation

description: Perspective gaps and positional bias become visible, reducing overreliance on the easiest or most powerful source set.

prose_essence:
Source Provenance Triangulation is the discipline of asking what each source is, where it came from, how close it is to the matter being reconstructed, what perspective it carries, whether it is independent of other sources, and how much confidence its evidence can support. It is useful whenever an account could become persuasive simply because it is coherent, frequently repeated, or backed by citations that have not been examined.

The archetype is not just “collect more sources.” It is a way to keep claims attached to their evidentiary grounds. A claim supported by a firsthand log, a later memoir, an official statement, an interview, and a scholarly synthesis should not be treated as five identical pieces of support. Each source occupies a different evidentiary position and must be interpreted accordingly.

prose_when_to_use:
Use this archetype when a decision, story, investigation, retrospective, or explanation depends on evidence from multiple kinds of sources. It is especially important when sources conflict, when an account will become institutional memory, when a finding affects accountability, or when a polished secondary account may be standing on weak primary evidence.

It is also appropriate when source type alone is too crude. A primary source can be biased, partial, edited, translated, or far from the relevant event. A secondary source can be derivative, circular, or carefully triangulated. The archetype helps reviewers avoid both naive trust and indiscriminate skepticism.

prose_structural_problem:
The structural problem is evidentiary flattening. Sources are placed behind claims as if they all carry the same kind of support. A citation, log, interview, official record, memory, artifact, dataset, or later analysis may all appear in the same reference pool, but each has different access, incentives, proximity, and transformation history.

When those differences are hidden, weak claims can harden into consensus. A claim repeated by many sources may still have one origin. A vivid witness account may dominate a dry but more direct record. An official report may have strong provenance but narrow perspective. A later synthesis may be clear while distancing the reader from the original evidence.

prose_intervention_logic:
The intervention begins by naming the claim or account that needs support. Reviewers then classify the sources, record provenance, assess proximity, profile perspective and bias, map interpretive layers, compare independent corroboration, and attach confidence labels. The result is not merely a pile of evidence; it is a claim-support structure that preserves why each claim is strong, weak, contested, or provisional.

The core logic is comparative. A source is not evaluated in isolation. Its evidentiary meaning changes when it is compared against other sources with different origins, positions, and vulnerabilities to error. Agreement matters most when sources are independent; disagreement matters when it reveals perspective, timing, omitted context, or genuine uncertainty.

prose_key_components:
### Source Type Classification

Source type classification distinguishes firsthand, contemporaneous, derivative, interpretive, summary, testimonial, material, and analytical sources. The goal is not to rank sources automatically, but to identify what kind of evidentiary work each source can perform. A sensor log, a diary, an interview, a newspaper article, and a later synthesis should not be asked to support the same claim in the same way.

### Provenance Record

The provenance record captures origin, authorship or production context, custody path, transformations, access conditions, and unresolved gaps. It answers questions such as: Who produced this? When? For what audience? How was it preserved or transmitted? What edits, translations, selections, or losses occurred before review?

### Event Proximity

Event proximity assesses closeness to the event or condition under review. Proximity is not only about time. It includes spatial location, role, access, mediation, technical instrumentation, and whether the source observed the relevant part of the event. A source can be temporally close but conceptually narrow, or temporally distant but valuable for explaining motives and context.

### Perspective Bias Profile

The perspective bias profile documents position, incentives, constraints, audience, conflicts of interest, and blind spots. Bias does not mean a source is useless. It means the source is located. The question is what the source could see, what it had reason to emphasize or hide, and what other perspectives are needed to interpret it responsibly.

### Interpretive Layer Map

The interpretive layer map separates observation from transcription, translation, selection, commentary, synthesis, and later reuse. This is crucial because derivative sources often present interpretation as if it were evidence. Mapping layers helps reviewers identify where meaning changed and whether a claim rests on original evidence or inherited framing.

### Corroboration Check

The corroboration check compares sources for independent agreement, disagreement, silence, contradiction, and shared dependence. Corroboration is strongest when sources are independent and differently vulnerable to error. Multiple sources copied from the same origin may create a false sense of confidence.

### Confidence Label

The confidence label carries the resulting judgment with the claim. It should explain whether confidence is high, moderate, low, contested, or provisional, and why. A useful label mentions source type, provenance, proximity, perspective, independence, corroboration, and missing evidence rather than presenting confidence as a naked score.

prose_common_mechanisms:
### Source Criticism Protocol

A source criticism protocol implements the archetype through structured questions about authorship, purpose, audience, context, proximity, and transmission. It is a mechanism, not the archetype itself: the protocol is useful only if it changes how claims are weighted and qualified.

### Evidence Provenance Log

An evidence provenance log records origins, custody, transformations, access dates, and gaps. It operationalizes the provenance record component and makes future revision possible. The log is not enough on its own; it must feed into corroboration and confidence judgments.

### Triangulation Matrix

A triangulation matrix places claims against sources so agreement, disagreement, independence, and source-type diversity can be seen at once. This mechanism helps prevent a coherent story from hiding unsupported or singly sourced claims.

### Audit Trail Review

Audit trail review inspects logs, version histories, document histories, or system traces for gaps and transformations. It is especially useful in incident review, data governance, and institutional accountability contexts where records may have changed after the fact.

### Chain of Custody Record

A chain of custody record documents who handled evidence, when, under what conditions, and with what transformations. It implements a custody-focused variant of the archetype. It should not be confused with proof of truth; it mainly supports proof of handling and integrity path.

### Witness / Source Comparison

Witness or source comparison evaluates firsthand accounts by role, timing, memory risk, access, incentive, and corroboration against non-testimonial sources. It helps avoid over-weighting the most vivid or authoritative account.

### Citation Lineage Review

Citation lineage review traces claims through references and derivative accounts. It detects circular citation, inherited assumptions, and apparent consensus that actually comes from a single weak origin.

### Confidence Annotation Rubric

A confidence annotation rubric attaches reasoned confidence levels to claims. It implements the archetype by making claim strength explicit and revisable rather than hidden in prose.

### Conflicting Source Table

A conflicting source table keeps contradictions visible. Instead of forcing premature resolution, it records each source’s claim, position, possible explanation, and unresolved question.

prose_failure_modes:
A common failure mode is citation laundering, where derivative sources cite each other until a weak claim looks well established. Citation lineage review and independence checks mitigate this.

Another failure mode is primary-source fetishism. Reviewers may assume firsthand sources are automatically superior, even when they are biased, partial, edited, or narrow. Proximity and perspective analysis prevent this oversimplification.

A third failure mode is false equivalence. The archetype asks for multiple perspectives, but it does not require treating all claims as equally supported. Confidence should remain unequal where the evidence is unequal.

A fourth failure mode is provenance theater. Teams may fill out metadata fields without letting provenance change claims, confidence, or unresolved-gap notes. The mitigation is to require every relevant provenance finding to affect interpretation.

A fifth failure mode is single-score flattening. A reliability score can be useful, but it should not replace reasons. The reasons are the transferable knowledge.

A sixth failure mode is over-triangulation. Not every claim needs exhaustive review. The level of triangulation should scale with stakes, uncertainty, and reuse risk.

prose_neighbor_distinctions:
Source Provenance Triangulation is distinct from Traceability Linking. Traceability Linking connects items, records, decisions, and consequences. This archetype uses traceability but adds source-type judgment, perspective analysis, corroboration, and confidence.

It is distinct from Data Integrity Preservation. Data integrity asks whether records remain accurate and consistent through their lifecycle. Source Provenance Triangulation asks what claims those records can support.

It is distinct from Source-of-Truth Assignment. Source-of-truth assignment chooses an authoritative representation for operational consistency. Source Provenance Triangulation may conclude that no source is fully authoritative and that confidence must vary by claim.

It is distinct from Epistemic Inclusion Design. Epistemic inclusion addresses who gets to contribute to knowledge-making. This archetype addresses how sources, including included voices, support claims.

It is distinct from Narrative Construction Audit. Narrative audit examines event selection, causal sequencing, focal actors, and omissions. Source Provenance Triangulation examines whether the sources behind that narrative warrant the claims being made.

prose_cross_domain_examples:
In historical analysis, the archetype helps reconstruct events from diaries, official records, photographs, newspapers, later memoirs, and scholarship without treating them as interchangeable evidence.

In incident review, it compares telemetry, logs, chat records, customer reports, and interviews so the final postmortem does not simply adopt the most vivid or senior narrative.

In journalism, it checks official statements against documents, affected parties, independent experts, and contemporaneous records before publishing a claim.

In research synthesis, it prevents several papers or reports that cite the same original source from being mistaken for independent confirmation.

In institutional memory, it preserves lessons learned with evidence links, confidence labels, dissent records, and update triggers so future teams know what the organization actually learned and what remains uncertain.

prose_non_examples:
A bibliography is not Source Provenance Triangulation. It may list sources, but it does not necessarily evaluate source type, provenance, proximity, perspective, corroboration, or confidence.

An archive is not the archetype. It stores or preserves materials. The archetype begins when those materials are evaluated as evidence for claims.

A footnote is not the archetype. It points to a source, but it can hide weak support unless citation lineage and source relevance are checked.

A single source-of-truth database is not the archetype. It may be operationally authoritative, but triangulation is needed only when claims require evidentiary comparison.

A polished historical essay is not automatically the archetype. It may contain good scholarship, but the archetypal intervention is visible only when source provenance and claim confidence are made inspectable.

prose_tradeoffs:
The archetype trades speed for rigor. It can slow down reporting, research, postmortems, and institutional learning, but it reduces the risk of preserving errors as settled accounts.

It also trades narrative smoothness for evidentiary clarity. A fully qualified account may be less elegant than a simple story, but it is more honest about what is known and unknown.

It trades inclusion for weighting discipline. More sources can improve coverage, but the archetype still requires unequal weighting when sources differ in proximity, independence, provenance, and corroboration.

Finally, it trades immediate closure for future revisability. The recordkeeping burden is justified when the account will be reused, contested, audited, or used to assign responsibility.

prose_invariants_to_preserve:
The first invariant is claim-source linkage: material claims should remain tied to the sources that support or challenge them. When this link is broken, accounts become difficult to revise.

The second invariant is source-type distinction. Firsthand, derivative, interpretive, and summary materials must not collapse into one citation pool.

The third invariant is provenance visibility. Origin, transmission, transformation, and access gaps should remain visible because they shape what a source can responsibly support.

The fourth invariant is corroboration independence. Agreement should only increase confidence when sources are not merely copying the same origin or sharing the same hidden dependency.

The fifth invariant is confidence humility. A claim should not sound more settled than its source base warrants.

prose_target_outcomes:
The intended outcome is a more reliable account. The archetype does this by making evidentiary support inspectable rather than rhetorical.

A second outcome is visible uncertainty. Readers can tell which claims are strongly supported, which are provisional, which are contested, and which depend on a narrow source base.

A third outcome is reduced evidentiary laundering. Repetition, citation density, official tone, and polished synthesis no longer automatically create confidence.

A fourth outcome is better revision. Because claims carry source links and confidence reasons, future evidence can update the account without starting over.

A fifth outcome is fairer interpretation. Perspective gaps and positional bias become explicit, reducing overreliance on the easiest, loudest, most formal, or most powerful source set.

prose_parameter_dimensions:
The first tuning dimension is evidentiary stakes. A public accountability finding, legal investigation, safety review, or canonical historical account needs stronger provenance and corroboration than a low-stakes internal note.

The second dimension is source diversity. When sources share one institutional origin, one role, one data pipeline, or one citation lineage, reviewers need stronger perspective and independence checks. When sources are diverse but uneven in quality, reviewers need explicit weighting rules.

The third dimension is proximity threshold. Some domains require contemporaneous records; others can use retrospective testimony if memory risk and interpretive layer are acknowledged. The threshold should match the type of claim being made.

The fourth dimension is confidence vocabulary. A lightweight setting may use high, medium, low, and unknown. A formal investigation may need claim-level labels such as well-corroborated, single-source, contested, derivative, inferred, or unsupported.

The fifth dimension is disclosure granularity. Provenance should be transparent enough for review, but source identities, whistleblower details, victim information, or sensitive records may need redaction or access control.

prose_variants_and_near_names:
Primary Source Proximity Check is a variant focused on ranking and qualifying firsthand sources by closeness, access, mediation, and context. It prevents the primary-source label from doing too much work.

Secondary Interpretation Layer Review focuses on later synthesis, translation, commentary, citation, and interpretive transformation. It is useful when derivative consensus may be hiding a weak or circular origin.

Perspective Triangulation focuses on differently positioned observers and records. It compares what each standpoint could know, what it might distort, and which voices are missing.

Chain of Custody Validation focuses on evidence handling and transformation. It is especially important when records, artifacts, logs, or documents may have been altered, contaminated, selectively transmitted, or edited.

Near names include source criticism, evidence triangulation, provenance tracking, source reliability assessment, citation review, witness comparison, and audit-trail review. These should usually be treated as methods or variants under the parent rather than separate archetypes.

Primary Source Proximity Check

variant_type: subtype

short_definition: Focuses the archetype on how close a firsthand source is to the event, decision, or condition being reconstructed.

distinctive_feature: The main distinction is proximity inside the primary-source category rather than a simple primary/secondary binary.

distinct_from_parent: The parent triangulates across all source types; this variant emphasizes ranking and qualifying firsthand material by temporal, spatial, role, and mediation distance.

still_same_parent_because: It still uses provenance, proximity, perspective, corroboration, and confidence marking to discipline an evidentiary account.

use_when: firsthand testimony, logs, records, or artifacts are available but vary in closeness to the event

use_when: participants disagree about what happened or what they directly observed

use_when: a source is labeled primary but may still be distant, edited, translated, selective, or retrospective

Event Proximity

role: Measures the source's closeness to the event or condition under reconstruction.

Interpretive Layer Map

role: Separates direct observation from later retelling, editing, translation, or interpretation.

Witness / Source Comparison

role: Compares firsthand accounts by access, timing, role, and incentives.

Chain of Custody Record

role: Tracks how the source moved or changed before review.

domain: Incident review

example: Separating a contemporaneous outage log from a memory-based interview recorded three weeks later.

domain: History

example: Distinguishing a diary entry written during an event from a memoir written decades later.

failure_modes: assuming all primary sources are equally reliable

failure_modes: treating closeness to the event as immunity from bias or incompleteness

Secondary Interpretation Layer Review

short_definition: Examines how later analysis, synthesis, citation, translation, or commentary changes what a source is taken to mean.

distinctive_feature: The distinctive issue is interpretive layering: who transformed the source, how, and under what assumptions.

distinct_from_parent: The parent evaluates source provenance broadly; this variant specializes in the transformations introduced by later interpretation and citation chains.

still_same_parent_because: It remains an evidentiary triangulation pattern because it still links claims to source type, provenance, perspective, corroboration, and confidence.

use_when: a widely accepted account rests on later summaries or interpretations rather than direct materials

use_when: multiple secondary accounts cite each other and may reproduce the same assumption

use_when: the interpretive frame of a later author may have shaped the source evidence being presented

Interpretive Layer Map

role: Names each interpretive transformation between original source and current claim.

Citation Lineage

role: Tracks how a claim moved through citations, summaries, and derivative accounts.

Citation Lineage Review

role: Checks whether secondary sources rely on independent evidence or circular citation.

Source Criticism Protocol

role: Applies structured questions about authorship, purpose, audience, and context.

example_domains: research journalism history policy_review

domain: Research synthesis

example: Tracing whether several review articles are independently grounded or all cite the same weak original study.

domain: Policy review

example: Checking whether a policy memo paraphrases evidence selectively from a broader technical report.

failure_modes: treating polished synthesis as stronger than original evidence because it is more coherent

failure_modes: missing circular citation or inherited interpretation

Perspective Triangulation

short_definition: Compares sources from differently positioned observers so blind spots, incentives, and excluded standpoints become visible.

distinctive_feature: The distinctive issue is perspective diversity and positional bias, not only chronological proximity or document provenance.

distinct_from_parent: The parent can triangulate any source properties; this variant specifically forces comparison across vantage points and interests.

still_same_parent_because: It still uses source classification, provenance, bias profile, corroboration, and confidence labeling to evaluate claims.

use_when: available sources cluster around one role, institution, class, team, or stakeholder group

use_when: credible sources disagree because they saw different parts of the event or had different incentives

use_when: the account may reproduce the standpoint of the most powerful or easiest-to-document source group

Perspective Bias Profile

role: Documents position, incentives, access, blind spots, and missing voices.

Source Gap Register

role: Names perspectives not represented in the evidence base.

Triangulation Matrix

role: Displays agreement and disagreement across sources and perspectives.

Conflicting Source Table

role: Keeps contradictory evidence visible instead of resolving it prematurely.

domain: Organizational retrospective

example: Comparing leadership, frontline, customer-support, and system-log views of a failed launch.

domain: Journalism

example: Checking an official account against affected residents, technical records, and independent observers.

failure_modes: mistaking numerical source diversity for genuine perspective diversity

failure_modes: using standpoint comparison to force false equivalence among unequally supported claims

Chain of Custody Validation

short_definition: Tracks custody, transformation, access, and handling of evidence so later claims can be tied to an accountable source path.

distinctive_feature: The distinctive issue is the integrity of the evidence path, not only the credibility of the original source.

distinct_from_parent: The parent evaluates evidence quality broadly; this variant emphasizes custody and transformation controls across a source life cycle.

still_same_parent_because: Custody validation is one way to establish provenance before triangulating claims across source types.

use_when: evidence may have been altered, selectively transmitted, contaminated, edited, or summarized

use_when: reviewers need to know who handled a record, artifact, dataset, or testimony before use

use_when: source validity depends on preserving a reliable path from origin to current review

Provenance Record

role: Captures origin, handlers, transformations, and unresolved custody gaps.

Source Update Trigger

role: Reopens confidence when the custody path changes or a hidden transformation is discovered.

Chain of Custody Record

role: Documents transfers, handling, and transformations.

Audit Trail Review

role: Checks record history for gaps, edits, and authorization anomalies.

domain: Security incident review

example: Confirming that log extracts were complete, time-synchronized, and unedited before using them as evidence.

domain: Archival work

example: Recording how a document was acquired, cataloged, restored, translated, and digitized.

failure_modes: treating custody paperwork as proof of truth rather than proof of handling

failure_modes: overweighting records with clean custody while ignoring corroborating but less formal sources

near_names:
Source Criticism
Evidence Triangulation
Provenance Tracking
Source Reliability Assessment
Citation Review
Witness Comparison
Audit Trail Review


Source–Sink Viability Management

batch: Batch 14

aliases:
source-sink governance
source-sink support design
source-sink network governance
source-sink metapopulation management
surplus-subsidy viability management
sink dependency governance
source protection and sink support

source_primes: source_sink_habitat flow reservoir_flux_network buffering turnover feedback resource_management resilience observability boundary coupling balance

slug: flow

slug: buffering

slug: turnover

slug: feedback

slug: resilience

slug: observability

slug: coupling

slug: balance

slug: metastability

slug: homeostasis

slug: equilibrium

slug: network

slug: threshold

slug: externality

slug: dependency

slug: boundedness

slug: queueing

slug: backpressure

components:
Unit of Persistence
Source–Sink Role Map
Net Balance Measurement
Exportable Surplus Budget
Source Viability Guardrail
Sink Dependency Profile
Sink Viability Threshold
Support Flow Map
Connectivity Pathway Map
Support Rationale and Horizon
Sink Recovery or Conversion Pathway
Role-Switch Monitor
Withdrawal Impact Guardrail
Feedback Review Cadence
Multi-Source Diversification Plan
Fairness and Equity Review
Scenario Stress Test
Adaptive Support Rule

mechanisms:
Source–Sink Patch Map
Metapopulation Model
Cross-Subsidy Budget
Source Depletion Dashboard
Sink Dependency Dashboard
Support Flow Agreement
Restoration Priority Matrix
Connectivity or Corridor Plan
Minimum Support Schedule
Support Taper Plan
Rescue-Effect Audit
Role Reclassification Review
Dispersal or Transfer Tracer

essence_one_line: Manage asymmetric support networks by protecting sources, diagnosing sink dependency, and deciding when to sustain, restore, transform, or exit sinks.

compression_statement: A source-sink system persists because some sites, units, markets, habitats, teams, or reservoirs produce surplus while others consume more than they produce and would decline alone. The intervention is to map net balance roles, measure source surplus and sink dependency, protect source viability, set support rules, maintain or redesign connectivity, and choose whether each sink should be sustained, restored, converted, or exited. The archetype prevents aggregate persistence from hiding local nonviability, source depletion, or permanent dependency.

core_intuition: A sink can look alive because a source is quietly keeping it alive. That can be wise stewardship, strategic investment, public service, ecological rescue, or dangerous denial. The design question is not merely whether support exists; it is whether the source can afford it, whether the sink should remain dependent, and what evidence would justify continuing, repairing, reducing, or ending the support flow.

canonical_formula: net_balance(site) = local_production_or_recruitment - local_consumption_or_loss; source if net_balance > export_threshold, sink if net_balance < viability_requirement and persistence depends on imported surplus.

structural_problem: A coupled system is treated as if every site or unit is locally viable, while some sinks persist only because surplus from sources compensates for their deficit, masking source depletion, sink fragility, or maladaptive dependency.

trigger_conditions: Some sites, teams, habitats, accounts, markets, services, or units generate surplus while others consume, lose, or require more than they produce.

trigger_conditions: Deficit units would decline, fail, collapse, exit, or become unacceptable without incoming support.

trigger_conditions: Aggregate system performance hides the fact that persistence is unevenly produced and unevenly consumed.

trigger_conditions: Support flows can be protected, increased, redirected, tapered, conditioned, or withdrawn by design choices.

trigger_conditions: Connectivity matters: a sink can persist only if the surplus path from a source remains open, reliable, and not too delayed.

trigger_conditions: Sources can be depleted, exploited, or weakened by repeated exports.

trigger_conditions: Sinks may deserve support for equity, coverage, mission, option value, ecological function, or strategic future potential, but not all dependency should be permanent.

symptoms: A site appears stable until imports, subsidies, staff transfers, larvae, cash, attention, or central support are removed.

symptoms: Aggregate health hides that some units are net drains and others are net producers.

symptoms: Sources experience fatigue, depletion, crowding, underinvestment, or loss of resilience because they are continually exporting surplus.

symptoms: Sinks do not improve because incoming support maintains persistence without addressing local constraints.

symptoms: Support decisions are justified by habit rather than explicit viability thresholds or time horizons.

symptoms: Connectivity failures cause sudden collapse in formerly stable sinks.

symptoms: Role labels are stale: an old source has become a sink, or a repaired sink has become a source, but policy has not updated.

symptoms: Withdrawal of support produces worse harm than expected because dependency duration was not tracked.

root_tension: The system may need unequal flows to preserve total viability, equity, or strategic coverage, but unequal flows can also hide extraction from sources and permanent nonviability in sinks. The intervention must preserve beneficial support while making dependency, depletion, and exit choices explicit.

anti_signatures: All units are locally self-sustaining and transfers are incidental; use ordinary network mapping or reservoir-flux balancing.

anti_signatures: The main problem is temporary mismatch between production and consumption; use Buffering.

anti_signatures: The main problem is route selection under capacity or cost constraints; use Network Flow Optimization.

anti_signatures: The main problem is reciprocal interdependence where both sides can destabilize each other symmetrically; use Mutual Dependency Stabilization.

anti_signatures: The main task is simply revealing dependencies without deciding how to govern support; use Dependency Exposure.

anti_signatures: The issue is externalized burden moved to a sink with cleanup accountability; use Entropy Export or Externality Internalization.

anti_signatures: The central question is general resource allocation across recipients rather than persistent source/sink role asymmetry; use Constrained Resource Allocation or Satiation-Aware Allocation.

structural_intervention: Install a source-sink governance layer: classify net-balance roles, quantify exportable surplus and required imports, protect source viability, diagnose sink dependency, maintain or redesign connectivity, and set explicit rules for sustaining, restoring, converting, tapering, or exiting support.

action_logic: Define the unit of persistence: species, service, market, facility, account, team, infrastructure node, or other site whose local viability matters.

action_logic: Measure local production, recruitment, replenishment, revenue, capacity, or benefit generation at each site.

action_logic: Measure local consumption, mortality, demand, loss, cost, drawdown, or maintenance burden at each site.

action_logic: Classify sites by net balance and confidence: source, sink, neutral, role-switching, unknown, or measurement-contested.

action_logic: Map support flows from sources to sinks, including volume, timing, reliability, cost, quality, and pathway vulnerability.

action_logic: Set source viability guardrails so surplus export does not deplete the source below renewal or resilience thresholds.

action_logic: Set sink viability thresholds and dependency profiles so persistence due to rescue is not mistaken for self-sustainability.

action_logic: Decide why each sink is supported: equity, coverage, ecological function, option value, strategic growth, safety, reciprocity, transition, or legacy obligation.

action_logic: Choose an intervention for each sink: sustain, restore local viability, reduce demand, change connectivity, convert role, merge, taper, or exit safely.

action_logic: Monitor role switching and reclassify sources and sinks as conditions change.

action_logic: Review whether support flows are improving long-term viability or only hiding deficits and source depletion.

decision_rules: If a sink persists only with imports, require an explicit support rationale, support horizon, and review cadence.

decision_rules: If a source falls toward its viability guardrail, reduce exports, increase replenishment, diversify sources, or reduce sink demand before source collapse.

decision_rules: If a sink has high strategic or ethical value but low local viability, pair support with restoration or adaptation rather than indefinite opaque subsidy.

decision_rules: If support creates dependency without improvement, decide whether to redesign the sink, convert its role, or plan an exit.

decision_rules: If connectivity becomes unreliable, treat sinks as at-risk even if recent aggregate performance looked stable.

decision_rules: If source/sink classification is uncertain, classify confidence separately from role and avoid irreversible support withdrawal.

decision_rules: If a former sink becomes net-positive, update support rules so it can stop consuming surplus or become a source itself.

decision_rules: If a support flow imposes unrecognized external costs, internalize those costs before calling the arrangement viable.

target_invariants: Source surplus is measured after preserving source renewal, resilience, and local obligations.

target_invariants: Sink persistence is not equated with sink self-sufficiency unless imports can be removed without collapse.

target_invariants: Support flows remain visible, accountable, and tied to rationale and horizon.

target_invariants: Connectivity assumptions are monitored because support fails when pathways fail.

target_invariants: Aggregate system success does not hide local depletion, dependency, inequity, or abandonment risk.

target_invariants: Sinks are supported, restored, converted, or exited by explicit criteria rather than inertia.

target_invariants: Role labels can change when net balance changes.

expected_outcomes: Clearer distinction between true local viability and persistence by rescue or subsidy.

expected_outcomes: Reduced source depletion caused by unbounded support obligations.

expected_outcomes: Better prioritization of which sinks to sustain, restore, transform, or exit.

expected_outcomes: More resilient support networks because connectivity and source guardrails are monitored.

expected_outcomes: Less accidental abandonment when support is withdrawn from dependent sinks.

expected_outcomes: More honest governance of cross-subsidy, ecological rescue, coverage obligations, and strategic support.

expected_outcomes: Earlier detection of role switching when sources become sinks or sinks become sources.

prose_essence:
Source–Sink Viability Management handles systems where some sites or units produce surplus and others persist only by receiving that surplus. The archetype asks whether support is wise, fair, sustainable, restorative, temporary, permanent, or disguising failure.

The target prime is not merely “a source and a sink.” It is asymmetric net balance across coupled sites. A source exports more than it needs to persist. A sink consumes or loses more than it produces and would decline in isolation. The design problem is to govern the relation rather than letting aggregate survival hide local nonviability.

prose_key_components:
### Unit of Persistence

Before classifying source or sink status, define what must persist: a population, habitat, service site, market, team, account, or infrastructure node. Without a clear unit, the classification becomes rhetorical.

### Source–Sink Role Map

The role map classifies each unit as source, sink, neutral, role-switching, unknown, or contested. It should include confidence and time horizon, because source/sink roles can change after shocks, restoration, seasonality, or growth.

### Net Balance Measurement

Net balance compares local production or replenishment against local consumption or loss. A source has exportable surplus only after its own renewal and obligations are protected. A sink requires imports to remain above its viability threshold.

### Source Viability Guardrail

A source should not be drained simply because it currently produces surplus. Guardrails protect renewal, resilience, local obligations, and future source capacity. They prevent stewardship from becoming extraction.

### Sink Dependency Profile

A sink dependency profile identifies the amount, reliability, duration, pathway, and interruption risk of required support. It distinguishes rescue from recovery and permanent chosen support from accidental lock-in.

### Support Rationale and Horizon

Support should have a reason and a review date. The reason might be equity, coverage, ecological function, option value, mission, strategic growth, transition, safety, or legal obligation. The horizon can be permanent, conditional, staged, or time-limited, but it should be explicit.

prose_common_mechanisms:
Useful mechanisms include source-sink patch maps, metapopulation models, cross-subsidy budgets, source depletion dashboards, sink dependency dashboards, support flow agreements, restoration priority matrices, connectivity corridor plans, minimum support schedules, support taper plans, rescue-effect audits, role reclassification reviews, and transfer tracers.

Mechanisms should fit the decision. Use metapopulation models when dispersal and recruitment matter. Use cross-subsidy budgets when financial support is institutional. Use rescue-effect audits when persistence might be confused with recovery. Use support taper plans when exit is possible but abrupt withdrawal would be harmful.

prose_failure_modes: The major failure modes are rescue mistaken for recovery, source depletion by invisible obligation, aggregate persistence illusion, connectivity neglect, stale role classification, maladaptive subsidy lock-in, abandonment shock, and sink stigmatization. The practical test is whether the system can say what each sink needs, why it is supported, what protects the source, and what would justify changing the support relation.

prose_neighbor_distinctions: Conserved Reservoir-Flux Balancing is the parent stock-flow neighbor, but it does not by itself answer source viability, sink dependency, support rationale, or exit decisions. Buffering smooths temporary mismatch. Mutual Dependency Stabilization is reciprocal. Dependency Exposure reveals hidden reliance. Commons Governance governs shared-resource use. Public Goods Provision funds shared benefits. Network Flow Optimization routes flow. Source–Sink Viability Management is the asymmetric-persistence pattern: sources export surplus, sinks persist through imports, and the system must govern the consequences.

prose_non_examples: A one-time transfer is not necessarily source-sink management. A dependency map without support decisions is Dependency Exposure. A buffer stock that smooths short-term mismatch is Buffering. A route optimization problem is Network Flow Optimization. A project ranking model is allocation unless persistent source/sink viability is the central structure.

prose_invariants_to_preserve: The main invariants are source viability, explicit sink dependency, visible support flows, monitored connectivity, fair support rationale, and safe transition rules. Aggregate viability should never be allowed to hide local depletion or collapse risk.

prose_target_outcomes: A good implementation makes source depletion visible before it becomes collapse. It prevents rescued sinks from being mistaken for self-sustaining units. It clarifies when support is justified and when restoration, conversion, taper, or exit is needed. It also helps preserve ethical support where permanent dependency is legitimate and openly chosen.

name: Ecological Source–Sink Habitat Management

short_definition: Manage habitat patches so surplus-producing sources can sustain sinks without masking sink degradation or exhausting the source.

distinctive_feature: Uses ecological patch viability, dispersal, recruitment, and carrying-capacity logic.

distinct_from_parent: Domain-specific ecological form of the general source-sink viability pattern.

still_same_parent_because: The governing structure remains asymmetric net production and consumption across coupled sites.

use_when: Population persistence depends on dispersal from productive patches to deficit patches.

use_when: A sink would decline in isolation but receives enough immigrants, larvae, seeds, workers, or resources to persist.

use_when: Managers can protect sources, restore sinks, alter connectivity, or change pressure on either side.

domain: marine conservation

example: A protected reef exports larvae that sustain fished or degraded reefs.

domain: wildlife corridors

example: Breeding habitat patches supply dispersers to marginal patches.

Cross-Subsidy Viability Design

short_definition: Use surplus from viable units to sustain deficit units while making dependency, fairness, and source depletion explicit.

distinctive_feature: Makes support flows, rationale, time horizon, and fairness constraints explicit.

distinct_from_parent: A policy and governance subtype focused on subsidy and support rather than ecological dispersal.

still_same_parent_because: It still depends on asymmetric net balance between sources and sinks.

use_when: Profitable, high-capacity, or high-yield units support low-yield units that would not persist alone.

use_when: The sink is maintained for equity, coverage, strategy, resilience, mission, or option value.

use_when: The design must prevent permanent hidden dependency and source exhaustion.

domain: public services

example: Urban clinics subsidize rural outreach sites maintained for access.

domain: platforms

example: Revenue from dense markets supports thin markets until they reach liquidity.

Rescue-Effect Stabilization

short_definition: Maintain enough incoming support to keep a sink from collapse while avoiding false belief that the sink has become self-sustaining.

distinctive_feature: The key risk is confusing rescued persistence with local viability.

distinct_from_parent: Narrower case where rescue prevents collapse but dependency remains unresolved.

still_same_parent_because: Rescue is one kind of source-to-sink support flow.

use_when: A sink persists because repeated imports prevent local collapse.

use_when: The support flow is intermittent, delayed, or shock-sensitive.

use_when: Managers must distinguish true recovery from continuous rescue.

failure_modes: Mistaking persistent rescue for independence.

failure_modes: Withdrawing support before the sink has crossed a viability threshold.

Sink Conversion or Exit Management

short_definition: Decide when to restore a sink toward self-sustaining status, convert its role, or exit support without destructive abandonment.

distinctive_feature: Focuses on transition decisions for persistent sinks: restore, reduce demand, repurpose, merge, or exit.

distinct_from_parent: The parent includes ordinary maintenance of source-sink networks; this variant handles unresolved sink dependency.

still_same_parent_because: The decision is triggered by source-sink net balance and viability thresholds.

use_when: A sink remains dependent beyond an acceptable support horizon.

use_when: Source surplus is no longer sufficient to sustain all sinks safely.

use_when: The system needs a humane, ecological, or strategic transition rather than indefinite subsidy.

Role-Switching Source–Sink Adaptation

short_definition: Monitor and adapt when sources become sinks or sinks become sources under seasonality, shocks, growth, depletion, or regime change.

distinctive_feature: Treats source/sink status as a monitored dynamic role rather than fixed classification.

distinct_from_parent: Narrower temporal case where role change is expected and central.

still_same_parent_because: It still uses source-sink net balance as the organizing relation.

source_primes: source_sink_habitat feedback turnover threshold

use_when: Net production and consumption roles change over time or across regimes.

use_when: A formerly reliable source can become a dependent sink after shock or overuse.

use_when: Support policy must adapt without locking old roles into the map.

near_names:
Source–Sink Governance
Source–Sink Support Design
Source–Sink Network Governance
Source–Sink Metapopulation Management
Surplus-Subsidy Viability
Sink Rescue Management