Skip to content
DMDQP AI Capability Hub

Draft a New MDM Matching Rule

Draft a New MDM Matching Rule

Context

Designing a new MDM matching rule requires balancing precision (no false merges) against recall (no missed duplicates). The rule must be expressed in terms of the attributes the system actually has, choose a confidence strategy, and account for common data quality issues in the available attributes. This prompt takes a business-level match requirement and produces a structured rule proposal, including an honest assessment of which attributes are risky to use as match keys.

See also the MDM Matching Rule Explain prompt, which covers the reverse direction: getting a plain-language explanation of an existing rule configuration.

The Prompt

I need to define a matching rule for [ENTITY TYPE] in [Reltio / MRHub].


Business requirement:
[DESCRIBE WHAT CONSTITUTES A MATCH IN BUSINESS TERMS — e.g.,
"Two customer records should be considered the same person if they share the same
email address, OR if they share the same first name, last name, and date of birth."]


Available attributes for matching: [LIST AVAILABLE ATTRIBUTES]


Please describe the matching logic, suggest a confidence threshold approach,
and flag any attributes that are risky to use as match keys (high cardinality,
frequently null, or commonly shared between different entities).

Usage Instructions

  1. Open build-cli in your terminal.
  2. Copy the prompt above.
  3. Replace [ENTITY TYPE] with the entity (Customer, Product, Location, etc.).
  4. Replace [DESCRIBE WHAT CONSTITUTES A MATCH IN BUSINESS TERMS] with the actual business rule in plain language — be as specific as possible.
  5. List the available attributes in the MDM system — include data type and any known null rates if you have them.
  6. Review the proposed rule with a data steward before implementing in Reltio/MRHub.

Example Output

The AI will produce a proposal such as:

Primary matching strategy — Email exact match: Use email_address (case-insensitive, trimmed) as the primary match key. Confidence contribution: 0.85. Risk: low for deterministic matching, but watch for shared household emails.

Secondary matching strategy — Name + Date of Birth composite: Use first_name (fuzzy, threshold 90%) + last_name (fuzzy, threshold 90%) + date_of_birth (exact). All three must score above threshold. Confidence contribution when all match: 0.70.

Recommended threshold: Confirm match at combined score ≥ 0.75; review queue at 0.50–0.74.

Risk flags: first_name has high null rate in legacy import (check with data engineer); date_of_birth is not reliably populated for B2B entity records.

Note: Treat the AI output as a starting point for discussion with a data steward — not a final configuration. False positive risks (merging distinct entities) are usually more serious than false negatives. Ask the AI to explicitly assess false positive risk.