Why AI Makes MDM Non-Negotiable | EBX Workshop Part 1

Generative AI makes data quality visible in a way dashboards rarely did. A dashboard can hide a duplicate customer inside an aggregate. A retrieval assistant may confidently expose both identities, quote the wrong contract tier, or recommend a discontinued product. The model did not create the contradiction; it amplified an unresolved identity problem.

This workshop treats master data management (MDM) as an operational control plane for AI—not a cleanup project. We will build a small but realistic customer-and-product domain in EBX, measure its quality, reconcile identities, publish governed records to consumers, and preserve evidence for every important decision. No production data is required.

Audience and prerequisites

This chapter is for data architects, stewards, governance leaders, analytics engineers and AI product owners. You should understand tables, keys and basic data-quality concepts. You need an EBX 6.x non-production environment, permission to use the Advanced perspective, and later chapters may require licensed Data Exchange and Match and Merge add-ons.

Version note: EBX installations differ by release, enabled add-ons, perspective configuration and administrator terminology. Menu labels below describe EBX 6.x concepts; verify them against your installed documentation before using them in production.

Learning outcomes

By the end, you can:

• explain how entity ambiguity becomes AI risk;
• distinguish source, mastered and golden records;
• define measurable acceptance criteria for an AI-ready domain;
• create an isolated workshop dataspace and dataset without affecting production;
• establish an evidence-based baseline.

The AI-ready master-data contract

An AI system needs more than accurate columns. It needs an entity contract:

1. Identity: one durable identifier for the business entity.
2. Meaning: governed definitions for fields and relationships.
3. Quality: declared rules, severity and accountable owners.
4. Provenance: where a value came from and when it changed.
5. Decision rights: who may propose, approve and publish changes.
6. Consumption policy: which records and attributes an AI workload may use.

These controls reduce retrieval collisions, leakage of restricted attributes, unstable training sets and irreproducible answers. MDM does not guarantee truthful AI, but it removes several avoidable ways of being wrong.

Synthetic case: Northstar Outfitters

Northstar sells outdoor equipment through commerce, stores and distributors. Start with these intentionally conflicting records:

Use .test addresses only. Never put personal or confidential data into the lab.

Workshop artifacts

Northstar EBX Workshop Kit

Everything required to reproduce Part 1 in an approved non-production EBX environment.

6 files

EBX 6.x · Synthetic data · 23 KB total

• northstar_master.xsdXSD schema · 20.0 KB

  Embedded semantic model for the Northstar workshop.

  Download ↓
• SourceSystem.csvCSV data · 277 B

  Five upstream-system definitions; import this first.

  Download ↓
• Customer.csvCSV data · 267 B

  Three deliberately conflicting customer candidates.

  Download ↓
• Product.csvCSV data · 267 B

  Three deliberately conflicting product candidates.

  Download ↓
• QualityObservation.csvCSV data · 938 B

  Six baseline quality-evidence records.

  Download ↓
• README.mdGuide · 1.4 KB

  Import order, corrected baseline, and safety guidance.

  Download ↓

Hands-on: establish the governed workspace

Complete these steps only in an EBX non-production environment. Menu labels can vary by EBX release and by the perspectives your administrator has enabled. Record any local naming differences in the workshop README before continuing.

Step 1 — Create the isolated workshop dataspace

1. Sign in to the EBX non-production environment with an account permitted to create child dataspaces.
2. Switch to the perspective that exposes Dataspaces or open the dataspace selector provided by your installation.
3. Select the approved non-production parent dataspace. Do not select a production, reference, or release dataspace.
4. Review the parent’s current snapshot or branch point and record its identifier and timestamp.
5. Choose the action to create a child dataspace.
6. Enter AIMDMWORKSHOP as the technical name and use a readable label such as AI MDM Workshop.
7. In the description, state that the dataspace contains synthetic training data and must never be merged into production.
8. Create the child and switch your session into it.
9. Confirm that the active-dataspace indicator shows AIMDMWORKSHOP before creating any model or data.

Expected result: AIMDMWORKSHOP appears beneath the approved non-production parent, and all subsequent changes are isolated inside it.

Validation: Open the dataspace comparison view. The child should initially show no workshop changes relative to its recorded parent snapshot.

Stop condition: If you cannot prove that the selected parent is non-production, or if the interface proposes an immediate merge, stop and ask the EBX administrator to confirm the lifecycle configuration.

Step 2 — Create the embedded semantic data model

1. While AIMDMWORKSHOP is active, open Data Models.
2. Choose Create data model and select an embedded or semantic model appropriate for the standard EBX dataspace lifecycle.
3. Set the technical name to northstar_master.
4. Add a readable label such as Northstar Master Data Model and describe its customer, product, source-system and quality-observation scope.
5. Confirm that relational mode is not selected for this workshop. The exercises rely on semantic-model capabilities and the dataspace lifecycle.
6. Assign the model to the workshop dataspace or repository location required by your EBX installation.
7. Save the initial model definition without publishing it yet.
8. Reopen the model and verify that its mode, technical name and location are correct.

Expected result: An unpublished embedded semantic model named northstar_master exists only in the workshop context.

Validation: The model editor should permit semantic schema construction and should not identify the model as relational.

Recovery: If the wrong model mode was chosen, remove the empty workshop model and recreate it before adding tables. Do not continue with a model whose lifecycle differs from the exercise.

Step 3 — Define the initial table skeleton and publish version 1

1. Open northstar_master in the model editor.
2. Create a table named Customer; add a technical primary key placeholder such as customer_id.
3. Create a table named Product; add a technical primary key placeholder such as product_id.
4. Create a table named SourceSystem; add a technical primary key such as sourcesystemid and reserve fields for the source name and authority scope.
5. Create a table named QualityObservation; add a technical key and reserve links to the observed entity, rule, result, severity and observation timestamp.
6. Use consistent labels, descriptions and naming conventions for all four tables. Do not load source data yet.
7. Run the model’s built-in validation and resolve every error. Record warnings that are intentionally deferred.
8. Review the generated table paths and keys so later workshop steps can refer to stable identifiers.
9. Create a model publication with a note such as Initial workshop skeleton.
10. Publish the model and record the exact publication version and timestamp.

The captured publication reports non-blocking default-strategy warnings for several strings. In this isolated synthetic lab, record why they are accepted. In a production design, return to the model and configure deliberate search or indexing strategies instead of normalizing the warning.

Expected result: The four tables are available from a successful first publication of northstar_master.

Validation: Reopen the published version and confirm that Customer, Product, SourceSystem and QualityObservation are present and that validation reports no blocking errors.

Design caution: These are intentionally minimal skeletons. Do not invent production-grade fields, matching rules or survivorship logic until the later modeling exercises establish their governance requirements.

Step 4 — Create the workshop dataset

1. Keep AIMDMWORKSHOP active and open Data.
2. Choose the action to create a dataset from a published data model.
3. Select the published northstar_master model, checking the version against the value captured in Step 3.
4. Enter northstar_lab as the dataset’s technical name and Northstar MDM Lab as its label.
5. Add a description stating that the dataset contains synthetic customer and product records for governed AI-readiness exercises.
6. Review the target dataspace shown by the creation dialog; it must be AIMDMWORKSHOP.
7. Create the dataset.
8. Open it and confirm that the four expected tables are visible.
9. Check that each table is empty before the synthetic records are loaded in a later exercise.

Expected result: Dataset northstarlab is bound to the recorded published version of northstarmaster inside the workshop dataspace.

Validation: From the dataset information or properties view, verify the model reference, active dataspace, creation timestamp and absence of production records.

Step 5 — Import the synthetic evidence in dependency order

1. Import SourceSystem.csv into /root/SourceSystem first so foreign-key references can resolve.
2. Import Customer.csv into /root/Customer.
3. Import Product.csv into /root/Product.
4. Import QualityObservation.csv into /root/QualityObservation.
5. Before each import, use EBX simulation or preview and verify the target, mappings, and proposed record operations.
6. Preserve the deliberately inconsistent source values; they are the evidence this workshop will govern.

Expected result: SourceSystem contains five records, Customer three, Product three, and QualityObservation six. Validation: Reconcile counts and values against the CSV files. Stop/recovery: Cancel any simulation that targets the wrong table or proposes an unexpected destructive operation; correct the mapping and simulate again.

Step 6 — Record governance and consumption controls

1. Create a governance entry for northstar_lab in the workshop README or your approved catalog.
2. Name one accountable domain owner for business decisions.
3. Name the customer and product data stewards responsible for definitions and quality exceptions.
4. State the purpose: a synthetic, non-production lab for MDM and AI-readiness training.
5. Record the environment and classification as non-production and synthetic.
6. List approved consumers, such as workshop participants and named test services.
7. State that production AI assistants, analytics pipelines and downstream operational systems are prohibited consumers.
8. Define a retention rule and a review or deletion date for the lab.
9. Record prohibited data classes, including real personal, confidential, credential and production-derived data.
10. Add the escalation contact and approval process for any requested scope change.

Expected result: Another authorized person can determine who owns the lab, why it exists, what it may contain, who may use it and when it must be reviewed or removed.

Validation: Ask a reviewer who did not create the lab to answer those five questions using only the governance entry. Any unanswered question is a documentation defect.

Step 7 — Capture the reproducibility anchor

1. Record the EBX environment or instance name without copying credentials or sensitive connection details.
2. Record the parent dataspace and the initial parent snapshot identifier from Step 1.
3. Record the child dataspace technical name AIMDMWORKSHOP.
4. Record the model name northstar_master, its first publication version and publication timestamp.
5. Record the dataset name northstar_lab and its creation timestamp.
6. Record the EBX release, enabled perspective and any add-ons relevant to the workshop.
7. Add the governance-entry location and the names or roles of the people who performed and reviewed the setup.
8. Capture evidence using identifiers and exported configuration where permitted; do not use screenshots containing confidential navigation, users or data.
9. Have a second participant verify each identifier directly in EBX.
10. Mark the anchor complete only after the recorded objects can be reopened and cross-checked.

Expected result: The workshop can be repeated or audited against a precise parent snapshot, model publication and dataset—not merely against someone’s memory of the setup.

Final checkpoint: Confirm that no production merge, production publication or real-data ingestion has occurred. If any has occurred, stop the workshop and follow the organization’s incident and rollback procedure.

EBX defines a dataset as data held according to a published data model; later model publications update associated datasets. Dataspaces isolate versions and can be compared and merged back to a parent. That pairing—model plus lifecycle boundary—is the foundation of the lab.

Baseline scorecard

Before fixing anything, calculate:

• completeness: populated required values / expected required values;
• validity: values passing declared rules / inspected values;
• uniqueness: distinct candidate identities / total records;
• consistency: records agreeing with controlled reference values / inspected records;
• freshness: records updated within the domain’s service level;
• traceability: values with source and timestamp / mastered values.

The baseline must distinguish observed evidence from assumptions. The corrected profile is:

Do not compress these results into one “data quality score.” Each denominator, rule, and normalization must remain visible. Loyalty agreement is unresolved—not “50% accurate”—and record-level provenance does not prove temporal lineage.

Governance and AI design questions

• May an assistant use a mastered email, or only a pseudonymous customer key?
• Does a low-confidence match enter retrieval automatically?
• Which source is authoritative for product status, and does authority vary by market?
• How will an AI answer cite the mastered entity version it used?
• What happens when a user exercises deletion or correction rights?

Write answers as policies that can be tested. “Use trusted data” is not a policy.

Validation checklist

• Not completed: Workshop changes are isolated in a child dataspace.
• Not completed: An initial snapshot and model version are recorded.
• Not completed: Synthetic records contain no real personal data.
• Not completed: Domain owner and stewards are named.
• Not completed: Six baseline quality dimensions are calculated.
• Not completed: AI consumers and restricted attributes are documented.
• Not completed: No production merge or publication has occurred.

Common failure modes

Starting with matching software. Without an identity policy, a score only automates ambiguity. Define the entity first.

Calling a consolidated record “truth.” A golden record is the best governed representation available at a point in time—not metaphysical truth.

Measuring only completeness. A fully populated false value can be more dangerous than a visible null.

Letting the AI read staging data. Landing and suspect zones exist precisely because their records are not ready for broad consumption.

Takeaway

AI raises the cost of unresolved identity, semantics and provenance. The answer is not merely cleaner rows; it is a governed entity lifecycle with explicit evidence and consumption controls.

Next

Part 2 turns this contract into an AI-ready EBX architecture: zones, dataspaces, permissions, model boundaries and publication interfaces.

Sources

• TIBCO EBX 6.0.6: Introduction to dataspaces
• TIBCO EBX 5.9.27: Creating a data model
• TIBCO EBX 6.2.0: Creating a dataset