How to Resolve Conflicting Information Across Business Systems

A service manager asks an AI assistant: “Does Northstar have round-the-clock production support?” The CRM says business hours. An approved service change says 24/7. A recent chat message says weekend coverage has been removed. All three records mention the customer, and all three look relevant.

This is an illustrative IT services scenario, not a customer incident. It exposes a problem that connecting more sources cannot resolve on its own: the assistant can retrieve the disagreement without knowing how to adjudicate it.

Choosing the newest record would favor the chat message. Counting matching documents might favor an old CRM value copied into several reports. Asking a model to reconcile everything could produce a fluent answer that hides the disagreement. A dependable resolution requires a business rule for deciding which evidence applies to the precise question being asked.

Establish whether the records actually contradict one another

Start by examining the evidence before reducing it to an answer. In this example, the retrieved records contain the following details:

The chat message concerns the sandbox. It does not contradict the production service change. The CRM field lacks environment-level detail, so it cannot establish whether its value applies to production, sandbox, or the account's default service.

The approved change and live routing configuration do concern the same environment. However, they describe different facts: the coverage that has been approved and the routing that has been configured. Both can be accurate records of a business process that has fallen out of alignment.

This distinction determines what the assistant should say. “What coverage is approved?” and “Will a ticket reach the on-call team tonight?” need different evidence. If the user needs to make an operational decision, the gap between those facts matters more than selecting one value.

For implementation, compare claims using a key such as customer_id + service_id + environment + attribute, together with the relevant time interval. Keep approved_coverage separate from configured_routing. Do not collapse them into a single field called support_status.

Resolve identifiers before comparing values. An account name can refer to a parent company, a subsidiary, or an unrelated customer with a similar name. Where a source lacks a stable identifier, retain the proposed match as uncertain until a reliable mapping or an authorized owner confirms it. The model's confidence in a name match should not silently determine which customer's data is used.

Assign authority to a fact, then check when it applies

There is no useful universal rule that the CRM always outranks documents, or that approved documents always outrank live systems. Authority depends on the fact and the decision.

For this example, suppose the service owner has established that approved service-change records govern coverage commitments, while the service desk configuration governs what routing is currently configured. Account summaries are informational copies. Chat can point to a change that needs investigation, but it cannot override an approved coverage record by itself.

That policy belongs outside the retrieved prose. Store it as configuration maintained by the responsible business owner: which source governs an attribute, which approval state qualifies, which scope an exception can override, and who can resolve a tie. A document claiming to be authoritative should not be able to grant itself that position.

Retrieval remains valuable for finding candidates. Elastic's documentation describes reciprocal rank fusion as combining result sets using their relevance rankings. The practical implication for this design is that search position should remain a retrieval signal; source authority requires a separate decision rule.

Use that rule to filter for applicable records before choosing among versions. A customer-specific exception may take precedence over a general policy when the owner has explicitly authorized that relationship. Two equally authoritative, current records that disagree require review. An arbitrary timestamp tie-breaker would conceal a missing business decision.

Three timestamps deserve separate fields:

• Effective time: when the business rule or value applies.
• Source modification time: when the source record was edited.
• Observation time: when the assistant's system last read that version.

The CRM's September 4 modification could be an unrelated contact edit. It says nothing by itself about when the support field changed. SC-218 was approved in August but takes effect in September. A query about August 30 must use the policy applicable on August 30, rather than the newest document available today. For boundaries within a day, record the timezone as well.

Do not infer an effective date from an upload date when the decision depends on it. Mark the date as unknown and request the missing evidence. Where history matters, retain previous versions and distinguish what applied at the time from what the organization knew at the time; a backdated correction can change the former without changing the latter.

Observation time also limits the answer. Microsoft documents processing delays in Graph delta queries: a source change may not appear immediately in the change response. A completed synchronization therefore cannot, by itself, prove that every source is current.

For a decision that depends on present configuration, read the responsible system again where practical and permitted. Record the version or timestamp returned. If that read fails, say which observation is available instead of presenting cached information as a current check. More frequent reads improve freshness at the cost of latency and API usage; the acceptable interval should reflect the consequence of a stale answer.

Return the resolved facts and the remaining discrepancy

The assistant now has enough information to answer part of the Northstar question. SC-218 establishes approved production coverage from September 1 under the illustrative authority policy. The sandbox message is excluded from that determination. The account-level CRM summary needs correction or clarification, while the live routing record exposes an operational discrepancy.

An appropriate response would be:

Approved production coverage for NS-042 is 24/7 from September 1, according to service change SC-218. The production service desk routing still shows business hours in the configuration read on September 7. These records are out of alignment. The service owner needs to confirm and correct the routing before this answer can be used as confirmation of after-hours ticket handling. The September 5 message applies to the sandbox.

This output separates a supported answer from an unresolved operational condition. In an actual application, the record names should link to the exact accessible versions used, and the configuration observation should include its read time. A collection of links at the end is less useful if the reader cannot see which claim each link supports.

Preserve the resolution as a record, not just a paragraph. It should contain the question and scope, accepted facts, conflicting candidates, reasons for excluding records, policy version used, evidence references, observation times, and the responsible reviewer. A later run must be able to distinguish an old decision from a fresh evaluation.

Provenance also prevents copied information from becoming false corroboration. Three reports derived from the same CRM field are one evidence lineage, not three independent confirmations. The W3C PROV primer distinguishes derivation and revision relationships, which provides a useful basis for retaining those connections. Recording lineage does not establish truth; it makes dependencies inspectable when an upstream fact changes.

Sometimes there is no supported value to return. If two approved service changes cover the same production environment and effective period, and neither supersedes the other, the answer should identify the unresolved conflict and request a decision from the service owner. Repeatedly searching or asking the model to reconsider cannot supply the missing approval.

Keep these outcomes distinct in application state: a value resolved under policy, conflicting evidence requiring review, and insufficient evidence to determine a value. Missing information is not agreement. A system that encodes every failure as null loses the reason that downstream work needs to pause.

Access limits apply throughout this process. Retrieve and compare evidence within the requesting user's permitted scope. Where restricted evidence requires a privileged review, the review output must follow an explicit disclosure policy; the assistant should not expose a hidden document's title or contents to explain its uncertainty.

Close the discrepancy in the systems that caused it

A correct explanation does not repair the production routing. The service owner still needs to establish whether SC-218 should be implemented, amended, or superseded. The assistant can prepare the evidence and, where authorized, open a tracked review. It should not overwrite the service desk configuration merely to make the records agree.

Capture the owner's decision with its scope, effective date, reason, and affected record versions. Apply any approved changes through the normal control path, then read back the affected state. Approval is evidence of authorization; successful execution requires separate confirmation. If the record changed between review and write, re-evaluate against the new version rather than applying a decision to stale state.

The derived information needs attention too. Correcting the source while leaving an old account summary, search entry, or cached answer in circulation allows the same disagreement to return. Track which summaries depend on the corrected record and refresh or invalidate them as part of closing the review. Preserve the old evidence where retention and access rules allow, so historical answers remain explainable.

Before trusting this behavior, test it with deliberate variations of the example. Move SC-218's effective date into the future: the assistant should stop treating it as current coverage. Change the environment to sandbox: it should no longer override production evidence. Add copies of the CRM summary: the decision should stay the same. Introduce a second current approval with no supersession relationship: the assistant should request review.

Evaluate whether the correct entity and period were selected, whether unsupported resolutions were avoided, and whether the remaining work reached an accountable owner. Measure unnecessary escalations too. Refusing every difficult question can look safe while making the assistant unusable; the aim is to answer supported parts and isolate the specific decision that still needs a person.

The Northstar case is closed when the approved coverage and operational configuration have been reconciled by the responsible owner, dependent summaries have been refreshed, and the next answer can show the current evidence. Until then, the discrepancy belongs in the answer and in the work queue.