EBX Matching, Survivorship and Golden Records | Part 5

Matching asks whether records may describe the same entity. Survivorship asks which values should represent that entity. These are different decisions and both require evidence. AI can assist with candidate discovery, but a similarity score must not quietly become an identity decision.

Audience, prerequisites and outcomes

For stewards, identity architects, quality engineers and EBX Match and Merge administrators. Complete Parts 1–4. For the product walkthrough, your environment needs a compatible, licensed EBX Match and Merge add-on; otherwise perform the policy exercise and steward review manually in the base model.

You will define deterministic and probabilistic signals, score candidates, configure a version-qualified matching policy, apply attribute-specific survivorship and validate golden-record lineage.

Product/version note: Match and Merge is a separately versioned add-on. Policy table names, algorithms and screens vary by release and configuration. The official 4.5.22 documentation cited here describes matching policies, fields, contexts and golden lifecycle; confirm compatibility with your EBX server and add-on before following UI steps.

The candidate set

The first three are strong candidates. The fourth is a near-name but different-email trap.

Match policy before algorithm

Define fields, normalization and evidence weights:

Example decision bands: ≥0.92 auto-link only when no contradictory decisive signal exists; 0.75–0.919 steward review; <0.75 no match. These numbers are workshop hypotheses, not vendor defaults. Calibrate them on labeled pairs and monitor false merges and missed matches.

Matching context matters. An organization and a person need different fields; a prospect and an employee may require different permitted attributes. Official add-on documentation describes optional matching contexts for this purpose.

Survivorship is attribute-specific

Do not choose one winning row. Define rules per attribute:

• display name: verified source, then steward-approved value;
• email: most recently verified non-null value;
• country: standardized value from validated address;
• loyalty tier: CRM authority, not “latest,” unless policy says otherwise;
• support sentiment: never promoted into canonical customer facts;
• product status: ERP authority by market, with commerce discrepancy alert.

Store the winning value, source record, rule version, decision time and approver. Preserve losing values as lineage, not duplicate canonical attributes.

Hands-on with EBX Match and Merge — expanded executable procedure

Match and Merge is a separately licensed/versioned add-on; screens, algorithms, datasets, and lifecycle behavior vary. Confirm compatibility with the installed EBX server and add-on before UI execution.

Actions: Record the EBX server, Match and Merge add-on, license, documentation version, operator, configuration dataset, and isolated child dataspace. Confirm the installed compatibility matrix before initialization. Initialize only the workshop configuration dataset by following the administrator guide for that exact add-on release. Expected result: the version-qualified add-on opens with an isolated configuration dataset. Validation: reopen the configuration and preserve a version record without secrets. Stop/recovery: if licensing, compatibility, or isolation is uncertain, stop UI work and complete the policy exercise manually; discard a partially initialized child dataspace rather than repairing shared configuration.

Actions: Create inactive/test-only policy customer-match-v1 for the workshop Customer table. Add normalized-email exact matching, name token/fuzzy support, and country blocking/context using only algorithms available in the installed release. Record paths, normalization, null behavior, weight, contradiction behavior, and separate contexts for materially different party types. Keep auto-merge disabled. Expected result: every signal resolves against all four synthetic rows and has an explicit purpose. Validation: preview field values and context selection record by record. Stop/recovery: disable the policy if a path/type/context is wrong; correct it as a new policy version before any run.

Actions: Validate and snapshot the four-row child dataspace, then run candidate generation in preview/non-merge mode. Capture run ID, policy version, time, candidate groups, overall score, and available field contributions. Confirm the first three Amina records are candidates and CRM:C-2040 retains the decisive different-email contradiction. Expected result: evidence is produced without golden records or source modification. Validation: compare pre/post row counts and confirm no merge links. Stop/recovery: if automatic consolidation occurs, stop, discard the child dataspace, disable auto-merge, and replay from the snapshot.

Actions: Configure survivorship separately for display name, email, country, and loyalty tier; encode authority, verification, recency, null, and tie behavior. Store winning source, losing values, rule version, decision time, and approver. Test a tie and null case. Expected result: the preview yields Amina Rahman, verified email, US, and CRM-authoritative Gold while retaining alternatives as lineage. Validation: reconcile every output value to its rule and source. Stop/recovery: do not consolidate if provenance is absent or an unauthorized source wins; revise and rerun under a new version.

Actions: Select only the first three source records, explicitly exclude CRM:C-2040 with the email-conflict rationale, consolidate in the child dataspace, and run dataset validation. Apply ordinary golden status only after validation; use definitive-golden only when the installed add-on semantics and approved lifecycle require final exclusion from future matching. Verify bidirectional source/pivot/golden links, take a snapshot, and export run evidence. Expected result: one traceable golden record, three linked sources, and one documented exclusion. Validation: reconstruct all values and links from evidence. Stop/recovery: do not promote invalid/incomplete results; follow the documented unmerge/lifecycle procedure or restore the child dataspace snapshot with an administrator.

Expected golden representation

{
  "master_id": "CUS-00017",
  "display_name": "Amina Rahman",
  "email": "amina@example.test",
  "country_code": "US",
  "loyalty_tier": "Gold",
  "governance_status": "APPROVED",
  "source_records": ["CRM:C-1007", "WEB:WEB-882", "ZD:ZD-441"],
  "policy_version": "customer-match-v1",
  "excluded_candidate": "CRM:C-2040"
}

The exact JSON is an outbound contract, not an EBX storage prescription.

AI-assisted matching—with guardrails

Embeddings can surface transliterations, reordered organization names or semantic address similarity. Use them to propose candidates, not to erase deterministic contradictions. Log model/version, input features, score and explanation. Never send restricted identity attributes to an unapproved external model. Maintain a non-AI fallback and continuously evaluate:

• pair precision and recall;
• false-merge rate (usually the costliest error);
• missed-match rate;
• review acceptance rate;
• performance by language, market and entity type;
• drift after source or model changes.

Exercise: adversarial identity review

Create six pairs: exact email/different names; same name/different email; transliterated name; shared household email; reused phone number; and changed address. Label truth before tuning. Run the policy, explain every disagreement and adjust rules only with an approved change record. Compare accuracy across groups—an overall average can hide systematic harm.

Validation checklist

• Not completed: Match and survivorship decisions are separate.
• Not completed: Thresholds were calibrated on labeled examples.
• Not completed: Decisive contradictions prevent automatic merge.
• Not completed: Survivorship varies by attribute and records provenance.
• Not completed: Merged source records remain traceable.
• Not completed: Excluded candidates retain rationale.
• Not completed: Golden lifecycle behavior is understood before “definitive” status.
• Not completed: AI suggestions are logged, evaluated and human-reviewable.
• Not completed: The original records can be reconstructed from evidence.

Failure modes

Name-only matching. Common names and cultural variation create false merges.

Highest score wins. Scores are policy evidence, not identity truth.

Most recent wins every attribute. A fresh, low-authority source can overwrite a governed value.

Deleting losers. You destroy lineage and make future unmerge/correction impossible.

Freezing golden forever. The official lifecycle allows golden records to participate in later matching unless configured otherwise; mastered identity must adapt to new evidence.

Unmeasured AI matching. A clever embedding demo without labeled evaluation is not a control.

Takeaway and next

A golden record earns trust through explainable identity evidence, attribute-specific survivorship and reversible lineage. Part 6 will turn these decisions into stewardship workflows, approvals and controlled change—not merely a batch result.

Sources

• EBX Match and Merge 4.5.22: Golden record lifecycle
• EBX Match and Merge 4.5.22: Matching policy documentation (PDF)
• TIBCO EBX 6.0.6: Dataspaces and snapshots