Skip to content
DMDQP AI Capability Hub

Explain an MDM Matching Rule

Explain an MDM Matching Rule

Context

MDM matching rules define how two entity records are determined to be the same real-world entity. Rules can be complex — combining attribute weights, confidence thresholds, and blocking strategies — and the logic is often expressed in system-specific configuration that is difficult to read without domain expertise. This prompt extracts a plain-language explanation from a rule configuration or description, covering what it matches on, what would trigger or block a match, and edge cases that could produce false positives or false negatives.

See also the MDM Matching Rule Draft prompt, which covers the reverse direction: turning a business requirement into a new matching rule.

The Prompt

Explain this MDM matching rule in plain language.
Describe: what it matches on, what conditions trigger a match vs. a no-match,
and any edge cases that might cause false positives or false negatives.


Matching rule configuration:
[PASTE RULE CONFIGURATION OR DESCRIPTION HERE]


System: [Reltio / MRHub]
Entity type: [CUSTOMER / PRODUCT / LOCATION / ...]

Usage Instructions

  1. Open build-cli in your terminal in the relevant project context.
  2. Copy the prompt above.
  3. Replace [PASTE RULE CONFIGURATION OR DESCRIPTION HERE] with the actual rule configuration — JSON, YAML, or a prose description of the rule logic.
  4. Fill in the system name (Reltio or MRHub) and the entity type.
  5. Review the explanation with your data steward to confirm accuracy before using it in documentation.

Example Output

The AI will produce an explanation such as:

This rule matches Customer records on email address (exact match, case-insensitive) as the primary key. If email is null or empty, it falls back to a combination of first name + last name + date of birth (all three must match, using fuzzy string comparison with a threshold of 85%). A match is confirmed when the combined confidence score exceeds 0.75.

False positive risks: Common names (John Smith) with the same date of birth could incorrectly merge distinct individuals. Email addresses shared by household members (family accounts) will merge records that should be separate.

False negative risks: Email typos or format differences (name@company.com vs name@company.co) will prevent email-key matching; the name/DOB fallback must then succeed.

Note: The AI cannot access your Reltio/MRHub configuration directly. Paste the relevant config or describe the rules in text. For new rules, treat the AI output as a starting point for discussion with a data steward — not a final configuration.