The Field-Conflict Verdict: Overwrite, Keep, or Escalate

Two sources give you different values for the same company field, and one of them has to win. This guide is for recruiting operations, revenue operations, and anyone answerable for how a record was built. It gives you a fixed scoring model to turn any single-field conflict - headcount, revenue, industry, or status - into a defensible overwrite, keep, or escalate verdict, with an audit trail a second person can reproduce.

This picks up exactly where entity matching ends. Once you have confirmed two records are the same company, matching is silent on which value survives when they disagree on one field. That is a separate decision, and "trust the newest source" gets it wrong often enough to matter.

What a field-conflict verdict actually decides

A field-conflict verdict is a per-field ruling on which of two or more candidate values survives into your golden record, and whether a human needs to sign off. It is not a record-level decision. Modern master data management assigns ownership by field, not by record, because real-world data quality is solved at the attribute layer.

That distinction is the whole game. A record can be right about a company's industry and wrong about its headcount at the same time, so resolving the record as a unit forces you to accept one source's mistakes to keep its correct fields. Platforms like Informatica and Reltio operationalize survivorship at the field level for exactly this reason. Your verdict scope is one field, two or more values, and three possible outcomes.

The three outcomes are fixed:

• Overwrite - a candidate value beats what your record currently holds, so it replaces it.
• Keep - the current value survives, either because it wins the score or because no candidate beats it decisively.
• Escalate - the score lands in the ambiguous band, so a steward decides.

The four survivorship strategies and why one rule is not enough

Four survivorship strategies are documented, and each is right in a narrow case and wrong outside it. The strategies are source-system precedence, most-recent-wins, most-complete-wins, and trust-score. The failure of most conflict-resolution setups is picking one and applying it uniformly.

Source-system precedence means a named system always wins for an attribute, for example a financial system always winning on revenue. Most-recent-wins takes the latest update. Most-complete-wins takes the fullest value. Trust-score assigns each cell a score and takes the highest, breaking ties by the most recent update date.

The documented weakness is blunt: source ranking alone is insufficient. So is completeness. Giving priority to good addresses makes a better decision than selecting the most frequent value, and a record with a valid phone number can outweigh a more complete record that has none. A single strategy cannot carry every field.

The right model is not one of these. It is a weighted combination scored per field: authority, recency scaled by decay class, corroboration, and a plausibility gate. The rest of this guide builds that.

The four scoring dimensions

Four dimensions decide the verdict, and each proves something specific while failing in a specific way. Score every candidate value on all four before you rule.

Source authority, per field

Authority is the reliability profile of the system a value came from, scored for this field, not in general. Survivorship rules are configured at the attribute level precisely so different fields can draw from different sources. A regulatory filing may be authoritative for company status and useless for headcount; a self-reported profile may be the reverse.

What it proves: a value came from a system with a track record on this attribute. Where it lies: authority ranking optimizes the wrong axis when the highest-authority source simply has more data rather than more correct data. In one test, the higher-coverage source (92%) held only a 3-point accuracy edge over a lower-coverage one. Ranking by volume would have picked the wrong winner.

Recency, weighted by decay class

Recency is only as strong as the field decays fast. Contact-class fields decay far faster than firmographic ones, so a fresh timestamp means very different things depending on the field.

The numbers behind the weighting are the spine of this framework. Contact data decays at 2.1% per month, compounding to 22.5% per year, and the field-dependent range runs from 22.5% to 70.3% annually. Firmographic data goes obsolete at roughly 20 to 30% per year. Contact data decays faster than firmographic attributes like industry classification or headquarters location, so a quarterly refresh on industry is acceptable while a quarterly refresh on direct dials is not.

What recency proves: for a fast-decay field, the newer value is more likely current. Where it lies: on a slow-decay field, a fresh timestamp on a wrong value is still wrong. Compare the recency weight against the field's decay class before you let it decide.

Corroboration count

Corroboration is how many independent sources carry the same value. If an entity name is found to have three different addresses, the address in the greatest number of matched records may be allocated as the primary. Take the mode.

This is where waterfall enrichment beats source ranking. No single provider cleared its accuracy ceiling, but a waterfall across many sources did.

What corroboration proves: independent sources converging on one value is strong evidence it is correct. Where it lies: three providers reselling one upstream feed look like three votes but are one. Confirm distinct provenance before counting.

Plausibility

Plausibility is whether the surviving value is internally consistent with the record's other fields. After survivorship rules are applied, the consolidated record goes through a validation layer for completeness, format compliance, and logical consistency. A company with 50 employees that grows to 500 no longer fits SMB segmentation, so headcount, revenue band, and size segment must agree.

What it proves: the value does not create an impossible record. Where it lies: it does not tell you which value is right, only that a survivor is wrong. It is a gate, not a chooser.

The scoring procedure

Run these eight steps in order. Steps one and two set scope; three through six produce the score; seven rules; eight makes it reproducible. The whole pass takes minutes per field.

One ordering decision you must fix in advance: whether trust score or recency breaks ties. Sources disagree. Informatica applies trust score before recency, breaking ties by the most recent update date. Some frameworks apply source precedence first and use recency only as a tiebreaker. Pick one, document it, and apply it every time, because an inconsistent order is the fastest way to make two analysts produce different verdicts on the same field.

Here is a rubric you can drop into a spreadsheet and score against.

Field in conflict: __________
Candidate value A: __________   Candidate value B: __________

Authority (0-3):     per-field reliability of the source system
Recency (0-3):       raw recency score
Decay class:         High weight (x2) for status/headcount/contact
                     Low weight (x1) for industry/HQ
Recency-adjusted:    raw recency x decay weight
Corroboration (0-3): count of INDEPENDENT sources holding this value
Plausibility gate:   PASS / FAIL (fail = disqualified regardless of score)

Total = Authority + Recency-adjusted + Corroboration (if PASS)

Auto-confirm threshold: ____   Non-match floor: ____
Verdict: OVERWRITE / KEEP / ESCALATE

Setting the two thresholds that decide escalation

The escalation band is the actual product of this system. Value is set not by the resolve rule but by the two thresholds around it. Set them too wide and everything queues to overloaded stewards; too narrow and wrong values auto-survive.

The banded model is documented across MDM platforms. A score below the clerical review threshold is a non-match. A score between the clerical review threshold and the auto threshold is a possible match sent to a review workflow so a person can decide. Above the auto threshold, the system merges automatically. In one vendor pattern, most records merge automatically but records at or below a confidence score of 80 stay unconfirmed for steward review.

Escalation is not a dead letter, because the human tier is staffed. In Refolk's index of professional profiles, there are 1,409 US professionals with data steward or data governance titles, against 1,290 with revenue operations titles - roughly one steward-function person per RevOps person in the US.

When you need to find the person who owns escalation for a given record, describing the role in plain language beats keyword filters. Refolk turns a request like the one below into named people with the title, industry, and location you asked for.

The US steward pool is deep, but the reviewer pool shrinks fast by geography. In Refolk's index the US RevOps population of 1,290 is about 5.9 times the UK population of 217, so if your records are owned out of a smaller market, plan escalation capacity around the smaller number.

How this goes wrong

The framework fails in predictable ways, and every failure has a check that catches it. These are the false positives that survive a careless verdict, and they are the most valuable part of this document because each one produces a record that looks resolved and is wrong.

• Blind most-recent-wins. A fast-updating but low-quality source overwrites a correct slow field. The false positive is a fresh timestamp on a wrong headcount. Check: compare the recency weight against the field's decay class before trusting recency.
• Most-complete rewards verbose junk. Choosing to overwrite from the longest value can promote padded or malformed strings. The false positive is a long industry string that is actually a concatenation. Check: run format validation before length is allowed to win.
• Fill rate mistaken for accuracy. A 100% fill rate means populated, not correct. The false positive is a complete-looking record with wrong values. Check: keep coverage and audited accuracy as separate columns and never let one stand in for the other.
• Corroboration counting non-independent sources. Three providers reselling one upstream feed look like three votes. The false positive is an inflated mode count. Check: confirm distinct provenance per source before you count.
• Cross-field checks skipped. Headcount survives from one source and revenue band from another, and the pair is impossible. Check: validate size-segment consistency after survivorship, not before.
• Threshold set once, never recalibrated. A static auto-merge threshold drifts as the source mix changes. The false positive is auto-resolving conflicts that now deserve review. Check: re-test thresholds on a sample set periodically.
• Job-level lineage instead of row-level. You know the batch ran but not which value won or why. Check: require row- and field-level audit stamps.

A related trap: per-field firmographic accuracy splits are not established publicly. Vendors publish coverage and email accuracy, not audited headcount-versus-revenue-versus-industry accuracy. So do not assign authority scores as if you had a published accuracy benchmark for each field. You do not. Build authority from your own reconciled history where you have it, and treat borrowed authority claims as unverified.

The lineage record that makes a verdict reproducible

A verdict is only defensible if a second person can reconstruct it, and that requires row-level provenance. Job-level lineage tells you a batch ran; it cannot answer why a specific value won a conflict. Audit columns that embed lineage directly into the data mean every row carries its own provenance, which is what reproducibility actually needs.

Capture the documented minimum set on every resolution: ownership records for who is responsible, source identifiers for where the data was first ingested, ingestion timestamps for when it arrived, audit stamps on subsequent changes for who modified what and when, and execution records for the pipelines that processed the data. Add a freshness timestamp so a reviewer can audit when each value was last computed and when each source page was last visited.

Keeping the framework current

The framework is stable, but two inputs drift and need periodic re-checking. The first is your threshold pair. A static auto-merge threshold silently degrades as your source mix changes, so re-test both thresholds on a labelled sample set on a schedule and move them when the sample shows the band is auto-resolving conflicts that should escalate.

The second is your per-field authority scores. Decay rates are field properties and change slowly, but which source is authoritative for a field can shift when a provider changes its collection method or you add a new feed. Rebuild authority from your own reconciled history rather than from vendor claims, since audited per-field accuracy is not published anywhere you can borrow it.

To pressure-test the whole model against practice, put it in front of people who have run this work. A request like "RevOps managers at US B2B SaaS companies who have run a golden-record or CRM enrichment project" surfaces practitioners who have lived the failure modes above and can tell you where your thresholds are wrong before your records do.