Which System Is Allowed to Be Right?

A CRM says the customer is active. Accounting says the account is overdue. A project tool says the work is complete. A spreadsheet says revenue is higher than both systems report. Connecting those sources does not settle the disagreement. Someone still has to decide what each fact means and which record is allowed to be right.

This is the part of data fragmentation that software demos rarely show. The records may be technically available and still be unusable together because the business has not defined identity, authority, timing, or meaning.

The useful goal is not one enormous database. It is a dependable answer contract: for each important question, the business can identify the definition, source, time rule, and exception path behind the answer.

Access is not authority

An integration can make a field available. A warehouse can copy it. A dashboard can display it. An AI assistant can summarize it. None of those actions determines whether the field should govern a business decision.

Authority must be assigned at the level where disagreement occurs:

Identity: Which records belong to the same person, company, request, project, or transaction?
Definition: What does “lead,” “customer,” “active,” “complete,” or “revenue” mean here?
Source: Which system records the event that makes the fact true?
Time: Is the answer based on creation, booking, completion, invoice, payment, or reporting date?
State: What event changes the status, and can a later event reverse it?
Exception: What happens when the sources disagree, arrive late, or cannot be matched?

If those decisions are absent, the business does not have one source of truth. It has several sources and an unstated argument about which one wins.

A unified profile is not automatically a golden record

Salesforce makes an unusually useful distinction in its current identity-resolution documentation. Data 360 can connect source profiles through matching and reconciliation rules, but Salesforce says the resulting unified profile is not a golden record and does not overwrite the source systems. It functions as a set of keys that helps a user reach the appropriate source data for a particular use case.

That distinction matters well beyond one platform. A combined view can answer “Which records appear to describe the same customer?” without answering “Which address should fulfillment use?” or “Which revenue value belongs in the monthly close?” Different questions may legitimately require different authoritative sources.

AI exposes semantic debt; it does not decide the business meaning

Microsoft’s current guidance for Fabric data agents gives a direct example. If a semantic model contains Total Revenue, Gross Sales, Net Sales, and Sales After Returns, a request for “sales” is ambiguous. The agent can select the wrong measure unless the organization narrows the schema and defines the intended metric.

The model is not missing intelligence. It is missing a business decision. The same problem appears when one department considers a submitted form a lead, another requires a reachable person, and a third counts only a qualified opportunity.

AI can make this debt less visible by producing one polished answer from several conflicting sources. That is false coherence: the interface feels unified while the definitions underneath it remain unresolved. Before an assistant is trusted to answer or act, the important terms need approved definitions and source rules.

Build an authority map around decisions, not applications

Do not label one product “the source of truth” for the entire company. Start with ten questions that affect money, customers, commitments, or capacity. For each question, record the following:

The exact question in the language a manager would use.
The operational definition of every important term.
The event that makes the answer true.
The system that records that event first.
The identifier that connects it to the customer or transaction.
The date and status rules used in the answer.
The systems that may display a copy.
The person who resolves an exception.

An authority map might produce decisions such as:

Accounting establishes collected revenue; the CRM displays the returned payment status.
Scheduling establishes whether an appointment occurred; the CRM preserves the customer relationship.
The approved estimate establishes quoted value; the project system records delivery status.
The CRM establishes qualification only after the agreed criteria are completed.

Those rules are more useful than a general promise that “everything syncs.” They specify which event, field, and system should govern each decision.

Test one answer from source event to management decision

Choose one question the business currently struggles to answer, then produce its evidence chain.

Ask: For example: How much work from June website inquiries has been completed and paid?
Trace: Follow the inquiry ID through the website, CRM, scheduling or project system, invoice, and payment.
Reconcile: List duplicates, unmatched records, conflicting statuses, missing identifiers, and date differences.
Authorize: State which source governs each fact and why.
Repeat: Confirm that the same rules reproduce the answer without a private spreadsheet or one person’s memory.

If the evidence chain fails, the fix might be a shared identifier, a definition, a returned status, a permission change, or a repaired handoff. It is not automatically a new dashboard, warehouse, CRM, or AI assistant.

One database is not always the goal

A coherent business can use several systems. Accounting, fulfillment, service, and customer management may need different controls and data models. Forcing every activity into one application can reduce fit, weaken controls, or create an even larger migration dependency.

Coherence comes from explicit identities, meanings, authorities, transitions, and exceptions across those boundaries. Sometimes consolidation is the right move. Sometimes the better answer is to keep the tools and make the record contract between them dependable.

A focused business systems review can examine one disputed record path. When the disagreement extends into recurring work, reporting, roles, and internal decisions, it belongs in a broader business systems consulting engagement.

What this does not prove

Different totals do not automatically mean one system is defective.
A unified profile does not guarantee that every field has one universally correct value.
A single database does not guarantee shared definitions or accurate entry.
A semantic layer can encode approved meaning; it cannot decide company policy on its own.
An AI answer with citations can still use the wrong definition, date, source, or identity.
More integrations do not remove the need to assign authority and handle exceptions.

The examples above describe documented architecture and a practical decision framework. They do not prove that every platform, implementation, or disagreement behaves the same way. The test is whether the business can reproduce an important answer from named events and rules.