AI source authority rules: which record should an agent trust?

Set AI source authority rules that separate different facts, name the governing record, and keep unresolved conflicts visible.

Two fields carry the same label. In the customer relationship management (CRM) system, “Plan tier” reads Enterprise, while billing’s “Plan tier” reads Growth. An AI agent asked “What plan is this customer on?” can see both, so which one is the authoritative record?

Before you ask which value is right, ask what each label means. In this fictional example, an account executive sets the CRM field to the tier they're selling toward in an open upsell. Billing sets its field from the contract that's active today. Both values are correct, because each one answers a different question.

An agent that returns either value without saying so has quietly answered a question nobody asked. That's the real risk when sources disagree. The fix isn't a smarter tiebreaker at query time.

It's two decisions made in advance. Do the records describe the same fact? If they do, which source has your organization declared authoritative for that attribute? Neither answer should be left for the agent to improvise.

Two values aren't a conflict until they describe the same fact

Start with four questions to distinguish a real conflict from a scope mismatch. Run them before any precedence rule, because a rule applied to two different facts produces a confident wrong answer.

Fictional record and field meanings, built for illustration. Your field definitions will differ.

Two “no” answers mean there's nothing to adjudicate. There are two separate facts that happen to share a label. The agent's job is to keep them apart: billing answers “What plan is active?” and the CRM answers “What tier is sales proposing?”

The entity check is easy to skip and expensive to miss. If the join between records is a guess, the agent can merge two customers into one dispute. That's a data-readiness problem upstream of authority, covered in how to prove data is ready for an agent's task.

The time check has its own depth. Which version of a record was in force on a given date is a retrieval problem, and it deserves separate treatment. Here, it only needs to answer one thing: are these two values about the same moment?

Authority is a decision, not something the agent works out

When the pre-check passes, you have a real conflict: same customer, same moment, same meaning, same scope, different values. Now precedence matters. The rule is simple to state: your organization decides in advance which source governs each attribute, and the agent applies that decision.

That rules out the tiebreakers an agent might reach for on its own. The newest record isn't automatically right, because a recent edit can be a mistake. The most complete record isn't right just because it has more fields filled. The value the model sounds most confident about carries no authority at all.

Kash Mehdi, vice president and field chief technology officer at Reltio, put the point plainly in a September 24, 2026, TechTarget article. “An agent should not decide authority simply based on which system it queried last or which record appears most complete,” he said. In the same piece, Omdia chief analyst Lian Jye Su recommended a system-of-record matrix that maps data types to their authoritative sources in advance.

Mehdi's other point changes how you build that matrix. Authority can sit at the attribute level, not the system level. A billing system can govern billing status while the CRM owns sales preferences and another platform owns customer identity. No system wins every attribute just because it wins one.

Fill in the authority map, one attribute at a time

An authority map names, for each disputed attribute, the governing source, the fallback, the disclosure rule, and the decision owner. Here's the map for the fictional customer, after the pre-check split “Plan tier” into two attributes.

Proposed method applied to a fictional record. Source names are categories, not product fields.

Two rows carry most of the weight. First, an active Growth plan in billing isn't proof of every feature the customer can use. Contracts carry add-ons, exceptions, and trials, so entitlement gets its own row. The agent doesn't grant access because a plan label suggests it should.

Second, the map is a policy for answering, not an instruction to fix records. If the agent notices the CRM tier looks stale, it reports that to the CRM owner. It doesn't write billing's value back into the CRM or edit either system on its own.

The owner column matters for the same reason. Each row has someone who decided it and someone who changes it. When a new attribute shows up without a row, the agent has no rule to apply. Treat that as a gap, not an invitation to guess.

Who should see the losing value?

Disclosure depends on who's asking. Showing both values is honest with an internal specialist. It's a leak when the second value is an internal sales note the customer was never meant to see.

Each row comes from the same records. What changes is how much of them the reader is allowed to see. A steward's packet can hold far more than any public answer, and it should.

This is where a confident, fluent answer does the most damage. It hides the contest from the people who need to know about it. That's the gap between an AI that sounds right and one that's actually right.

When two governing sources claim the same fact

Sometimes the pre-check passes and the map still doesn't decide. Here's that branch, on the same fictional customer.

The map says billing governs the active contract tier and the contract system governs signed terms. Then a mid-term upgrade is signed, and the contract system shows Enterprise, effective today. Billing still shows Growth for today. Both sources are now declared authoritative for overlapping definitions.

Fictional case. No system behavior, latency, or threshold is implied.

The agent doesn't average, pick the newer timestamp, or guess from the signed date. An Exemplary AI guide makes the same case for documents. It recommends letting a precedence hierarchy return “undecided” and reporting both sides with citations.

In the TechTarget piece, Mehdi said ambiguous or high-risk discrepancies should be escalated to human data stewards. Su added that an agent should flag discrepancies to the responsible business team rather than make consequential corrections itself.

Routing isn't resolution, though. A ticket assigned to a named steward is a next step, not an answer. The case closes when the owners record a decision and the source is corrected.

That accepted outcome also improves the map. A recurring undecided outcome is a signal that two authority claims overlap. Fixing the row once beats escalating the same contest every week.

Make the authority decision inspectable

Your source owners must settle the map before you test an agent against it. Otherwise, a plausible answer can conceal a policy decision nobody authorized.

Keep the governing row beside the agent's output. A cleared reviewer should be able to identify the attribute, source, fallback used, and audience-specific disclosure. For an undecided result, retain the competing evidence and named decision owner instead of accepting whichever value appeared first.

In an evaluation of Computer, by DevRev, can the proposed configuration produce that decision record without exposing restricted values to the customer? Can it leave a genuine tie undecided, without editing records or granting access? Ask DevRev to distinguish supported configuration from steps requiring human review. These questions don't establish native authority-map or conflict-resolution capabilities.

The broader governance context belongs in governing the knowledge your agents use, not in a model's improvised tiebreaker.

Start with the field you argue about most

Every team has one: the field that two departments read differently and nobody has formally settled. Pick that one. Run the four-question pre-check, write the map row, name the owner, and decide what each audience should see when the row doesn't decide.

Freshness is a separate decision. Who keeps each source current, and how often, doesn't settle which source governs. Keep the two apart, or “newer” will creep back in as a tiebreaker.

Copy the authority-map table and ask the named source owner to approve your row, including the fallback and disclosure rule. If the owners can't settle overlapping authority, record “undecided” as the required outcome until they do.

The agent shouldn't be the first participant to discover that nobody owns the decision.

Once one row works, build the governance architecture that turns a single authority map into a repeatable policy across sources: design the knowledge governance your agents rely on.