Two source systems disagree about which document version is authoritative. How would you resolve ownership and precedence?

Production incident (illustrative): A benefits RAG assistant answers that employees receive 20 days of parental leave, citing an intranet PDF. The HR policy-management system says 30 days under an approved revision. Both versions are indexed, both appear current, and the older intranet file ranks higher because its wording closely matches the question. The assistant repeatedly gives the wrong entitlement. This is not fundamentally an embedding problem: two publishing systems are claiming authority over the same policy.

1. Contain and scope the disagreement

• Flag the affected canonical_policy_id and policy scope (country, legal entity, workforce type, effective date). Temporarily block unsupported answers on this policy or route them to human-approved guidance; do not silently pick the top-ranked snippet.
• Capture the exact question, response, citation URLs, candidate source IDs, hashes, approval states, source timestamps, ingestion run IDs, tenant and ACLs.
• Notify the accountable business policy owner and ingestion owners. Preserve both records and audit evidence; don't delete conflicting copies before resolving lineage.
• For legally material or customer-impacting decisions, fail closed or explicitly identify the unresolved discrepancy. Authorization revocations take priority over version disputes.

2. Root-cause debugging checklist

• Compare source semantics: is one system the actual system of record, while the other is a syndication mirror, collaboration workspace, draft folder or cached export?
• Check approved_by, approval workflow, owner, policy revision ID, signed/published state, jurisdiction, effective-from/to, supersession links, and source-system revision sequence.
• Distinguish event time (when the policy applies), approval time, source last-modified, and indexing time. Newest upload or highest embedding similarity is not proof of authority.
• Follow lineage from original policy through copies/exports to chunks and citations. Look for an outdated mirror, a misconfigured connector marking drafts as ACTIVE, missed change notifications, or conflicting IDs mapped to separate canonical policies.
• Root cause in this example: both the canonical HR system and a replicated intranet PDF were treated as equal publishers; no enforceable authority registry, owner decision, or precedence gate existed ahead of retrieval.

3. Engineer explicit ownership and precedence

• Set up a governed source authority registry, keyed by tenant_id + policy_type + business_scope, not a one-size-fits-all global ranking. Store business_owner, technical_steward, primary source, eligible fallbacks, approval rule, effective-date rules, policy version and decision approver.
• Define authority as business ownership and approved publication rights, confirmed in governance records; don't infer it from last-write-wins, URL domains, filename or vector scores. A designated system of record may vary by entity/country/policy type.
• Map duplicates and exports to one stable canonical_policy_id; maintain separate source_record_id, source_system, source_version, content hash and derived_from lineage per copy. Preserve the original citations and approval evidence.
• Build a precedence decision gate, in order:

1. Authenticate tenant and enforce row/document ACLs for every candidate.
2. Determine applicable jurisdiction, entity, population and requested as_of date.
3. Require source ownership/approval and non-revoked status. Verify that the candidate falls within its valid effective interval.
4. Select the designated primary authority for that policy scope; consult approved fallback sources only if governance explicitly allows it and freshness/consistency checks pass.
5. Resolve within that source using a documented supersession/revision chain. A higher revision number across *different* sources is not comparable.
6. If equally authorized sources conflict or the declared primary cannot be verified, quarantine the policy for escalation rather than inventing a winner.

• Apply the authority and effective-version eligibility gate before vector similarity ranking. Keep drafts, mirrors and unapproved copies searchable for internal auditing but not eligible for production answers.
• Use a versioned, signed/approved authority decision record (who, when, evidence, scope, rule version). Publish a new retrieval eligibility manifest or metadata state only after validating references and source ACLs. Invalidate stale retrieval/answer caches, then test representative user queries.
• If two independent business owners legitimately retain separate rules, do not collapse them into one golden record: partition by scope and ask for missing context when needed.

4. Numerical production example

• At 09:00 the intranet export POL-LEAVE-v4 says 20 days, with similarity score 0.94. The approved HR system POL-LEAVE-v5 says 30 days, with similarity score 0.82.
• Naive top-1 retrieval selects v4 (0.94 > 0.82), returning the incorrect 20-day entitlement.
• Governance registry says HR Policy Manager is primary for India/full-time/2026, with v5 approved and effective 1 October 2026; intranet is a read-only derivative, last synced 20 September.
• An authority filter excludes v4 for current answers despite its higher semantic score. The assistant returns 30 days, citing v5, its scope and effective date. For an explicitly historical question dated 1 September 2026, the correct result may be v4 if its approval and effective-window records confirm it.
• Suppose a test set has 1,000 current-scope policy questions. Before the gate, 120 return an unauthorized/outdated version: 120/1,000 = 12% wrong-authority rate. After deployment, 8 do: 8/1,000 = 0.8%; that's an 11.2 percentage-point reduction and 93.3% relative reduction in wrong-authority answers. The remaining eight require investigation, not an assumption of perfection.

5. Trade-offs and failure modes

• Centralized authority registry improves auditability and predictable answers, but requires ongoing stewardship; an outdated registry can enforce the *wrong* source at scale.
• Per-scope ownership supports multinational policy differences, but adds metadata complexity and may require clarifying user context.
• Hard source filters reduce the risk of persuasive but unauthorized answers, though they may reduce recall and increase abstentions when the primary source is unavailable.
• Approved fallback can improve availability but may resurrect stale guidance. For high-risk policies, require explicit owner approval and TTL rather than automatic fallback.
• Manual arbitration is slower than heuristic recency ranking, but necessary when approval authority is genuinely disputed. Add deadlines and escalation tiers.
• Golden-record approach works when one authorized version exists; it should not flatten legally distinct country rules, future-effective policies, or historical answers.
• Security is separate from document authority: a correct authoritative file can still be forbidden to a given user. Keep tenant/ACL checks mandatory and never cite a restricted source.

6. Prevent recurrence

• Require one accountable business owner per policy scope, an up-to-date authority registry, and an explicit exception/appeals workflow for overlapping ownership.
• Validate canonical IDs, origin chains, approval metadata, effective windows, ACL inheritance and primary-source designation during ingestion. Reject unknown authority states from the serving index.
• Monitor multiple-active-authority conflicts, mirror lag, missing owner, unapproved-source retrieval, authority-registry drift, stale citation caches and unresolved dispute age.
• Add canary tests with higher-scoring but unauthorized mirror text, overlapping effective windows, late-arriving approvals, disputed owners, revoked ACLs and historical queries.
• Reconcile the source registry with business owners on a regular cadence and audit every promotion/override with evidence and approver identity.

Interview takeaway: When two document systems disagree, first decide who is authorized to publish policy for the applicable scope, then enforce ownership, approval, effective dates and lineage before semantic ranking. Similarity and timestamps decide relevance and freshness, not authority.

Further reading

• Microsoft Purview: Master data management — https://learn.microsoft.com/en-us/purview/data-governance-master-data-management
• Microsoft Purview: Data lineage in the Data Catalog — https://learn.microsoft.com/en-us/purview/data-gov-classic-lineage