# The Field Conflict Rubric: Which Source Wins When Records Disagree

*You will be able to score any single-field disagreement on five dimensions and decide which value survives, when to keep both, and when to escalate.*

- Canonical URL: https://www.refolk.ai/guides/field-conflict-survivorship-rubric
- Pillar: Process, data, and compliance
- Format: Framework
- Published: 2026-08-15
- Last reviewed: 2026-08-15
- Reading time: 14 min

## Key takeaways

- Decay is concentrated, not uniform: job title changes for 65.8% of contacts a year and phone for 42.9%, while firmographics barely move, so recency should govern volatile fields and trusted-source should govern stable ones.
- One job change breaks four fields at once - title, email, phone, and company - so field conflicts cluster on a record; resolving them jointly by asking whether the person moved beats scoring each cell in isolation.
- Corroboration only counts when sources are independent: two aggregators reselling one upstream feed look like agreement but are a single source, so check lineage to origin before you count to two.
- Auto-accept only when 2+ independent sources agree or confidence clears your threshold; single-source values below threshold get held or escalated, never silently written.
- Manual resolution does not scale: two researchers took 143 hours to reach 91% accuracy on 10,000 contacts, and the list was stale on delivery, which is why the uncertain band is the only part a human should touch.
- In Refolk's index there are about ten times as many RevOps title holders in the US (412) as in the UK (41), so a hand-applied rubric, not an MDM hire, is the realistic tool for most teams.

When two data sources return different values for the same field on one record you have already matched, you have to decide which value survives. This guide is for the RevOps and RecOps operator who owns CRM or ATS data quality and has two conflicting cells in front of them right now. It turns the enterprise idea of survivorship into a five-dimension rubric you can apply by hand, without an MDM platform, to a single disagreement.

This sits one layer below entity matching. It assumes the two rows are already certified to be the same person or company. It covers only which value wins, when to keep both, and when to hand the conflict to a human.

## What this rubric decides, and what it does not

This rubric decides the value of one field on one already-matched record. It does not decide whether two records are the same entity - that is entity resolution, and it happens upstream. If you are not certain the rows describe one person or one company, stop and resolve that first; survivorship logic run on a bad match produces confident nonsense.

The documented survivorship strategies are few, and every generic golden-record explainer stops after naming them: trusted-source precedence, most-recent, most-complete, consensus or frequency, and validation. Naming the strategies is not the hard part. The hard part is choosing which one governs *this* field on *this* conflict, and doing it the same way every time. That choice is what the rubric produces.

Two facts frame the whole exercise. First, the people accountable for it are scarce. In Refolk's index there are 412 US professionals holding a Revenue Operations title and 175 holding Recruiting or Talent Operations titles - a pool of under 600 people who own this call across US tech. Second, doing it by hand at volume is punishing: two researchers took 143 hours to manually enrich 10,000 contacts to 91% accuracy, and the list was stale on delivery. So the design target is not perfection. It is a scored rule that auto-accepts the clear cases and escalates only the uncertain band.

**143 hours - Manual effort to enrich 10,000 contacts to 91% accuracy**

Two researchers, and the list was already stale when the project wrapped - which is why only the uncertain band should reach a human.

## Score the field on five dimensions

Score every conflict on five dimensions, then let the field's volatility decide which dimension leads. The five are source trust, recency, corroboration, completeness, and validation. Each one proves something specific, and each one lies in a specific way.

- **Source trust.** What it proves: some systems are more reliable than others for a given attribute, so a confidence level or trust rank per source lets the highest-scoring source win. How it lies: a global ranking forces you to take a source's worst fields along with its best, so a uniformly "trusted" record can carry a wrong title.
- **Recency.** What it proves: the freshest value is usually the truest for a field that changes. How it lies: recency without a verified source-side timestamp promotes the latest write even when it is wrong. Require a "Last Edited" date from the source, not your ingestion date.
- **Corroboration.** What it proves: agreement across independent sources raises confidence. How it lies: two aggregators reselling one upstream feed look like two sources but are one, so check lineage to origin before you count to two.
- **Completeness.** What it proves: a record with fewer nulls carries more usable fields. How it lies: a filled-in-but-stale value can beat a correct null, so a fuller record is not a truer one. Read the timestamp alongside completeness.
- **Validation.** What it proves: a value that passes a format or deliverability check (a phone that dials, an email that does not bounce) is more likely real. How it lies: a syntactically valid value can still belong to the wrong person after a job change.

> **Rule:** Score per field, never per record
>
> Assign a governing rule to each attribute, not to the whole record. "Trust the ERP for everything" forces you to inherit that system's wrong values to get its right ones. Modern practice assigns ownership by field.

## Which rule governs which field

Let volatility pick the leading rule: recency-led for fields that decay fast, trusted-source-led for fields that barely move, consensus for low-confidence fields. This is the single most useful mapping in the guide, because decay is concentrated, not uniform. A flat rule over one record over-trusts the volatile fields and under-uses the stable ones.

The decay figures make the split concrete. Job title changes for 65.8% of business contacts within a year - the single largest driver of B2B data decay. Direct phone changes for 42.9%, email for 37.3%. Firmographic fields like HQ and employee count drift far more slowly. Aggregate decay sits around 2.1% per month, compounding to roughly 22.5% a year, with Gartner placing the high end near 3% per month - but that aggregate masks the field-level spread that actually drives your rule choice.

| Field | Annual change rate | Suggested governing rule |
|---|---|---|
| Job title | 65.8% | Most-recent (verified timestamp) |
| Direct phone | 42.9% | Most-recent + validation |
| Email | 37.3% | Validation + most-recent |
| Firmographic (HQ, size) | Slower drift | Trusted-source |

The insight that ties this together: one job change breaks four fields at once. When someone is promoted, moves to a competitor, or leaves, their title, work email, and direct-dial all go stale together. So conflicts cluster on a record rather than scatter across your database. Before you score a title conflict cell by cell, ask the cheaper question first: did this person move? If they did, resolve title, email, and phone jointly from the fresher source rather than fighting each field alone.

#### Volatility vs authority - which rule leads

Horizontal axis runs from Low decay to High decay. Vertical axis runs from Low source authority to High source authority.

| Quadrant | What it means |
| --- | --- |
| Stable, no clear authority (aliases, tags) | Consensus or most-complete, low stakes |
| Stable, authoritative (legal name, registry ID) | Trusted-source wins, refresh rarely |
| Volatile, no clear authority (self-reported title) | Most-recent with a verified timestamp, corroborate before write |
| Volatile, authoritative (direct phone, work email) | Most-recent plus validation, trust decays with age |

*Place the field by how fast it decays and how authoritative any single source can be, then read the governing rule from its quadrant.*

Trust should decay with time, not just rank. A source ranked highest today loses authority as its value ages, and a fresher source should take over. This is why "trusted-source" and "most-recent" are not opponents - trusted-source picks the pool of acceptable sources, and most-recent picks the freshest value inside that pool. You still need to know which of the trusted source's values is the most up to date.

## The corroboration gate: when a value is allowed to write

A value is allowed to auto-write only when it clears a confidence gate: two or more independent sources agree, or a single source's confidence clears your threshold. Anything below that is held or escalated, never silently written.

There is no published universal threshold, but there is a documented working hierarchy that maps agreement to trust tiers. Use it as your default gate and tune the numbers to your data.

| Trust tier | What it means | Gate action |
|---|---|---|
| Rep-verified | Confirmed by a human | Auto-accept, highest trust |
| 90+ confidence | Verified by multiple independent sources | Auto-accept |
| 70-89 confidence | Single-source match | Hold or review |
| Form-submitted | Self-reported, may be inaccurate | Never write over verified data |

The word doing the work is *independent*. Corroboration count only means something if the sources do not share an upstream feed. Provenance to origin is the check: trace the value back to its official source before you treat two matches as two votes. If both came from the same aggregated feed, you have one source wearing two coats.

The waterfall model enforces this cleanly. In a properly configured sequential waterfall, conflicts are rare because only one provider's result is written per field, and the waterfall advances to the next provider only when the previous one returned nothing or returned a result below your confidence threshold. Single-provider match rates run 55% to 70%, so up to 45% of records come back incomplete; a second provider recovers 15% to 25% of what the first missed. That is why the gate matters - you are stacking sources precisely because no single one is enough.

I ran this search: `RevOps and revenue operations managers at Series B SaaS companies in the United States who own CRM data quality.` - [see the full result list](https://www.refolk.ai/s/bfmvn8ef23).

*Returns the named people who own this judgement call, with the current-role context you need to route escalations to the right steward.*

When a conflict fails the gate, you need to find the human who owns it. That is a sourcing problem, and it is the one [Refolk](/) removes: instead of guessing who owns CRM data quality at an account, you ask for them in plain English and get the named people back. The same query pattern works for talent operations owners of ATS hygiene, or MDM stewards at enterprise firms.

## Run the procedure

Follow these eight steps in order for any single-field conflict. The rubric lives inside step four; the steps around it make the decision repeatable and auditable.

#### Resolving one field conflict on one matched record

1. **Confirm the record is already matched** - Verify entity resolution certified the two rows as the same entity before scoring any field. Survivorship starts only after matching finishes.
2. **Isolate the field and pull both values with provenance** - Take the one conflicting field and retrieve each value with source name, source-side last-verified timestamp, and confidence.
3. **Classify the field's volatility** - Tag the field volatile (title, phone, company) or stable (legal name, registry ID, HQ). This decides whether recency or trusted-source leads.
4. **Score the five dimensions and pick the rule** - Score source trust, recency, corroboration, completeness, and validation, then select the governing rule for the field rather than improvising.
5. **Apply the rule and check the corroboration gate** - Run the chosen rule, then accept only if two or more independent sources agree or confidence clears your threshold.
6. **Escalate below-threshold or high-stakes conflicts** - Route failing or high-stakes values to a steward through an exception workflow carrying context and a suggested resolution.
7. **Write the survivor plus a provenance capsule** - Write the winning value with source, timestamp, owner, and confidence, and retain the losing values rather than deleting them.
8. **Re-verify on cadence** - Schedule re-verification so fields do not silently degrade; 90 days is the minimum refresh baseline for CRM hygiene.

#### How many conflicts should reach a human

| Stage | Figure | Note |
| --- | --- | --- |
| All field conflicts | 100 | every disagreement on a matched record |
| Cleared by rule + gate | 70 | two independent sources agree or confidence clears threshold |
| Held for re-check | 20 | single-source or below threshold, retryable on cadence |
| Escalated to steward | 10 | high-stakes or unresolvable by rule |

*The gate exists so that only the uncertain band reaches a steward, because manual review does not scale.*

The funnel figures are illustrative of the shape, not measured proportions - your split depends on how many independent sources you run and how you set the threshold. The point is the shape: the human band should be the narrowest stage, because 143 researcher-hours for 91% accuracy is the cost of widening it.

## How this goes wrong

Most survivorship failures are not exotic. They are a handful of predictable false positives, and each one has a specific check. Learn these, because a wrong resolution at scale is worse than an unresolved conflict - at least an unresolved conflict is visible.

| Failure mode | What it looks like | The check |
|---|---|---|
| First-match masquerading as best-match | Cheapest source queried first wins the field | Compare source rank against confidence, not query order |
| Most-recent promotes a bad write | Latest edit wins even though it is wrong | Require a source-side "Last Edited" date, not ingestion date |
| Global ranking takes worst with best | Uniformly trusted record with a wrong title | Confirm the rule is field-level, not record-level |
| False corroboration | Two vendors reselling one feed look like agreement | Trace lineage to origin before counting to two |
| Completeness beats a correct null | A fuller but stale value wins over an accurate blank | Read the timestamp alongside completeness |

Three more failures live in the plumbing rather than the rule. **Silent degradation:** golden records decay silently without monitoring, so conflicts resolve wrong at scale and nobody notices until a campaign bounces. Set the re-verify cadence and watch it. **Externally-maintained attributes:** values that arrive without revision traceability break survivorship, because the logic depends on knowing when each value was last edited; do not run recency rules on fields you cannot timestamp. **Provenance recorded as an app log:** the most common audit failure is assuming an ordinary application log is sufficient provenance. A log tells you your system wrote a value at a time; it usually omits the origin source and classification, which are exactly what an audit or incident reconstruction needs.

> **Watch out:** Recency without a verified timestamp is a trap
>
> The single most damaging false positive is most-recent promoting a wrong value because "recent" was measured by when your pipeline ingested it, not when the source last edited it. Ingestion date is not edit date. Never let recency win on ingestion time.

> A fuller record is not a truer one, and the latest write is not the most recent edit.

## Store the survivor so it survives an audit

Write the winning value together with a provenance capsule, and keep the losing values. Provenance means the ability to trace every data point back to its official source with timestamps - that is what closes the trust gap and what an audit or incident reconstruction actually reads.

The strongest implementations preserve five things per field: source, timestamp, owner, classification, and access path. Golden-record design adds field-level confidence scores and version history so you can roll a wrong resolution back. The W3C PROV entity-activity-agent model is the standard shape if you want to align your capsule to something portable.

**Per-field provenance capsule**

```
field: <field name>
surviving_value: <the value that won>
source: <official source, traced to origin>
source_last_edited: <source-side edit date, not ingestion date>
owner: <system or steward accountable>
confidence: <0-100 or your tier>
rule_applied: <trusted-source | most-recent | consensus | validation>
corroborating_sources: <count of INDEPENDENT sources that agreed>
losing_values: <value :: source :: timestamp for each contender>
classification: <e.g. contact PII, firmographic, public>
next_reverify: <date, per cadence>
```

*Attach one of these to every resolved field. Drop fields your stack cannot populate, but never drop source and timestamp.*

Retaining losing values is not hoarding. When a conflict re-opens - and volatile fields will - the retained contenders and their timestamps let you reconstruct why the current value won without re-querying every source. It is also your defence when someone asks how a record got its value.

## Keep the resolution current

A resolved field is not permanently resolved; it starts decaying the moment you write it. Treat 90 days as the minimum refresh baseline for CRM hygiene, and shorten it for the fastest-decaying fields. Between cycles, decay continues daily, and it takes surprisingly little to push bounce rates past the 1% threshold that damages your sending domain reputation.

Set the cadence by field, not by record, because the fields decay at different speeds. Title and phone earn a tighter loop than HQ or legal name. Median employee tenure is 3.9 years across all workers and 3.5 in the private sector, which tells you roughly how often the role-linked cluster of fields turns over per person - frequently enough that a static record is wrong within a couple of years.

#### Before you call one field conflict resolved

- [ ] The two rows were certified the same entity upstream, before scoring
- [ ] Both competing values carry source, source-side edit date, and confidence
- [ ] The field is tagged volatile or stable, and the governing rule matches the tag
- [ ] Corroborating sources were traced to origin and confirmed independent
- [ ] The value cleared the gate, or was escalated - it was never silently written
- [ ] A provenance capsule is stored and the losing values are retained
- [ ] The field has a next-reverify date and is under decay monitoring

Two roles will own this cadence in practice, and Refolk's index shows the split: Revenue Operations makes up about 70% of the accountable pool in US tech, Recruiting and Talent Operations the other 30%. That imbalance matters because the RevOps world is where CRM decay bites hardest, and it is also where the rubric pays off fastest. Wherever the owner sits, the discipline is the same: score the five dimensions, let volatility choose the rule, gate on independent corroboration, escalate the narrow uncertain band, and store enough provenance that any resolution can be explained and undone.

## Frequently asked questions

### Most recent or trusted source - which one wins by default?

It depends on the field, not the record. Trusted-source should win on stable, authoritative fields like legal entity name, registry IDs, HQ and financials, because they barely move. Most-recent should win on volatile fields like job title (65.8% annual change), direct phone (42.9%) and email (37.3%), because a trusted source that is stale is simply wrong. Assign the rule per attribute and require a verified source-side timestamp before recency can promote a value.

### How many sources need to agree before I auto-accept a value?

No universal number is published, but the documented working hierarchy treats agreement from two or more independent sources as the auto-accept tier and a single-source match as review-worthy. Independence is the catch: two vendors reselling one upstream feed count as one source, not two. Confirm lineage to origin before you count corroboration, then auto-accept only when independent agreement or your confidence threshold is met.

### When should a field conflict go to a human instead of resolving automatically?

Escalate when the value fails your confidence gate, when sources conflict and neither clears the threshold, or when the field is high-stakes (billing, legal name, contract owner). Automated merge should handle high-confidence cases; lower-confidence ones route to a steward through an exception workflow that carries context and a suggested resolution. Keep the escalation band narrow, because manual work does not scale - 143 hours bought only 91% accuracy on 10,000 contacts.

### What do I store so the resolution is auditable later?

Store a provenance capsule per field: source, timestamp, owner, classification, access path, and the confidence score, plus the losing values. Provenance means tracing every data point back to its official source with timestamps, and it should support version history and rollback. An ordinary application log is not provenance; it usually omits origin and classification, which is the most common way audits fail.

### Why not just rank my sources once and always trust the top one?

A global source ranking forces you to take that source's worst attributes along with its best - you inherit its wrong titles to get its right addresses. It also ignores decay: a top-ranked source loses authority as its value ages, and a fresher source should take over. Define survivorship at the attribute level and let trust decay with time, not just rank.

### How often should resolved fields be re-checked?

Treat 90 days as the minimum refresh baseline for CRM hygiene. Volatile fields drift faster - contact data decays around 2.1% per month - so between cycles bounce rates can creep past the 1% threshold that damages sending domain reputation. Set a next-check date on each field, monitor for silent golden-record degradation, and shorten the cadence for the fastest-decaying fields like title and phone.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/field-conflict-survivorship-rubric*