Responsible AI Practice4 min read

Before AI Merges Records, Define the Source of Truth

AI can surface likely duplicates, but it should not quietly decide which identity, field or history survives. Use a merge contract before records are combined.

Bokili EditorialPublished October 3, 2026· Verified October 3, 2026

Two supplier records compared at a human review gate, with conflicts flagged and both originals retained in an audit trail

A duplicate record looks like a tidy-up problem until the two rows disagree. One supplier entry carries the current bank verification, another has the approved payment terms, and a third-party address check points somewhere else. An AI system can rank the pair as a likely match, but a high similarity score does not answer the consequential questions: are these truly the same entity, which fields should survive, and what history must remain visible?

This is why an AI-assisted merge needs a human-owned source of truth. The UK Government Data Quality Framework treats uniqueness, completeness and consistency as separate dimensions; a record can be unique yet incomplete, or duplicated while each copy contains valid evidence. The ONS also notes that matching can create false positives and false negatives. The safest workflow therefore separates match suggestion from merge authority.

Write a TRACE merge contract before the first click

A merge contract is a short, reusable decision rule for one record type. It tells reviewers what counts as identity evidence, which system has authority for each field, and when the process must stop. Use TRACE to draft it:

TRACE merge contract

Target entity

Name the thing being identified: a legal supplier, a person, an account, a site or a contract. Do not let a shared name substitute for a shared identity.

Record evidence

List the evidence that can establish a match, such as a verified tax identifier, customer number or approved address. Mark weak signals, including spelling similarity, as supporting evidence only.

Authority per field

Name the source that wins for each important field. The finance system may own payment terms while procurement owns supplier status.

Conflict log

Record every disagreement and the reason for the chosen value. A reviewer should be able to reconstruct the decision without rerunning the AI.

Escalate and retain

Define fields that block an automatic merge, then preserve both original records and their provenance after a decision.

Similarity is not identity

Names, domains and addresses can help find candidates. They should not by themselves authorise a merge when identifiers, ownership or regulated attributes conflict.

Worked example: two supplier records, one uncertain identity

Suppose an AI assistant flags “Northline Studio Ltd” and “North Line Studios” as duplicates. The names and postcode are close. However, the tax identifiers differ, one record is approved for bank payments, and the other carries a current insurance certificate. Treat the suggestion as a review queue, not a merge command.

Reading is a start. Practice makes it stick.

Start learning

	AI suggestion	Human decision
Identity	Likely duplicate from name and address	Hold: conflicting tax IDs must be resolved by procurement
Payment terms	Prefer the newest value	Use the finance-owned approved value
Risk status	Combine both labels	Retain both until the legal entity is confirmed
History	Keep the merged row	Keep both originals, the decision log and a reversible link

If procurement confirms that the tax-ID mismatch was a data-entry error, the reviewer chooses a primary record, applies field-by-field survivor rules and logs why each value won. The secondary record can be deactivated, but it remains viewable. The Department for Education used a similar pattern in its duplicate-record design: side-by-side comparison, a chosen primary record, individual field decisions, comments and a retained secondary record. If the identity is not proven, both records stay active and the case is escalated.

Run the merge as a controlled decision

Five review steps

1
Freeze the candidates
Capture both records and their update dates before any changes.
2
Prove the entity
Check the contract’s identity evidence. Classify the pair as exact, likely or ambiguous.
3
Resolve by field
Apply the named source authority instead of choosing the most complete-looking row.
4
Record the exception
Log conflicts, missing evidence, reviewer and reason. Stop on any escalation field.
5
Preserve and test
Keep the originals, create the reversible link, and check downstream totals, permissions and alerts.

This control also supports accuracy. The ICO advises organisations to make the source and status of personal data clear and, in some cases, to retain an accurate record of a mistake rather than erase all trace of it. A merge log is therefore not administrative clutter; it is evidence that the current record can be explained.

Ten-minute merge-contract exercise

Choose two low-risk records that a system has flagged as possible duplicates.
Write the target entity and two pieces of identity evidence that would prove a match.
Name the authoritative source for three conflicting fields.
Mark one condition that must stop the merge and require escalation.
Decide how both originals and the review decision will remain accessible.

Make the rule reusable

Once tested, store the contract beside the workflow and review it when systems or responsibilities change. A good contract works with an assumption log, a workflow change log and an AI handoff card. Together they turn a one-off correction into a controlled, explainable operating practice.

The central discipline is simple: let AI find plausible pairs, but require people to define identity, authority and retained history before data is combined. The source of truth is not whichever row looks most complete. It is the record produced by an explicit, reviewable decision.