Source of truth and information authority

Leaders often ask for a single source of truth because they want clarity and trust. The intention is understandable. The problem is that enterprise reality is usually more complex. Different systems may be authoritative for different attributes, stages, or forms of publication of the same business object.

If the architecture responds to the slogan too literally, it can flatten real governance needs and create the false impression that one product can own the truth of everything. The transmission operator in the opening story spent four months looking for a winner that did not exist because the directive assumed a shape of reality that the enterprise did not have.

The slogan causes three specific problems. First, it implies a single system answer when the enterprise actually has distributed authority. Second, it discourages the team from asking the harder question: "Which parts of this entity are authoritative in which system, for which purpose?" Third, it can become a political tool where system owners compete to be named "the source of truth" rather than collaborating on a shared authority model.

Four kinds of authority appear repeatedly in enterprise information architecture. Recognising them prevents the architecture from collapsing a nuanced problem into an impossible one-system answer.

Attribute authority. One system or role may be authoritative for selected fields or properties, but not for the whole entity. Customer identity might sit in one system while service history sits in another. In a London distribution network, the asset register might be authoritative for asset specification data while the GIS is authoritative for spatial location. Both are legitimate. Neither is the whole truth.

Lifecycle authority. Different actors may control different stages such as registration, validation, operational update, retirement, or publication. The system that creates a record may not be the system that validates it for external publication. A connection application might be created in one system, validated in another, and published through a third. Each stage has its own authority owner.

Stewardship authority. A governance role may protect quality, meaning, and standards without being the operational producer of every data change. The steward does not necessarily own the system. The steward owns the rules. In TOGAF terms, stewardship is the governance responsibility that ensures metadata definitions, quality thresholds, and usage policies are maintained even when multiple systems participate in producing or consuming the information.

Publication authority. The enterprise may designate which representation is trusted for external or cross-enterprise consumption even when upstream authority is shared. This is the "last mile" authority that determines what consumers are expected to rely on. In the London case, the LTDS publication layer has publication authority for network development information even though the upstream data is produced by planning and asset systems.

The four authority types combine into an information authority ownership model with five layers. Each layer answers a different governance question, and together they replace the single-source slogan with a structured, testable view.

1. Entity and domain identification. What is the business entity or information domain being governed? Use enterprise language from the information map (Module 27), not system or table names.
2. Attribute decomposition. Which attributes or attribute groups need separate authority assignments? Not every attribute needs the same governance treatment. Identity attributes may need tighter control than historical transaction records.
3. Authority assignment. For each attribute group, which system, role, or team holds attribute authority and lifecycle authority? This layer records who can create, update, validate, and retire the information.
4. Stewardship assignment. Which role or function stewards the meaning, quality rules, and usage policies? The steward may be different from the operational authority. The steward ensures the rules are followed across all participating systems.
5. Publication designation. Which representation is trusted for external or cross-enterprise consumption? What metadata must travel with the published view? This layer connects authority to the downstream trust that consumers depend on.

The model is documented as a matrix or structured table, not as a single-system declaration. Each row represents an entity or attribute group. Each column captures one of the five layers. The result is an authority map that governance boards can review, challenge, and use to resolve disputes.

In an asset-intensive organisation, the engineering team may hold attribute authority for asset specification data. The maintenance team may hold lifecycle authority for condition updates. The data governance office may steward the definitions and quality rules. The regulatory-reporting function may hold publication authority for the view that the regulator receives. Asking "which system is the source of truth for assets?" misses all five layers of this model.

A practical information-authority exercise follows four steps that align with the ownership model described above.

1. Name the business entity or information object in plain language. Use enterprise vocabulary from the information map, not system or table names. "Customer" is enterprise language. "CRM_CONTACT_MASTER" is not.
2. Break the object into the attributes or lifecycle states that matter to real decisions. Not every attribute needs the same governance treatment. Customer identity, contact details, billing attributes, and service history may each have different authority owners.
3. Record which system or role is authoritative for each part and which role stewards the meaning and controls. This step populates the authority and stewardship layers of the ownership model.
4. Record which published representation consumers are expected to trust and what assumptions or caveats travel with it. This step populates the publication layer and connects authority to downstream consumer trust.

This produces an authority map rather than a single-system claim. The map is more honest, more governable, and more useful for integration and publication decisions later.

The phrase can still be useful when the architecture is genuinely talking about one defined representation for one defined consumer purpose. The problem is not the phrase itself. The problem is using it without saying what is authoritative, for whom, and under which conditions.

A team that says "the CRM is the single source of truth for customer contact details used by the call centre" has made a bounded, testable claim. The claim specifies the entity (customer contact details), the authority system (the CRM), and the consumer purpose (call-centre use). That claim can be validated, governed, and changed when conditions change.

A team that says "we need a single source of truth for customer data" has made a claim too vague to govern anything. It does not specify which attributes, which lifecycle stages, which consumers, or which publication channels. The architecture team should always push for the bounded version.

Three conditions make a single-source claim testable. First, it specifies which attributes or lifecycle stages are covered. Second, it names the consumer purpose the authority serves. Third, it states how conflicts with other systems are resolved. If all three are present, the claim is useful. If any are missing, the claim needs refining before it can be governed.

In London Grid Distribution, customer details, planning assumptions, asset condition, topology, telemetry, and published outputs do not all share one natural authority location. They sit across functions and systems with different operational and governance responsibilities.

The London authority map needs to show at least the following authority assignments.

• Customer information. Identity attributes may be authoritative in the customer-management system. Connection-request details may be authoritative in the connections platform. Billing attributes may be authoritative in the finance system. Stewardship should sit with the customer-data office.
• Planning information. Scenario assumptions are authoritative in the planning-modelling tool. Published forecasts carry publication authority through the LTDS layer. The planning team stewards the methodology and interpretation rules.
• Asset information. Specification data may be authoritative in the asset register. Condition data may be authoritative in the maintenance system. Spatial data may be authoritative in the GIS. The asset-data governance office stewards definitions and quality thresholds.
• Network information. Topology and connectivity are authoritative in the network model. Ratings and constraints may be authoritative in the engineering-design system. Publication authority for external network development data sits with the LTDS publication layer.

That is why the London case needs an information-authority map rather than a one-system myth. The course uses that map to explain downstream publication rules, integration choices, and analytics trust. Every module that follows in Stage 4 builds on the authority structure defined here.