For CDOs + data platform + master-data stewards + MDM architects
Same customer in three systems. Three different email addresses. Informatica MDM ships survivorship rules. Which actual rule applies to your operator data estate is your wiring.
POS captures the purchase amount accurately. CRM captures the email correctly because the customer provided it during the last campaign engagement. Loyalty platform captures tier status because it owns the points-earned event. The same customer in 8-12 source systems carries different facets correctly per source. Record-level resolution picks one source and drops the rest; field-level resolution preserves the per-field accuracy by deciding per-field per-source.
What this gets you
- Field-level conflict resolution policy — per-field per-source precedence rules. POS authoritative for purchase amount. CRM authoritative for email. Loyalty platform authoritative for tier status. USPS-validated source authoritative for address. Each field decides independently.
- Per-vertical policy variants— healthcare records under HIPAA need different reconciliation policies than retail records. Financial-services records under FINRA need explicit reviewer approval for changes to PII anchor fields. Cannabis records vary per state. Per-vertical policies layer on top of the base reconciliation rules.
- Per-franchisee policy variants— some franchisees own their own CRM with field-level authority for franchise-specific data. Per-franchisee precedence overrides sit in the customization layer.
- AI-generated-data handling— AI-generated fields carry provenance metadata (generating-agent ID + prompt version + brand-voice gate evaluation + compliance gate evaluation). Policy defaults to system-captured values when AI-generated conflicts with system- captured. Operators tune AI-vs-system precedence per field.
- Real-time vs batch reconciliation routing — high-stakes records (customer-facing identity changes, regulated-data updates) reconcile in real time. Lower-stakes records reconcile in micro-batches. Same policy library; different runtime envelope.
Three sources, three different emails, three different tier statuses
A multi-location operator runs the same customer across 9 source systems. The customer-relationship management system (Salesforce) has email-A captured from the customer signup form three years ago. The email service provider (Klaviyo) has email-B that the customer provided during a campaign engagement two years ago after changing addresses. The loyalty platform has email-C captured at the most recent in-store loyalty-signup six months ago at the Phoenix location. The POS at the Phoenix location has email-C from the same loyalty-signup. The booking system has email-A from the customer original CRM contact. The ecommerce platform has email-B from the customer most recent online purchase. The call-tracking provider has captured email-B during a call last month. The customer-service ticketing has email-C from a service inquiry two weeks ago.
The operator data team buys Informatica MDM. The MDM ships survivorship-rule configuration. The data team configures most-recent-update wins as the global rule. The MDM picks email-C as the authoritative value because the loyalty platform update was most recent. Email-A and email-B drop from the canonical record.
Two months later the customer logs in to the ecommerce site to make a purchase. The customer enters email-B (the email the customer remembers using for online purchases). The ecommerce site does not find email-B in the canonical record. The ecommerce platform creates a new contact for email-B. The customer is now duplicated. The downstream attribution model splits the customer journey across two identities. The customer-experience metrics degrade.
The cause: record-level resolution dropped the accurate per-field data from the other sources. The fix: field-level resolution that treats each field independently with per-field per-source precedence rules. Email-survivorship rule changes from most- recent-update wins to ESP-source wins because the ESP captures the email the customer provides for marketing communications, which matches the email the customer uses for online purchases. Address- survivorship applies USPS-validated source wins. Purchase-amount survivorship applies POS-source wins. Tier-status survivorship applies loyalty-platform- source wins. Each field decides per its own rule; the canonical record carries the per-field-correct values.
What is in market — and what each category leaves to you
The MDM survivorship-rule engine is mature. The operator-specific per-field policy content tuned to the actual operator data estate is operator-side architecture.
Enterprise MDM — Informatica MDM, Reltio, Profisee, Stibo Systems, Tibco EBX, Semarchy, Ataccama, Talend Master Data Management
Excellent at the configurable survivorship-rule engine + most-recent-timestamp rules + manual- curate fields + record-level vs field-level resolution + entity-resolution algorithms. The operator-specific per-field per-source policy content tuned to which actual sources are authoritative for which actual fields at the operator data estate + per-vertical policy variants + per-franchisee policy variants are operator-side architecture above the MDM rule-engine layer.
Modern MDM — Reltio, Semarchy, Tamr (AI-first), Pretectum, Riversand
Strong at AI-assisted entity resolution + ML-based matching + cloud-native deployment + faster time- to-value than legacy enterprise MDM. The operator- specific per-field policy customization and per- vertical compliance integration sit above the AI-matching primitive.
Cloud-native data quality + MDM — Snowflake + dbt + custom, Databricks + Tamr, Google BigQuery + Dataplex
Strong at building MDM-style reconciliation in the cloud warehouse for operators with in-house data- engineering capacity. The field-level policy library + per-vertical policy variants + per- franchisee customization + audit trail are operator-side build above the warehouse primitive.
Specialized MDM — SAP Master Data Governance (SAP-ecosystem), Oracle Customer Hub (Oracle- ecosystem)
Strong at MDM integrated tightly with the dominant ERP ecosystem. The cross-ecosystem reconciliation for operators running mixed SAP + non-SAP + Oracle + non-Oracle source systems is operator-side build on top of the ecosystem-specific primitive.
The most-recent-update-wins global rule the data team configured once
The status quo at most multi-location operators running MDM. Global survivorship configured once at deployment + never tuned per field per source. The duplicates accumulate. The downstream attribution degrades. The data team blames the MDM. Field-level per-source precedence policy is the actual fix.
The pipeline, end to end
- Position in the 4-skill Parallel-Inputs → Validate → Resolve bundle. Parallel-Input 1 (custom-system-adapters) + Parallel- Input 2 (multi-source-ingestion) + Validate (per- vertical-schema-validation) + Resolve (this skill). NEW 15th canonical bundle architecture sub-type in arc — Parallel-Inputs → Validate → Resolve. 6th 4-skill same-agent bundle in arc + 4th 3to4 bundle growth instance.
- Field-level policy library structure. One policy entry per canonical-record field. Each entry encodes which source is authoritative under which condition (POS authoritative for purchase amount when present; ESP authoritative for email when most-recent-customer-provided event exists; loyalty-platform authoritative for tier status; USPS- validated source authoritative for address). The policy library is operator-tuned and version- controlled.
- Per-source precedence rules. Per-field per-source precedence with conditional logic. Most-recent-update wins applies where the field changes legitimately over time (preference attributes). Source-authoritative wins applies where one source owns the record-of-truth (POS for transactions). Manual-curate wins applies where operator stewards override programmatic rules.
- Per-vertical policy variants. Healthcare records under HIPAA need different reconciliation policies (changes to PHI fields require explicit consent state verification). Financial-services records under FINRA need explicit reviewer approval for changes to PII anchor fields. Cannabis records vary per state. Per-vertical policies layer on top of the base reconciliation rules.
- Per-franchisee policy variants. Some franchisees own their own CRM with field-level authority for franchise-specific data (per-franchisee customer service preferences captured by the franchisee staff). Per-franchisee precedence overrides sit in the customization layer.
- AI-generated data provenance handling. AI-generated fields carry provenance metadata (generating-agent ID + prompt version + brand-voice gate evaluation + compliance gate evaluation). Policy defaults to system-captured values when AI-generated conflicts with system-captured. Operators tune AI-vs- system precedence per field.
- Real-time vs batch reconciliation routing. High-stakes records (customer-facing identity changes, regulated-data updates, financial-product cross-sell attributes) reconcile in real time. Lower-stakes records (historical analytics records, batch import from secondary systems) reconcile in micro-batches. Same policy library; different runtime envelope.
- Conflict-resolution audit trail. Every Resolve decision stores the field reference, the contributing source values with timestamps, the applicable policy rule, the winning value, the actor (auto vs steward vs reviewer), and the resolution. Audit trail queryable per-field per-time period for data-quality investigation + regulator inquiry response.
- Escalation workflow for ambiguous conflicts. Conflicts that exceed policy-rule confidence (multiple authoritative sources disagree; policy rule absent for a new field; per-vertical compliance gate flags the conflict) escalate to the master-data steward review queue. Steward decisions feed policy-rule tuning per cycle.
- Integration with the Validate axis upstream. Validation failures at the per-vertical-schema- validation gate (upstream of Resolve) propagate as signals to the Resolve policy. A field that failed validation in one source but passed in another tightens the precedence toward the passing source.
- Integration with the downstream emit-change pipeline. Resolved records publish to the broader system via the customer-data-orchestration emit-change pipeline. Downstream consumers receive the resolved authoritative values. The resolution provenance propagates with the published record so consumers see which source contributed which field.
- Policy versioning + rollback. Policy versions follow semver-style numbering with effective dates. Major policy bumps require operator acknowledgement before the runtime Resolve picks up the new version. Rollback to a prior policy version available inside the retention window for emergency response.
- ROI measurement. CRM-duplicate rate pre vs post deployment. Per-field accuracy measured against periodic ground-truth audit. Downstream attribution accuracy improvement attributable to better field-level reconciliation. Marketing-campaign deliverability improvement (email bounce rate drops as the canonical email matches what the customer uses). Customer-experience metric improvement on customer-service interactions where the steward sees the correct field values.
Frequently asked
What is data reconciliation software?
Data reconciliation software resolves conflicts when multiple data sources disagree about the same entity. The same customer in three source systems may have three different email addresses or three different phone numbers or three different addresses. The reconciliation layer decides which source value wins for each field. Enterprise master data management (MDM) platforms include Informatica MDM, Reltio, Profisee, Stibo Systems, Tibco EBX, Semarchy, Ataccama, Talend Master Data Management. Modern MDM platforms include Reltio, Semarchy, Tamr (AI-first), Pretectum, Riversand. Cloud-native options include Snowflake plus dbt with custom rules, Databricks plus Tamr, and Google BigQuery plus Dataplex. The field-level per-source-precedence policy that knows POS is authoritative for purchase amount and CRM for email and loyalty platform for tier status at multi-location operator scale is operator-side architecture.
Why does record-level conflict resolution fail multi-location operators?
A multi-location operator has the same customer in 8-12 source systems. Each source captures different facets of the customer correctly. The POS captures the purchase amount and timestamp accurately. The CRM captures the email that the customer provided during the last campaign engagement. The loyalty platform captures the tier status from the last earned-points event. The booking system captures the most recent appointment slot. Record-level resolution picks one source as the winner and drops the data from the other sources. The chosen-source-of-truth pattern loses the field-level accuracy that the other sources captured better. Field-level resolution preserves the per-field accuracy by treating each field independently with a per-field per-source precedence rule.
How is this different from Informatica MDM, Reltio, Profisee, Stibo Systems, Tibco EBX, Semarchy, Ataccama, or Tamr?
Those platforms ship the MDM survivorship-rule primitive — configurable per-source precedence + per-field survivorship + most-recent-timestamp rules + manual-curate fields. They are excellent at the rule-engine layer. The operator-specific per-field policy content tuned to which actual sources are authoritative for which actual fields at the operator data estate, the per-vertical policy variants (healthcare records under HIPAA need different reconciliation policies than retail records), the per-franchisee policy variants (some franchisees own their own CRM with field-level authority for franchise-specific data), the integration with the per-vertical-schema-validation gate that runs upstream of Resolve, and the integration with the broader 4-skill Parallel-Inputs → Validate → Resolve bundle are operator-side architecture on top of the MDM primitive.
How does the 4-skill Parallel-Inputs → Validate → Resolve bundle work?
The master-record-canonicalization agent owns a 4-skill bundle. Parallel-Input 1 (custom-system-adapters connects to each per-source system via versioned adapter). Parallel-Input 2 (multi-source-ingestion orchestrates the parallel adapters with schema canonicalization and per-location attribution metadata). Validate (per-vertical-schema-validation evaluates every ingested row against HIPAA + FDA + FINRA + cannabis-state + PCI + GDPR + CCPA libraries before downstream consumption). Resolve (this skill — field-level conflict resolution decides per-field per-source precedence). The bundle is the NEW 15th canonical bundle architecture sub-type in arc (Parallel-Inputs → Validate → Resolve) — distinct from walk-in-phone-attribution Parallel-Inputs → Resolve → Forecast.
What is survivorship and how do you handle it?
Survivorship is the MDM term for which source value wins when multiple sources disagree. Survivorship rules tune per field per source per condition. Email survivorship at a multi-location operator might apply most-recent-update wins because the email-collecting CRM captures the customer-provided email correctly. Address survivorship might apply USPS-validated source wins because address validation depends on the validation service. Purchase amount survivorship applies POS-source wins because POS captures the transactional record-of-truth. Tier status survivorship applies loyalty-platform-source wins because the loyalty platform owns the tier computation. The survivorship rule library is part of the field-level conflict-resolution policy.
How do you handle conflict resolution for AI-generated data?
AI-generated data (review-response drafts, product descriptions, personalized email content) enters the master record as derived data alongside the human-authored and system-captured data. The reconciliation policy treats AI-generated fields differently from system-captured fields. AI-generated fields carry provenance metadata (generating-agent ID + prompt version + brand-voice gate evaluation + compliance gate evaluation). When the AI-generated value conflicts with a system-captured value (the AI-generated personalized greeting uses an outdated first name; the system-captured first name is current), the policy defaults to the system-captured value because the AI-generated value is downstream of the system-captured data. Operators tune the AI-vs-system precedence per field as needed.
Hire the agent that resolves field-level conflicts
The master-record-canonicalization agent owns the 4-skill Parallel-Inputs → Validate → Resolve bundle — custom-system-adapters + multi-source- ingestion + per-vertical-schema-validation + conflict- resolution policy — sitting on top of whichever enterprise MDM (Informatica MDM, Reltio, Profisee, Stibo Systems, Tibco EBX, Semarchy, Ataccama, Talend MDM), modern MDM (Tamr, Pretectum, Riversand), cloud- native data-quality (Snowflake + dbt, Databricks + Tamr, BigQuery + Dataplex), or ecosystem-specific MDM (SAP Master Data Governance, Oracle Customer Hub) you license downstream. Field-level per-source precedence policy + per-vertical policy variants + per-franchisee policy variants + AI-generated-data handling + real-time vs batch routing + audit trail + escalation workflow.
We scope on the call and send a private checkout link after.
Related reading: Multi-source ingestion · Per-vertical data validation · Customer data orchestration