Articles

Microsoft MDS to CluedIn: a technical migration guide for SQL Server, Fabric and Purview

CluedIn — Wed, 16 Sep 2026 16:32:20 GMT

MDS remains supported in SQL Server 2022 and earlier releases. Existing installations do not suddenly stop working because SQL Server 2025 exists.

But Microsoft has removed Master Data Services from SQL Server 2025. That changes the question for architects from "How do we upgrade MDS?" to "How do we get the data, rules, hierarchies, integrations and consumers out of MDS without recreating the same technical debt somewhere else?"

What this guide covers

The migration mechanics, the MDS-to-CluedIn concept mapping, where Fabric and Purview fit, and what Microsoft and other third parties have actually published about CluedIn.

The aim is not to produce another generic "modernise your data" article. It is to separate what is technically useful from what is merely marketing shorthand.

First, what does Microsoft actually say?

Microsoft's current position on Master Data Services is straightforward.

Microsoft Learn

"MDS is removed in SQL Server 2025 (17.x)."

Source: Microsoft Learn

Microsoft also confirms that MDS remains supported in SQL Server 2022 and earlier versions.

That distinction is important. There is time to migrate properly. There is considerably less justification for designing new architecture around MDS.

And where does CluedIn appear?

This is where the history becomes useful. Microsoft's Architecture Center repository contains a reference architecture titled:

Historical Microsoft architecture

Migrate master data services to Azure with CluedIn and Azure Purview

View the MicrosoftDocs architecture source: MicrosoftDocs Architecture Center repository

The live Architecture Center has evolved since then, but the original MicrosoftDocs architecture metadata remains publicly visible. That matters because it establishes that the CluedIn/MDS relationship did not appear only after Microsoft removed MDS from SQL Server 2025.

A Microsoft-hosted presentation from 2022, End-to-end Data Estate Lineage with Purview and CluedIn, also includes that same MDS migration architecture in its resource material.

Source: Microsoft-hosted presentation

The Microsoft references did not disappear with the old MDS architecture

The current material has moved on from MDS migration specifically and into the wider MDM architecture. Microsoft Learn currently has a dedicated page titled Microsoft Purview and CluedIn integration for master data management.

Current Microsoft Learn

Microsoft describes the CluedIn architecture as providing a "coherent, consistent, end-to-end Master Data Management (MDM) solution."

Source: Microsoft Learn

That page covers ingestion, data quality, mastering, governance, graph relationships and downstream data delivery.

Microsoft also publishes a current guided project for building a complete master data management and data governance stack using Microsoft Purview and CluedIn.

The training walks through Azure Data Factory, CluedIn ingestion, streaming data back to ADLS, deduplication, cleaning, enrichment and Purview scanning.

Source: Microsoft Learn guided project

The evidence chain

MDS migration architecture → Azure and Purview MDM architecture → current Microsoft MDM training

The technology has moved forward. The architectural role has remained recognisable.

What does an MDS migration actually involve?

This is where migration projects often underestimate the problem. MDS is rarely just a database.

MDS component	What may depend on it
Models	Domain boundaries and organisational ownership
Entities	Master data objects
Members	Business records
Attributes	Data definitions and controlled values
Domain-based attributes	Relationships between entities
Business rules	Validation, defaults and data acceptance
Hierarchies	Operational and reporting structures
Subscription views	Downstream integration contracts
Change tracking	Incremental integration
Excel Add-in	Manual stewardship processes
Security	Who can view and modify domains
Transaction history	Audit and investigation

The dependencies are more important than the tables.

An MDS migration should start by identifying what actually relies on MDS, not by assuming every object deserves to be recreated.

Three technical paths from MDS into CluedIn

There is no requirement to switch MDS off before CluedIn comes online.

Connect CluedIn directly to MDS

CluedIn has a dedicated Microsoft SQL Server MDS integration.

There is a practical technical issue to handle: MDS uses Windows authentication by default, while the CluedIn crawler runtime does not rely on Windows authentication in the same way.

CluedIn therefore documents direct connectivity where the network path permits it, and Azure Relay where an on-premises MDS server does not have a routable path to CluedIn.

On-premises MDS → Azure Relay → CluedIn

Useful when coexistence is required before MDS is retired.

Treat existing SQL outputs as migration contracts

Many mature MDS implementations already publish stable subscription views.

If those views are understood and trusted, they can provide a useful migration surface without forcing the team to reproduce the entire MDS model first.

The caution is obvious: a beautifully simple subscription view can hide years of assumptions and transformation logic underneath it.

Use both

For larger estates, this is often the sensible route.

Connect directly to MDS first to establish parity, identity and downstream publishing. At the same time, begin replacing the dependency on MDS with cleaner ingestion from original source systems or curated upstream datasets.

MDS disappears from the middle only after the replacement path has earned confidence.

Hybrid migration

Phase 1: Source systems → MDS → CluedIn → Consumers

Phase 2: Source systems → CluedIn → Consumers

How MDS concepts map into CluedIn

Some concepts map cleanly. Others should change.

Microsoft MDS	CluedIn approach
Model	Data model scope across Business Domains
Entity	Business Domain
Member	Mastered record
Attribute	Vocabulary Key
Domain-based attribute	Relationship between Business Domains
Business rules	Validation, quality, survivorship and publishing logic
Hierarchies	Graph relationships and controlled classification structures
Validation issues	Quality exceptions and failed checks
Subscription views	Streams and Export Targets
Change tracking	Event-log Streams
Data steward	Data steward / data owner with increased focus on exceptions and policy

Technical mapping: CluedIn MDS migration playbook

Do not copy MDS business rules line for line

An MDS business rule can do several different jobs.

It might validate a value. It might set a default. It might determine whether a record is valid enough to publish. It might trigger something operational.

Years later, all of those behaviours can be buried inside the same rule estate.

The business requirement should survive. The implementation does not always need to.

In CluedIn, validation, data quality, survivorship, workflow and publishing logic can be separated into the controls that actually own those responsibilities. That is more useful than recreating old coupling because "that is how MDS did it."

Subscription views deserve special treatment

In many MDS environments, subscription views are where the real operational dependency lives.

Finance pulls one.
The warehouse loads another.
A CRM integration depends on a third.
Someone has an Excel workbook connected to a fourth.

That is why CluedIn's adoption guidance recommends starting with consumers and contracts rather than attempting to perfect the whole model first. In CluedIn, mastered data is typically distributed using Streams and Export Targets.

Synchronized streams

Maintain a downstream representation of mastered data.

Event-log streams

Emit create, update and delete events for event-driven consumers.

A useful migration test:

Can the replacement platform produce the data this consumer requires, with the same or better reliability, semantics and auditability?

What happens to hierarchies?

Do not flatten them because it makes migration easier. Parent-child structures, product hierarchies, customer ownership structures and organisational relationships often contain genuine business meaning.

CluedIn's graph-native model treats relationships as first-class elements rather than forcing all that context back into denormalised tables.

Supplier → Material → Product → Plant → Region

Relationships can provide context for matching, governance and agentic data operations.

What about the MDS Excel experience?

This deserves attention because many people experience MDS through Excel rather than through architecture diagrams.

CluedIn's technical guidance does not assume every manual maintenance process should simply be reproduced. Modern stewardship may use forms, governed workflows, application interfaces, controlled ingestion patterns or Power Platform experiences depending on the use case.

The steward's role changes too. Instead of becoming the person through whom every correction must pass, stewardship increasingly becomes exception handling, approval, policy definition and oversight.

Where Microsoft Fabric fits

Fabric does not turn into MDS because MDS disappeared. A solved Microsoft Fabric Community discussion from 2025 made the architectural point succinctly: Fabric does not contain a built-in replacement for legacy Master Data Services.

Community source: Microsoft Fabric Community

That is community guidance rather than Microsoft product documentation, but the distinction is technically useful. Fabric is extremely capable at data engineering, analytics and AI workloads. Master Data Management still has to deal with identity, mastering, relationships, survivorship, quality, stewardship and controlled distribution.

Operational systems
↓
CluedIn: identity, mastering, quality, relationships and governed operations
↓
Fabric: data engineering, analytics, AI and consumption

And where does Purview fit?

Purview is equally important, but for a different reason. It is not simply "new MDS". Microsoft's current Learn architecture documents Purview and CluedIn working together across governance, lineage and operational MDM.

Microsoft Purview

Governance, discovery, lineage and understanding of the data estate.

CluedIn

Operational mastering, entity-level quality, matching, relationships, enrichment and governed data operations.

A practical migration sequence

A complicated MDS estate becomes much less frightening when the unit of migration is a consumer contract rather than the entire platform.

1. Inventory the MDS estate

Inventory dependencies, not just objects. Find the consumers, rules, hierarchies, identities and manual processes that still matter.

2. Pick one meaningful domain

Customer, Product or Supplier will usually expose more useful migration issues than a harmless lookup table.

3. Establish connectivity

Use direct MDS integration, Azure Relay or an existing SQL contract depending on the topology.

4. Preserve identity first

Establish business keys and identifiers before polishing every attribute. A clean record with the wrong identity is still the wrong record.

5. Translate the important rules

Separate validation, quality, survivorship and publishing concerns instead of reproducing legacy coupling unnecessarily.

6. Publish early

Create the first Stream and Export Target before declaring the mastering model "finished".

7. Dual run

Publish the new contract alongside the current MDS output. Compare, investigate differences and repeat until the behaviour is understood.

8. Move one consumer

Not the whole enterprise. One consumer. Then repeat.

The 90-day version

CluedIn's adoption playbook proposes a useful shape for proving the migration early.

DAYS 0–30

Prove one domain

Ingest one domain and prove one consumer contract end to end.

DAYS 31–60

Improve mastering

Improve matching and survivorship, then introduce a second consumer.

DAYS 61–90

Dual run and cut over

Reconcile outputs and move the first consumer away from MDS.

So, is CluedIn actually recognised outside CluedIn for this?

Yes. The important thing is to describe the evidence accurately.

Current Microsoft documentation

Microsoft Learn documents a complete CluedIn MDM architecture with Purview.

It also publishes a hands-on guided project using Purview, Azure Data Factory and CluedIn.

Historical Microsoft architecture

Microsoft's Architecture Center repository contains an explicit MDS-to-CluedIn migration architecture.

Microsoft's own Purview and CluedIn webinar also referenced that architecture.

Historical Microsoft Q&A

Microsoft employees previously named CluedIn among third-party MDM options where organisations required alternatives to MDS.

These are historical Q&A responses, not current Microsoft product policy.

Microsoft Q&A example

Microsoft Fabric Community

A solved Fabric Community discussion from 2025 points to CluedIn in the context of replacing legacy MDS.

Community content is useful supporting evidence, but it should not be presented as official Microsoft product documentation.

Independent research

Info-Tech highlights CluedIn's graph architecture, AI integration and strong Microsoft Azure alignment.

Its technology note says CluedIn "may be a good choice for organizations with strategic reliance on Microsoft Azure cloud."

Source: SoftwareReviews / Info-Tech

Independent comparison signal

Gartner Peer Insights maintains a direct comparison page for CluedIn and Microsoft MDS (Legacy).

This is not an analyst endorsement. It is an independent signal that the two products appear in a directly comparable MDM buyer context.

Gartner Peer Insights comparison

What this evidence does not mean

It does not mean Microsoft has designated one universal successor to Master Data Services. It has not. It does not mean every MDS deployment requires an enterprise MDM platform. Some do not. And it does not mean a historical Azure reference architecture should be treated as the current implementation guide for CluedIn in 2026.

What the evidence does establish is a long-standing, documented architectural relationship between CluedIn and Microsoft around MDM and MDS migration.

Current CluedIn documentation should be used for implementation. The older Microsoft material provides provenance.

The migration is finished when MDS is no longer a dependency

Not when all the records have been copied. MDS has not really been retired if:

A nightly job still reads one subscription view
Finance still maintains a hierarchy through an old process
An undocumented Excel workbook still depends on it
Change notifications still originate there
An application still expects an MDS-generated identifier
Nobody knows whether an old business-rule job can safely be switched off

The cleanest migration is not the one that moves the largest number of objects.

It is the one that leaves no unexplained dependencies behind.

Planning the technical move from MDS?

Start with the architecture you actually have.

Bring the important subscription views, the rules nobody wants to touch, the consumer dependencies and the current MDS topology. Then work out what deserves to survive, what needs to change and what can finally be retired.

Explore MDS migration with CluedIn Read the technical migration playbook

Best Microsoft MDS Alternatives 2026

CluedIn — Wed, 16 Sep 2026 09:45:59 GMT

Microsoft removed MDS from SQL Server 2025 while continuing to support it in SQL Server 2022 and earlier releases. If you run MDS today, that leaves you with something more interesting than an upgrade problem.

You now have to decide what kind of Master Data Management you actually want next.

Before making a shortlist

Do not start by asking which platform looks most like MDS.

Start by deciding which parts of MDS are genuinely valuable, which parts are technical baggage, and what your data architecture needs to do over the next five to ten years.

First things first, there is no direct Microsoft successor to MDS

Microsoft MDS Replacement After SQL Server 2025 | CluedIn

CluedIn — Tue, 15 Sep 2026 15:09:30 GMT

Microsoft Master Data Services has been removed from SQL Server 2025. That does not mean existing MDS implementations suddenly stop working. Microsoft continues to support MDS in SQL Server 2022 and earlier versions.

But it does mean organisations relying on MDS now have a clear architecture decision to make: what replaces it, and how do you move without turning years of master data logic into a high-risk migration project?

Quick answer

Is Microsoft MDS discontinued?

Master Data Services is no longer included in SQL Server 2025. Microsoft continues to support MDS in SQL Server 2022 and earlier versions.

So there is no immediate shutdown. But there is now a clear ceiling for organisations planning future SQL Server upgrades or wider data platform modernisation.

What has actually changed?

MDS has traditionally been used to define and manage models, entities, attributes, members, hierarchies, business rules and mastered outputs. Microsoft describes an MDS model as the highest level of organisation for master data, containing entities, attributes, hierarchies and collections. That model has served many organisations well.

The issue is not that MDS suddenly stopped being useful. It is that it no longer has a place in Microsoft's forward SQL Server platform.

The bigger question

Should you simply recreate MDS somewhere else, or use this as an opportunity to modernise Master Data Management properly?

What are the options for organisations still using MDS?

From AI Assistance to AI Action: What’s Coming Next to CluedIn Agentic MDM

CluedIn — Tue, 08 Sep 2026 11:00:20 GMT

CluedIn is introducing a significant set of new capabilities across AI Agents, data enrichment, the Global Data Model and Topology Explorer.

Each enhancement solves a specific product challenge. Together, they support a bigger change in how CluedIn helps enterprises manage data, moving from AI that waits for individual instructions towards AI that can work proactively towards a defined outcome.

From helping people manage data to actively helping manage the data itself.

This does not mean removing people, policies or governance from the process. It means reducing the need for a person to identify, initiate and supervise every individual step.

Give an AI Agent an objective, not just another prompt

The redesigned CluedIn AI Agent experience will support proactive Agents and long-running work that may continue for minutes or hours.

Instead of asking an Agent to complete one isolated task, users will increasingly be able to give it a broader objective, such as:

Improve the quality of this customer domain.
Investigate why these records are failing quality rules.
Enrich incomplete supplier records.
Investigate and resolve suspected duplicates within defined governance rules.

The Agent can then work through multiple steps, use the context available to it, take permitted actions and bring a person back into the process when judgement or approval is required.

Agents will also be able to track the work they perform and the results of their actions. Over time, those outcomes can provide useful context for approaching similar work. Support for Model Context Protocol, or MCP, will also allow CluedIn Agents to interact with external tools and services as part of a wider enterprise AI ecosystem.

Do not ask the AI whether it worked. Measure it.

An AI model can make a change and produce a convincing explanation. That is not proof that the data improved.

CluedIn will combine AI-driven action with independent, deterministic data quality measurement. This makes it possible to assess whether completeness increased, validity improved, duplicate rates fell or the quality of a domain moved in the right direction.

Identify → Reason → Act → Measure → Improve

This creates an objective scorecard for Agent actions. The Agent can reason and act, but CluedIn can independently determine whether the intended result was achieved.

More intelligent enrichment for messy enterprise data

Enterprise enrichment is rarely a simple exchange of one internal record for one external record. Company names vary. Addresses change. Legal entities multiply. Enrichment providers may return historical records, branches, subsidiaries or several plausible matches.

CluedIn is improving enrichment with AI-assisted fuzzy matching, helping identify likely external records even when names, addresses, abbreviations, formatting or identifiers do not align perfectly.

New multi-record matching capabilities will also help CluedIn work with multiple related responses rather than assuming the first result is the right one. The aim is higher enrichment coverage and more accurate matching, while handling the ambiguity that appears in real enterprise data.

The hard part of enrichment is not finding more data. It is knowing which data belongs to whom.

A Global Data Model with more meaning and context

The CluedIn Global Data Model is also evolving with new search, filtering, semantic model capabilities and synchronisation with Microsoft Fabric IQ.

Search and filtering will make larger enterprise models easier to navigate. The bigger strategic change is the growing role of the model as a semantic representation of the business.

AI needs more than access to tables, columns and values. It needs to understand what an entity represents, how it relates to other entities and what those relationships mean. Customers, products, suppliers, assets, locations and legal entities do not exist as isolated records. Together, they form a map of the enterprise.

The Global Data Model can provide this context to CluedIn AI capabilities and, through Fabric IQ synchronisation, help make governed enterprise context available within Microsoft’s wider data and AI ecosystem.

Topology Explorer: from seeing change to understanding it

Enterprise data estates never stand still. Sources, mappings, schemas, relationships and properties change continuously. Finding the change that caused a later issue can mean manually comparing complex technical representations across months of history.

The new CluedIn Topology Explorer is designed to work across thousands of historical versions, with improved ways to explore how the topology and model have evolved.

AI-generated explanations will help users investigate questions such as:

What changed between these versions?
Which entities and relationships were affected?
When was this relationship introduced?
What changed before this issue appeared?

For data architects, engineers, governance teams, administrators and auditors, this changes the question from “show me the topology” to “help me understand what happened”.

One product direction, not four isolated features

These capabilities are connected. The Global Data Model provides semantic context. Data quality and topology help CluedIn observe the state of the data estate. AI Agents reason about what needs to happen. Agents and enrichment capabilities perform governed work. Deterministic metrics measure the result. Previous outcomes can then become context for future work.

The Agentic Data Management loop

Understand → Observe → Reason → Act → Measure → Learn

People remain in control of the policies, permissions, approval points and acceptable level of autonomy. The aim is not blind automation. It is useful, explainable and measurable action within clear enterprise boundaries.

This is the direction CluedIn is building towards: a platform that can increasingly understand the state of enterprise data, identify what needs attention, take governed action and prove whether that action improved the result.

From AI assistance to AI action.

Explore Agentic Master Data Management

See how CluedIn combines AI Agents, graph-native context, data quality and governance to help enterprises build trusted, AI-ready data.

Explore the CluedIn platform

When Should You Merge Two Customer Records?

CluedIn — Tue, 11 Aug 2026 10:51:23 GMT

7 Things to Know About MDM Remediation Workflows

CluedIn — Tue, 28 Jul 2026 14:30:32 GMT

Enterprise master data management platforms promise clean, governed data. The reality? Data teams spend most of their time chasing errors, reconciling duplicates, and manually fixing records one at a time. CluedIn helps enterprises address this challenge through automated data remediation workflows that turn fragmented, inconsistent data into trusted master data at scale.

Why Does Graph-Native MDM Work Better for Complex Enterprise Data?

CluedIn — Mon, 27 Jul 2026 14:08:51 GMT

Direct answer

Graph-native Master Data Management works well for complex enterprise data because it treats entities, relationships, lineage and governance context as connected parts of the same operational model. This gives data teams more context for matching, stewardship, auditability and governed AI-agent decisions.

The central idea

Graph-native MDM does not merely store relationships more efficiently. It turns relationships into operational context for matching, governance, lineage and AI agents.

What is graph-native Master Data Management?

Graph-native MDM represents master data as connected entities and relationships rather than treating it primarily as rows distributed across rigid tables.

Customers Products Suppliers Assets Locations Legal entities

Relationships are part of the operational model and can directly influence matching, data quality, governance, ownership, workflow, auditability and agent decisions.

Why is enterprise master data inherently connected?

A master record rarely exists in isolation. A supplier may connect to products, certifications, factories, contracts, risk classifications and parent companies. A customer may connect to accounts, locations, contacts, products, consent and legal entities.

The important point Identity and meaning often depend on the connections around the entity—not only the values stored on the record itself.

Relational databases vs graph databases

Relational model

Tables and predefined schemas
Primary and foreign keys
Link tables and joins
Strong fit for stable transactional systems
Relationships must usually be designed in advance

Graph model

Nodes, edges and properties
Relationships are first-class data
Connections can carry meaning
Strong fit for evolving and interconnected data
New relationships can be introduced more flexibly

Why can rigid canonical models slow MDM programmes?

Traditional programmes often begin by designing a complete canonical model before useful work can start. Teams must agree fields, identifiers, relationships, source mappings and survivorship logic in advance.

A graph-native approach can preserve source records as they arrive, connect them to source and relationship context and allow the mastered model to evolve as the organisation learns more.

Graph-native MDM reduces rigid upfront modelling. It does not remove the need for semantics, governance or mastered entity definitions.

Does graph-native MDM eliminate upfront modelling?

No. Enterprises still need to define entities, meaningful relationships, trusted sources, governed attributes, policies, ownership and publishing outputs.

Ingest source records
Preserve their original structure
Identify entities and relationships
Explore recurring patterns
Define mastered concepts
Apply governance
Refine the model as evidence improves

How does graph context improve entity resolution?

Traditional matching compares names, addresses, emails, telephone numbers and identifiers. Graph context adds relationships, hierarchies, source trust, lineage and historical decisions.

That extra context can prevent false merges and identify legitimate matches that attribute similarity alone may miss.

Example: preventing a false supplier merge

Two suppliers may have nearly identical names, the same postcode and similar contact details.

The graph may show that they have different legal identifiers, different parent organisations, separate contracts and different regulated materials. That evidence may prevent an incorrect merge.

Example: confirming a difficult customer match

Two customer records may have different names, different addresses and no shared local identifier.

The graph may reveal a previous legal name, a shared registration number, transferred contracts and a common parent organisation. That connected evidence may support a match.

What does record-level entity resolution mean?

Each source record may contribute different evidence, such as a legal identifier, billing location, historic name, parent relationship, contract or ownership link.

A graph-native platform can retain each record and connect it to the mastered entity, allowing teams to inspect which records contributed, which relationships supported the match and which source supplied each mastered value.

Why are relationships important for golden records?

A golden record is not only a flat collection of preferred attributes. It is a trusted entity within a wider business network.

Parent organisation Approved products Operating locations Contracts Risk classifications Source lineage

How does graph-native MDM improve governance?

Attribute-level rules remain important, but graph-native governance can also evaluate relationships and dependencies.

A supplier is linked to more than one legal parent.

A customer is connected to conflicting consent records.

A product is supplied from a restricted region.

A sensitive dataset is connected to an unauthorised downstream consumer.

What is relationship-aware governance?

Relationship-aware governance applies policy based on the connected context around an entity.

Example: every supplier providing regulated materials to a European business unit must have an approved risk assessment and a current certification.

How does a graph improve lineage and auditability?

A mastered value can remain connected to its source record, source system, transformation, matching decision, survivorship rule, approving user or agent and downstream target.

This allows teams to inspect the path that created the current record instead of reconstructing it from disconnected logs.

Why does graph context matter for AI agents?

A responsible data-management agent may need to know which sources are trusted, how entities are related, who owns the domain, which policy applies, whether the data is sensitive and which systems may be affected.

The graph becomes the operational context layer for the agent.

Is a knowledge graph the same as a graph database?

No. A graph database is a storage and query technology. A knowledge graph adds enterprise meaning, semantics, trust, lineage, policy and governance context.

The value comes not simply from storing nodes and edges, but from giving them business meaning.

Does graph-native MDM reduce stewardship effort?

It can reduce effort by bringing more evidence together and allowing agents to assist with relationship discovery, candidate grouping, conflict detection, evidence gathering and recommendation preparation.

The steward still makes the decision where policy or risk requires it. The time spent assembling the evidence can be reduced.

How does graph-native MDM support changing data estates?

New entity and relationship types can be added without restructuring every existing table.

An organisation may begin with suppliers, products and locations, then later add certifications, risk assessments, carbon measurements and regulatory restrictions while preserving existing context.

Does graph-native mean schema-free?

No. Enterprise MDM still requires entity definitions, relationship definitions, ownership, quality rules, trust policies, access control and publishing contracts.

The advantage is not the absence of structure. It is the ability to add and refine structure without forcing every source into one rigid model first.

When is relational MDM still appropriate?

The domain is highly structured
Relationships are limited and stable
Source systems are few
Identifiers are consistent
Data models change infrequently
Batch processing meets the requirement

When does graph-native MDM become more valuable?

Data comes from many heterogeneous sources
Relationships influence identity
Hierarchies change frequently
Source confidence varies
Governance depends on connected context
AI agents need relationship and lineage context
New use cases must be introduced quickly

How should enterprises evaluate graph-native MDM?

Test resolution Use conflicting attributes, shared addresses, missing identifiers and complex hierarchies.

Test governance Create policies that depend on suppliers, products, regions, owners or consumers.

Test lineage Ask why records were matched, which values survived and where data was published.

Test change Add a new source, entity or relationship and measure the modelling effort.

CluedIn perspective

How does CluedIn use graph-native architecture?

A persistent enterprise knowledge graph connects sources, mastered entities, relationships, lineage and policies
Entity resolution combines attribute similarity with relationship and source-trust evidence
Golden records remain connected to contributing source records and business relationships
Governance policies can consider the context surrounding an entity
Governed AI agents use graph context to investigate and prepare decisions
Microsoft Fabric and Microsoft Purview integrations support analytics, AI and governance use cases

Explore the CluedIn platform CluedIn for Microsoft Fabric

What should buyers ask a graph-native MDM vendor?

Are relationships stored as first-class data?
Can source records remain connected to mastered entities?
Can relationship evidence influence matching?
Can the platform explain why records were linked or merged?
Can policies operate on relationships?
Can lineage be traced to source-record and attribute level?
Can new relationship types be added without redesigning the entire model?
Can agents use graph context during decisions?
How are entity and relationship semantics governed?
How does the graph publish trusted data downstream?

The graph is the context, not just the storage layer

Graph-native MDM is valuable because it turns relationships into operational context for entity resolution, golden records, governance, lineage, stewardship and AI-agent decisions.

The result is a more contextual way to determine what data means, why it should be trusted and how it should be governed.

See graph-native MDM in action

FAQs about graph-native MDM

What is graph-native Master Data Management?

Graph-native MDM represents master data as connected entities, source records and relationships, making context available for matching, governance, lineage and data-quality decisions.

How is graph-native MDM different from relational MDM?

Relational MDM primarily organises data in predefined tables and keys. Graph-native MDM treats entities and relationships as first-class, queryable elements.

Does graph-native MDM eliminate data modelling?

No. Enterprises still need entity definitions, semantics, ownership, policies and publishing models. The difference is that the structure can evolve more iteratively.

How does a graph improve entity resolution?

It adds evidence from relationships, hierarchies, lineage, source trust and historical decisions alongside traditional attribute matching.

Why are relationships important for golden records?

A trusted entity includes both preferred attributes and its connections to parent organisations, suppliers, products, locations, contracts and sources.

Can graph-native MDM improve governance?

Yes. Governance policies can consider relationships and dependencies, not only the fields stored on a record.

How does a graph support lineage?

It connects mastered values and entities to source records, transformations, rules, approvals and downstream destinations.

Is a knowledge graph the same as a graph database?

No. A graph database is a technology. A knowledge graph adds business meaning, semantics, trust, lineage, policy and governance context.

Why do AI agents benefit from a knowledge graph?

Agents can use relationships, source trust, ownership, policies, lineage and previous decisions to make more contextual and explainable recommendations.

When should an enterprise consider graph-native MDM?

It is most valuable when data comes from many heterogeneous systems, relationships influence identity, governance depends on context and the model changes frequently.

Agentic MDM vs Traditional MDM: Which Operating Model Reduces Data Stewardship?

CluedIn — Mon, 27 Jul 2026 13:39:04 GMT

Direct answer

Traditional MDM is usually queue-centric. Agentic MDM is outcome-centric. Traditional MDM relies more heavily on predefined rules, scheduled processing and human exception queues. Agentic MDM gives governed AI agents responsibility for inspecting data, gathering evidence, recommending actions, performing authorised low-risk work and escalating cases that require human judgement.

Key takeaways

Traditional MDM remains useful Agents do not replace core MDM Rules still matter Governance applies to agents Humans retain accountability Modernisation can be progressive

What is traditional Master Data Management?

Traditional Master Data Management consolidates important business entities from multiple systems and creates trusted master records.

Data is ingested from source systems
Validation and standardisation rules are applied
Matching logic identifies possible duplicates
Survivorship rules select preferred values
Golden records are created
Exceptions are sent to data stewards
Approved records are distributed downstream

What is Agentic Master Data Management?

Agentic Master Data Management adds governed AI agents to the work of resolving, improving and governing master data.

Example agent objectiveMonitor supplier records for duplicate identities, gather evidence from approved sources, recommend appropriate resolution and escalate cases where ownership or legal identifiers conflict.

The fundamental difference: queues versus outcomes

Traditional MDM

A rule identifies an issue, the issue enters a queue and a person investigates, interprets policy and makes the decision.

Agentic MDM

A governed agent is given an outcome, performs the repetitive investigation and escalates only where evidence, policy or risk requires human judgement.

Agentic MDM vs traditional MDM at a glance

Area	Traditional MDM	Agentic MDM
Operating model	Rules, batches and exception queues	Governed agents pursuing defined outcomes
Primary unit of work	Record or exception	Policy, outcome and exception
Matching	Configured deterministic and probabilistic logic	Rules plus relationship, trust and agent-supported evidence
Stewardship	Humans investigate most exceptions	Agents investigate and prepare; humans handle material exceptions
Governance	Workflows govern human activity	Governance applies to human and agent activity
Context	Attributes and configured reference data	Attributes, relationships, lineage, trust, policy and history
Scaling model	More exceptions often require more people	More routine work can be absorbed by agents

Does Agentic MDM replace traditional MDM capabilities?

No. A credible Agentic MDM platform still requires entity resolution, golden records, survivorship, data quality, governance, stewardship, lineage and trusted publishing.

Agentic MDM changes how established MDM capabilities are operated. It does not remove the need for them.

How does the stewardship model differ?

Traditional stewardship

Review match candidates
Compare source records
Correct values
Search for evidence
Process quality exceptions

Agentic stewardship

Define trusted sources
Set confidence thresholds
Establish approval requirements
Review ambiguous cases
Evaluate agent performance

How does entity resolution differ?

Traditional matching relies on deterministic and probabilistic rules. Agentic MDM can combine those rules with source trust, legal identifiers, relationships, hierarchies, lineage and historical decisions.

The aim is not to replace predictable logic with unexplained AI. It is to add context and make the evidence easier to inspect.

How does governance differ?

Traditional MDM commonly governs roles, workflows, approvals and human stewardship. Agentic MDM extends those controls to software agents.

A governed agent should have a defined objective, known permissions, approved tools, clear confidence thresholds, audit history and a tested escalation or reversal path.

Does Agentic MDM mean fully autonomous data changes?

Observe-only Identify issues and gather evidence without modifying data.

Recommend Propose matches, corrections, classifications, enrichments or rules.

Controlled execution Perform approved low-risk actions within defined boundaries.

How does data-quality management differ?

Traditional processes often identify a rule failure and send it to a queue. Agentic MDM can add investigation and controlled remediation.

Identify the issue
Inspect lineage and source records
Search approved evidence
Recommend a correction
Apply or route the correction
Monitor whether the issue returns

How does processing cadence differ?

Agentic MDM does not mean every process must be real time. The right cadence may be scheduled, micro-batch, event-driven, near-real-time or continuous.

The advantage is that an agent can retain ongoing responsibility for an outcome across processing cycles.

How does each approach scale?

Traditional MDM can scale technically, but operational effort may rise as new sources create more rules, exceptions and stewardship work.

Agentic MDM aims to absorb more profiling, investigation, evidence gathering, classification, enrichment, prioritisation and low-risk remediation without increasing manual effort at the same rate.

Which model is better for AI readiness?

Both approaches can provide consolidated entities, golden records and trusted publishing. Agentic MDM adds a more continuous operating model around that foundation.

Data does not remain AI-ready automatically. It must stay resolved, current, classified, governed and traceable as conditions change.

When is traditional MDM still a sensible choice?

Data domains are stable
Matching patterns are predictable
Batch processing meets business needs
Exception volumes are manageable
Stewardship teams have sufficient capacity
The existing platform is delivering acceptable outcomes

When should an organisation consider Agentic MDM?

Stewardship queues are growing
Data issues repeatedly return
Rule maintenance consumes significant effort
Relationships affect matching decisions
AI programmes require continuously trusted data
Skilled stewards spend too much time on repetitive work

Can an organisation modernise without replacing its entire MDM estate?

Yes. Agent-assisted processes can be introduced around an existing environment.

Profiling new sources Investigating quality exceptions Preparing duplicate evidence Recommending classifications Prioritising queues Enriching records

How should an organisation evaluate the two approaches?

Establish the current baseline for queues, steward hours, quality and cost
Choose one contained use case
Compare accuracy, approvals, false positives, reversals and human effort
Review governance, permissions, stop conditions and rollback

CluedIn perspective

How does CluedIn combine MDM and agentic operations?

Enterprise MDM capabilities including entity resolution, golden records, survivorship, hierarchies and governance
A persistent knowledge graph connecting sources, mastered entities, relationships, lineage, ownership and policy
Governed agents for profiling, duplicate discovery, validation, classification, enrichment and stewardship preparation
Risk-based operation through observe, recommend and authorised-action modes
Human oversight for ambiguity and high-impact decisions
Integration with Microsoft Fabric and Microsoft Purview

Explore the CluedIn platform CluedIn vs traditional MDM

What should buyers ask an Agentic MDM vendor?

What objective was assigned to the agent?
What data, evidence and relationships did it inspect?
What tools, rules and policies applied?
Was human approval required?
What action was proposed or completed?
What audit evidence was created?
How could the result be stopped or reversed?

The decision is about the operating model

Traditional MDM and Agentic MDM should both support trusted master data. The real difference is whether the operating model remains centred on rules, batches and human exception queues, or evolves towards governed agents progressing defined outcomes.

Human expertise should no longer be consumed by every repetitive data task.

See Agentic MDM in action

FAQs: Agentic MDM vs traditional MDM

What is the main difference between Agentic MDM and traditional MDM?

Traditional MDM relies more heavily on configured rules, scheduled processing and human exception queues. Agentic MDM gives governed agents responsibility for continuously progressing defined data outcomes.

Does Agentic MDM replace traditional MDM capabilities?

No. It still requires entity resolution, golden records, survivorship, governance, stewardship and trusted publishing.

Does Agentic MDM replace data stewards?

No. Agents handle more repetitive investigation and preparation, while stewards focus on policy, ambiguity, oversight and high-impact decisions.

Is traditional MDM obsolete?

No. It remains effective for stable data patterns, predictable matching, manageable exception volumes and environments where batch processing is sufficient.

How does Agentic MDM reduce stewardship effort?

Agents filter noise, gather evidence, prepare recommendations, prioritise exceptions and perform approved low-risk work before cases reach a person.

Does Agentic MDM still use rules?

Yes. Deterministic rules remain valuable for stable and predictable requirements.

Why is a knowledge graph useful?

It gives agents context about relationships, lineage, ownership, source trust, policies and previous decisions.

Can Agentic MDM make changes automatically?

It can perform authorised actions where policy, permission, evidence and confidence allow. High-risk changes should retain human approval.

Can Agentic MDM work alongside an existing MDM platform?

Yes. Organisations can introduce agent-assisted profiling, quality investigation, classification, enrichment and stewardship preparation before deciding whether broader modernisation is required.

How should an organisation choose between the two approaches?

Evaluate both using representative data and compare accuracy, stewardship effort, quality improvement, governance, reversals, cost and business impact.

How Do AI Agents Reduce Manual Data Stewardship in MDM?

CluedIn — Fri, 24 Jul 2026 16:26:20 GMT

Direct answer

AI agents reduce manual data stewardship by taking over the repetitive work surrounding master data decisions: profiling records, finding likely duplicates, gathering evidence, recommending corrections, enriching missing values, classifying entities and prioritising exceptions.

The real change

AI agents do not simply make data stewards faster. They change the unit of stewardship from individual records to policies, outcomes and exceptions.

What is data stewardship in Master Data Management?

Data stewardship is the ongoing work required to keep important enterprise entities accurate, complete, consistent and appropriately governed.

Customers Products Suppliers Assets Locations Reference data

The problem is not stewardship itself. The problem is using expensive human judgement for thousands of repetitive decisions that software could investigate, prepare or safely resolve.

Why does manual stewardship become a bottleneck?

As ERP, CRM, product, procurement, lakehouse and SaaS sources multiply, so do identifiers, formats, duplicates, ownership questions and quality issues.

Open the case
Compare the records
Inspect source systems
Check policies
Gather evidence
Make and record the decision
Approve or reject the action

What changes when AI agents enter the stewardship process?

Traditional stewardship is organised around a queue of records. Agentic stewardship is organised around defined outcomes.

Example agent objectiveMonitor product records for missing mandatory attributes, gather evidence from approved sources, propose corrections and escalate cases where the evidence conflicts.

The shift from record stewardship to policy stewardship

Traditional record stewardship

Is this customer a duplicate?
Which supplier value should survive?
What category should this product use?
Can this record be published?

Agentic policy stewardship

What evidence is required before a merge?
Which sources are trusted?
Which corrections are safe to automate?
Which changes require human approval?

Which stewardship tasks are best suited to AI agents?

Duplicate investigation Identify candidate groups, compare identifiers, inspect source trust and gather relationship evidence.

Data-quality investigation Detect missing values, group recurring issues and recommend corrections or rules.

Classification Classify products, suppliers, assets, sensitive data and reference values.

Enrichment Find approved sources and propose missing values with evidence.

Mapping Support source-to-target mappings, taxonomy alignment and semantic interpretation.

Stewardship prioritisation Rank cases by business impact, confidence, sensitivity and downstream dependencies.

Which tasks need stronger controls?

High-impact actions may include: customer identity merges, legal ownership changes, financial master-data updates, sensitive-data reclassification, supplier-risk changes and publication into critical operational systems.

What is governed autonomy in data stewardship?

Governed autonomy means agents work independently only within defined limits.

Observe Identify issues and gather evidence without changing data.

Recommend Propose corrections, matches, classifications, enrichments or rules.

Perform authorised actions Execute approved low-risk or high-confidence work within clear boundaries.

Why is explainability essential?

For any material action, the platform should show what the agent was trying to achieve, which records and sources it inspected, which relationships and policies applied, what it recommended and who authorised the outcome.

Explainability is not only a compliance feature. It is a productivity feature.

How does a knowledge graph reduce stewardship effort?

A knowledge graph connects source records, mastered entities, relationships, hierarchies, lineage, ownership, policies, previous decisions and downstream dependencies.

CluedIn uses this connected context so agents can reason over the broader entity and governance picture rather than processing records in isolation.

Do AI agents replace deterministic rules?

No. Rules remain better when the requirement is clear and stable. Agents are more useful when evidence is distributed, language interpretation is required or several possible actions exist.

The strongest model combines deterministic rules, similarity matching, source trust, relationship context, AI recommendations and human judgement.

How do human stewards work alongside agents?

Before Agentic MDM

Compare records
Search source systems
Correct fields
Process duplicate queues
Prepare audit evidence

With Agentic MDM

Define policy
Set thresholds
Approve automation
Resolve ambiguous cases
Review agent performance

How should agentic stewardship be measured?

Stewardship Queue volume, review time, resolution time and steward hours.

Accuracy Approval rates, false positives, false merges and reversals.

Governance Policy coverage, owner coverage and evidence completeness.

Business value Faster onboarding, fewer errors and lower cost per resolved issue.

What evidence is there that agents reduce stewardship work?

Komatsu

CluedIn’s published case material reports approximately 10 million records processed per day and a shift from a full team maintaining the operation to one person overseeing AI-driven processes.

SEGA

SEGA used CluedIn agents to classify a full catalogue by console, complete more than 12,000 properties across approximately 7,000 games and process 7,000 records in under one minute.

How should an organisation get started?

Choose one high-volume, measurable and relatively low-risk stewardship problem.
Establish a baseline for queue size, steward hours, quality and business impact.
Start agents in observe mode.
Introduce recommendations for human approval.
Measure approval rates, false positives, reversals and time saved.
Define low-, medium- and high-risk actions.
Permit controlled actions only where evidence and policy support them.
Expand progressively by domain.

CluedIn perspective

How does CluedIn support agentic data stewardship?

Agents work with relationships, lineage, source trust, ownership, rules and previous outcomes
Agents support duplicate discovery, validation, classification, enrichment and rule recommendations
Permissions, approvals, workflows and audit history shape execution
Human oversight remains available for ambiguous and high-risk actions
Results can be evaluated through quality, accuracy, time, cost and stewardship reduction

Explore the CluedIn platform

AI agents change the unit of stewardship

The most important effect of AI agents is not that they help stewards click through queues faster. It is that organisations can move from record-by-record repair towards policy-driven stewardship.

The outcome is not stewardship without humans. It is human stewardship applied where it has the greatest value.

See agentic stewardship in action

FAQs about AI agents and MDM stewardship

What stewardship tasks can AI agents automate?

AI agents can assist with duplicate discovery, classification, enrichment, validation, mapping, anomaly investigation, rule recommendations and evidence gathering.

Do AI agents replace data stewards?

No. They reduce repetitive record-level work so stewards can focus on policy, ambiguity, ownership, high-impact decisions and agent oversight.

What is agentic data stewardship?

It is an operating model in which governed AI agents continuously perform or prepare authorised stewardship work while humans retain responsibility for policy and consequential decisions.

What is the difference between rule-based automation and AI agents?

Rules execute fixed logic. Agents can investigate context, gather evidence, select approved actions and pursue a defined outcome.

Why is a knowledge graph useful?

It gives agents context about relationships, lineage, ownership, source trust, policies and previous decisions.

Can AI agents merge master data automatically?

They may support controlled merges where policy, evidence, permissions and confidence permit. High-impact or ambiguous merges should retain human approval.

How should agent accuracy be measured?

Measure approval rates, false positives, false merges, reversals, missed matches, time saved, quality improvement and business impact.

How does governed autonomy protect data?

It restricts agents through permissions, policies, confidence thresholds, approvals, logging, escalation and reversal controls.

How should an organisation start?

Start with one high-volume, measurable and relatively low-risk use case, begin in observe mode and expand gradually.

How does CluedIn reduce stewardship effort?

CluedIn uses governed agents and a persistent knowledge graph to support duplicate investigation, enrichment, validation, classification and data-quality remediation while preserving explanations, lineage and human oversight.

8 Questions Regulated Enterprises Should Ask Before Choosing an MDM Platform

CluedIn — Fri, 24 Jul 2026 15:45:29 GMT

Direct answer

Regulated enterprises should choose an MDM platform by evaluating the evidence it produces whenever data is matched, changed, approved, enriched or published. The key question is not how many features the platform has, but whether it can prove what happened, why it happened, who or what authorised it and whether the outcome can be reviewed or reversed.

What regulated teams should expect from MDM

Trusted Explainable Traceable Policy-compliant Approved Auditable Fit for AI

Why is MDM platform selection different in regulated industries?

Regulated organisations need more than accurate records. They may need to demonstrate where a value originated, which rule changed it, who approved a merge, why one source was trusted over another and whether a decision can be challenged or reversed.

In regulated environments, the quality of the outcome and the quality of the evidence are inseparable.

Why is a conventional feature checklist not enough?

Two MDM platforms may both claim matching, workflows and AI. One may only provide a score. Another may combine deterministic rules, similarity, source trust, relationships, policy constraints and human approval.

The feature name is the same. The governance, evidence and operational risk are not.

The 8 questions regulated enterprises should ask

QUESTION 1

Can the platform explain why every important mastered value exists?

For every important attribute, the platform should show the source, alternative values considered, survivorship rule, enrichment, approver and policy.

Look for: attribute-level provenance, golden-record history, explain logs, before-and-after values, source contribution and approval history.

QUESTION 2

Can the platform resolve entities using more than field similarity?

Entity resolution should consider legal identifiers, source reliability, relationships, locations, contracts, historical names and prior decisions—not only similar names and addresses.

Why it matters: a false merge can affect consent, sanctions screening, supplier risk, reporting and customer rights.

QUESTION 3

Does governance operate when data changes—or only after the event?

Governance should validate data during ingestion, restrict actions by role, require approval at defined thresholds and block prohibited changes before publication.

The key question: can policy change what the platform is allowed to do at the moment a data decision is made?

QUESTION 4

Can AI reduce manual effort without removing accountability?

AI agents can assist with profiling, enrichment, duplicate discovery, recommendations and evidence gathering, but actions should be governed according to risk.

Low risk Formatting, casing and approved code mapping.

Medium risk Enrichment, new relationships and rule recommendations.

High risk Identity merges, ownership changes and sensitive data.

QUESTION 5

Can the platform reduce stewardship queues without hiding risk?

The platform should prioritise issues, gather evidence, explain recommendations and automate approved low-risk work while routing real exceptions to the right owner.

The goal: reserve expert attention for ambiguous, sensitive and high-impact decisions.

QUESTION 6

Does the deployment model satisfy security, residency and sovereignty requirements?

Ask where data is stored and processed, which regions host the service, how keys are managed, what AI services receive data and who can administer the environment.

Do not rely on labels. Ask for a precise architecture showing processing boundaries, model access, logging, backup and cross-region transfer.

QUESTION 7

Can the platform prove that data is fit for AI—not simply available to AI?

AI-ready data should be resolved, contextual, governed, current, traceable, approved and monitored.

Moving data into a lakehouse does not make it AI-ready.

QUESTION 8

Can the vendor prove value and control before you scale?

A safer path is progressive: observe, recommend, permit controlled low-risk action and expand responsibility only when evidence supports it.

Demand: representative pilots, success criteria, error reporting, cost visibility, audit evidence, stop conditions and rollback.

What evidence should an MDM platform produce?

Record evidence Original values, corrected values, source, timestamps and validation.

Entity evidence Match candidates, confidence, relationship evidence and survivorship.

Governance evidence Policies, owners, permissions, approvals and exceptions.

Operational evidence Agent activity, quality trends, failures, reversals, cost and latency.

How should entity resolution be tested?

Use representative and difficult records, including shared addresses, historical names, subsidiaries, common names, missing identifiers and conflicting source values.

Measure precision, recall, false merges, missed matches, review volume, unmerge rate, survivorship accuracy and explanation quality.

What should buyers ask about AI governance?

What was the agent asked to achieve?
Which records and evidence did it inspect?
Which permissions and policies applied?
Was human approval required?
What changed?
How was the action logged?
How could the action be reversed?

CluedIn perspective

How does CluedIn approach MDM for regulated enterprises?

CluedIn combines Master Data Management, entity resolution, data quality, enrichment, governance and governed AI agents in a graph-native platform.

Persistent knowledge graph connecting entities, sources, lineage, ownership and policy
Entity resolution using rules, similarity, source trust and relationship context
Governed agents for classification, validation, enrichment and duplicate discovery
Permissions, approvals, workflows and audit history
Human oversight for high-risk and ambiguous decisions
Microsoft Fabric and Purview integration

Explore the CluedIn platform Compliance, privacy and security

What are the warning signs?

A chatbot is presented as an autonomous agent
Full autonomy is claimed without explaining controls
Match scores are shown without supporting evidence
All issues enter the same manual queue
False merges and reversals are not measured
Governance is treated as a separate documentation layer
AI processing boundaries are unclear
“AI-ready” is used without defining the required data state

Choose an MDM platform by the evidence it can defend

Do not begin with the longest feature list. Begin with the decisions the platform will make about your data, the controls surrounding those decisions and the evidence it will produce.

The defining question is: “Why should we trust this record?”

See governed MDM in action

FAQs about choosing an MDM platform for regulated industries

What makes MDM different for regulated industries?

Regulated organisations need accurate data and evidence showing how important values, matches, approvals and changes were produced.

What is the most important MDM capability for compliance?

No single feature is enough. Entity resolution, provenance, governance, approvals, access control and audit history must work together.

How should entity resolution be tested?

Use difficult representative records and measure precision, recall, false merges, missed matches, review volume and explanation quality.

Why does graph context matter?

Graph context adds relationships, ownership, lineage, hierarchies and dependencies to entity-resolution decisions.

Can AI agents safely manage regulated master data?

They can assist when permissions, policy, confidence thresholds, approvals, logging and human oversight govern their actions.

What is governed autonomy in MDM?

Governed autonomy means agents can perform authorised data work independently while remaining constrained by explicit policies and risk controls.

How can MDM reduce manual stewardship?

By automating evidence gathering, prioritisation and approved low-risk corrections while preserving human review for sensitive decisions.

What should an MDM audit trail contain?

It should show what changed, the previous and resulting values, source, policy, user or agent, approval history and downstream impact.

How does MDM support AI readiness?

MDM gives AI systems resolved, governed, current and contextual entities instead of duplicate or conflicting records.

How should a regulated enterprise start?

Begin with one high-value domain, establish a baseline, observe first, test recommendations and expand only after controls and accuracy are proven.