Source Of Truth Assignment¶

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.

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.

Canonical formula: competing_representations + authority_boundary + authoritative_source + update_and_conflict_rules → reliable_governing_state

When to Use This Archetype¶

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.

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.

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

Key Components¶

Source-of-Truth Assignment converts a tangle of competing representations into a governed authority relation, so the system can decide which record controls action when several plausible versions disagree. The pattern starts by naming the Represented Subject — the customer, asset, policy, codebase, or operational state — clearly enough that competing claims can be recognized as claims about the same thing. A Competing Representation Inventory lists the systems, repositories, documents, or actors that currently claim or imply authority over that subject, because any assignment that misses representations leaves hidden conflicts intact. The Authoritative Source is then designated as the representation whose value governs, with its reach defined by an Authority Boundary that may make the source authoritative for identity but not payment, or current policy but not historical interpretation. A Precedence Rule makes conflict resolution repeatable by stating how disagreements among authoritative, secondary, cached, and derived representations are settled.

The remaining components turn authority from a label into a governed relation that can survive contact with reality. Update Rights specify who or what may create, edit, approve, override, retire, or restore authoritative state, preventing accidental or unauthorized authority changes. A Synchronization Rule defines how authoritative state propagates to dependent systems and how copies remain explicitly secondary rather than silently becoming competing sources. A Conflict Resolution Rule prescribes the workflow when disagreement is detected — accept, investigate, reconcile, quarantine, escalate, or correct the source itself — so the authoritative source can be challenged when it is stale or wrong. A Stewardship Owner carries ongoing responsibility for maintenance, disputes, and boundary updates, because an unstewarded source decays into an abandoned artifact still carrying apparent authority. The Audit Trail preserves changes, overrides, synchronization events, and authority transfers so the governing state remains accountable and interpretable. Finally, an Exception Rule lets emergency overrides, legal requirements, or local context temporarily supersede the normal rule while still creating a reviewable record, preserving flexibility without dissolving the authority structure.

Component	Description
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 ↗	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 ↗	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 ↗	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 ↗	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 ↗	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 ↗	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 ↗	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 ↗	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 ↗	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 ↗	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.

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.

Parameter / Tuning 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.

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.

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.

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.

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.

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.

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.

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.

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.