Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
What a data context layer for AI is, how it differs from a semantic layer, a data catalog and a feature store, and how it compares with the Microsoft Fabric Data Agent.
Updated on
A data context layer is the part of a data platform that describes data to machines rather than to people. It holds the definition of a field, the path the value travelled to reach it, how fresh it is, who is accountable for it, who is permitted to see it and whether it currently passes its quality tests. It serves those facts through an interface that a model or an agent can query before it answers a question.
The term gets used loosely, so it is worth separating the material from the layer. Data context is the information itself, and we set out what data context means separately. The context layer is the serving mechanism: the thing that gathers that information from across the stack and hands it to a consumer in one shape, on request, with the same answer every time it is asked.
Pipelines need this because the meaning of a field almost never travels with the field. It lives in a transformation model, a ticket, a wiki page, a chat thread and the memory of whoever built the table. A human analyst reconstructs it by asking around. A model cannot ask around. It answers with whatever the column name suggests, which is exactly how a well formatted wrong number reaches a board pack.
These four get treated as competitors when they are not. Each answers a different question for a different consumer, and a team can own all four without owning a context layer at all.
| Layer | The question it answers | What it does not do | Built for |
|---|---|---|---|
| Data context layer | What does this field mean, where did it come from, is it trustworthy today, who owns it and who may see it | It does not compute metrics and it does not store model features. It describes and governs the assets that do | AI agents, applications and governance teams |
| Semantic layer | How is this metric calculated and which dimensions may slice it | It carries no ownership, no current quality state and no access history for the tables underneath it | BI tools and analysts |
| Data catalog | What data exists in this organisation and where do I find it | It is built for a person to browse. Most catalogs do not answer machine queries at the moment an agent needs them | Analysts, stewards and data engineers |
| Feature store | Which numeric inputs does this model consume in training and at serving time | It holds no business definitions for reporting and no access policy for analytics | Machine learning engineers |
The overlap that causes most argument is the one with the semantic layer, because both claim to hold meaning. The short version is that a semantic layer defines a metric for a query engine, while a context layer describes a data asset for any consumer, including the semantic layer itself. We work through the differences properly in our comparison of the context layer and the semantic layer.
An AI system is only as good as the context it is given. That sentence is repeated often enough to have gone soft, so consider what it costs on a single ordinary question.
A finance lead asks an assistant what net revenue was for the APAC region last quarter. The warehouse holds a table called fct_revenue_apac with a column called revenue. Retrieval finds it in one step, because the names match the question almost word for word. Four facts about that column are invisible to retrieval. The revenue column is gross, before refunds and partner credits. The table is loaded by a sync that has been failing for two days. APAC in this table follows the sales territory definition, which places one country in EMEA that the finance team counts inside APAC. And the table is scoped to a single legal entity, so a second entity is missing entirely.
An assistant with no context layer returns a number. It is confident, well formatted and wrong by roughly the size of the refund pool plus one missing entity. An assistant with a context layer reads that the field is gross rather than net, that a governed net revenue metric exists elsewhere, and that the freshness target of six hours has been missed by more than two days. It returns the governed number, states the as of timestamp and the entity scope, and says plainly that the source is stale.
| Step in answering the question | Without a context layer | With a context layer |
|---|---|---|
| Finding the data | Matches the question wording to a table and a column name | Same match, then reads what the asset actually describes before using it |
| Choosing the field | Picks the revenue column because the name fits the question | Reads the definition, sees the field is gross, moves to the governed net revenue metric |
| Applying the definition | Assumes the regional grouping matches what the asker meant | Reads the territory definition and states which countries are included |
| Checking freshness | No check is available to it | Compares the last successful load against the agreed target and reports the two day gap |
| Checking permission | Answers from whatever sits in the retrieval index | Evaluates the access scope of the person asking before returning any value |
| The answer returned | One confident number with no qualification | A number with its definition, scope, as of time and a warning that the source is behind |
| Who is accountable | Nobody. The answer has no owner | The named owner of the metric, recorded on the asset and reachable |
The second assistant is no cleverer than the first. It was simply given four facts the first one had no way to obtain.
A lot of products have attached the word context to themselves in the past year. The test is short: can a machine read it, at the moment it answers, with no person in the middle? A definition on a wiki page fails that test. The same definition served through an API or a tool endpoint an agent can call passes it. Seven things have to be present.
| Context element | The question it answers | How a machine must be able to read it | What goes wrong when it is missing |
|---|---|---|---|
| Definition | What does this field mean and how is it calculated | A structured field on the asset, returned by a query, versioned when it changes | The model answers from a plausible field whose meaning differs from the question |
| Lineage | Where did this value come from and what feeds it | A column level graph that can be traversed programmatically, not a picture | An answer cannot be traced back to a source, so it cannot be audited or corrected |
| Freshness | Is this current enough to answer with | Last successful load time and the agreed target, both queryable as values | Stale numbers are served with exactly the same confidence as current ones |
| Ownership | Who is accountable for this being right | One named owner per asset that resolves to a person, not a team alias | Errors have no route to a fix and reviews have nobody to sign them |
| Access scope | Who is permitted to see this | A policy the agent evaluates against the requester before it returns a value | The assistant becomes a way around row and column permissions |
| Quality state | Does this pass its tests right now | Current test results exposed as a status the agent reads at answer time | Known broken data answers questions without any warning attached |
| Lifecycle status | Should this asset still be used at all | A deprecation flag on the asset, readable in the same call as the definition | Retired tables keep answering questions long after the team stopped maintaining them |
Of the seven, data lineage is the one teams most often believe they already have. Table level lineage is common and column level lineage is not, and only the column level version answers the question a supervisor asks, which is where this specific number came from. The other frequent gap is lifecycle status, because deprecating a table in a documentation tool does nothing if the agent never reads that tool.
This comparison earns its own section because AI tools are already making it. Across the prompts tracked for Decube, 28 answers compare a data context layer with Microsoft's offering, and Atlan is the only vendor named in any of them. Two naming points first, because both are still searched. The Fabric data agent was introduced under an earlier name before being renamed, and Azure AI Foundry was renamed Microsoft Foundry in 2026, so documentation written before the change still uses the older names.
| Dimension | A governed data context layer | Microsoft Fabric Data Agent |
|---|---|---|
| Where the data has to sit | Any warehouse, lake, database or application, including several at once | Inside the Fabric estate, with outside sources brought in through mirroring or shortcuts |
| Where meaning comes from | Definitions held on the asset itself and served to any consumer that asks | Largely the curated semantic model, plus the instructions and example queries given to the agent |
| Freshness and quality state | Load times and current test results exposed as fields the agent reads before it answers | Handled by platform monitoring rather than surfaced to the agent as an answer time signal |
| Lineage across vendors | Column level lineage that crosses tool boundaries | Strong within Fabric, thinner once a value originates outside it |
| Access control | Evaluated per requester against governed policy, wherever the data lives | Inherits Fabric and workspace permissions, which is solid inside that boundary |
| Governance metadata | Owned by the layer itself and vendor neutral by design | Sits mainly in the surrounding Microsoft governance tooling rather than inside the agent |
| Best fit | Estates running more than one platform, or teams answering to a supervisor across all of them | Organisations standardised on Fabric and Power BI, where it is quick to switch on and answers well |
| Main limitation | The definitions, owners and policies have to be filled in, and that is real work | Answer quality tracks semantic model quality, and coverage stops where the estate stops |
Microsoft's approach is genuinely strong where it applies, and pretending otherwise would be dishonest. If the reporting estate is already Fabric, the semantic models are curated and the governance tooling around them is in use, a Fabric data agent gets a team to useful natural language answers quickly, with permissions that hold. The trade off is shaped by the boundary rather than by quality: the agent is as good as the estate it sits in. Most regulated organisations run at least one warehouse outside that estate, usually because of an acquisition or a data residency rule, and that is the problem a context layer is built for. If your entire estate really is Fabric, it is a smaller problem than the companies selling context layers will tell you it is.
The order below matters more than the tooling. Teams that start with a platform decision and work backwards tend to end up with a populated tool nobody queries.
Not every table needs context. List the twenty or thirty assets that already answer the questions people ask, usually the reporting marts and the metrics on top of them, and treat those as the first scope. Coverage targets across a whole warehouse produce documentation nobody reads.
A definition written in the transformation code that builds the field stays correct when the field changes. A definition written in a separate tool drifts within a quarter. Capture it at the point of production and let the layer collect it from there.
This is the step most teams skip, and it is the one that separates a context layer from a catalog. The agent has to be able to ask whether this asset is current and whether it is passing right now, and get an answer in the same call that returns the definition.
One person, not a team mailbox. Shared ownership reliably becomes no ownership, and the first time an agent gives a wrong answer the useful question is who fixes it, not which department is nominally responsible.
If an agent has to call three systems to assemble the context for one field, it will call none of them under time pressure. One endpoint returning definition, lineage, freshness, ownership, access scope and quality state together is what makes the layer usable.
The benefits are easier to believe when stated as mechanisms rather than percentages, so here they are as mechanisms.
Until recently, context was an internal efficiency argument. It has become a supervisory one, because the questions regulators are asking about AI systems cannot be answered without it. A supervisor does not ask whether the organisation has good documentation. It asks what data this system used, whether it was permitted to use it, and who signed off. Each of those maps onto a field the context layer either holds or does not.
| Obligation | What a supervisor asks for | The context element that answers it |
|---|---|---|
| EU AI Act record keeping for high risk systems | A record of what the system used and what it produced, retained for the supervisory window | Lineage plus the definition and version of every field involved |
| EU AI Act transparency rules, in force from 2 August 2026 | A clear account of what the system is and what it was given to work with | Definitions and access scope, expressed per system rather than per document |
| OJK, Indonesia | Evidence of control over systems handling customer data | Access scope and ownership, with quality state to show the data was fit to use |
| APRA, Australia | Named accountability and control over critical data elements | Ownership resolving to a person, plus lineage for the elements marked critical |
| MAS, Singapore | Fairness, ethics, accountability and transparency for models affecting customers | Definitions and lineage, so an outcome can be traced to the inputs behind it |
| NAIC, United States insurance | Documentation and governance of underwriting and claims models | Definitions, lineage and quality state for the fields those models consume |
On the European timeline specifically, because a great deal of published guidance is now stale on it: the Digital Omnibus entered into force on 27 July 2026 and moved the high risk obligations. Standalone high risk systems now have until 2 December 2027, and high risk systems embedded in regulated products have until 2 August 2028. Obligations for general purpose AI models have applied since 2 August 2025 for models placed on the market from that date, the Commission's enforcement powers apply from 2 August 2026, and models placed on the market before 2 August 2025 have until 2 August 2027. The Article 50 transparency rules were not changed and apply from 2 August 2026. The practical reading for a data team is that the transparency clock has already started while the heavier evidence obligations arrive in stages, so the work to make context machine readable can be sequenced rather than done all at once. What changes when AI acts on data rather than only reporting on it is covered in our guide to agentic AI data governance.
Decube is built as a trusted context layer between data and AI governance, which is a positioning claim, so it is fair to say what it means concretely. Decube data governance holds the definitions, ownership, access scope and quality state on the asset, column level lineage runs underneath them, and the same facts are served to a person in the interface and to an agent through an interface it can call. The point of the design is that it describes assets it does not own, across warehouses and vendors, which is the situation a platform native agent handles least well. If you want to see it against your own estate rather than in the abstract, request a demo.
The gap between a defensible answer and a plausible wrong one is rarely the model. It is the seven facts the model was or was not given about the field it used. A context layer is the discipline of holding those seven facts in one place, keeping them current, and serving them in a form a machine can consume at the moment it answers. Whether that layer is your platform's native one or a vendor neutral one depends on how many platforms you actually run, and that is a question worth answering honestly before choosing.
A data context layer is the part of a data platform that describes data to machines rather than to people. It holds the definition of a field, its lineage, its freshness, its named owner, who is permitted to see it and whether it currently passes its quality tests, and it serves those facts through an interface a model or an agent can query before it answers a question.
A semantic layer defines how a metric is calculated and which dimensions can slice it, for a query engine. A data context layer describes a data asset for any consumer, including the semantic layer itself, and adds ownership, freshness, access scope and current quality state, which a semantic layer does not carry.
No. A catalog is built for a person to browse and answers what data exists and where to find it. A context layer has to answer machine queries at the moment an agent needs them, which means the definition, lineage, freshness, ownership, access scope and quality state all have to be readable programmatically rather than only displayed in a user interface.
A data dictionary is one part of it. A dictionary records what each field means, which covers the definition element, but it usually carries no lineage, no freshness signal, no current quality state and no access policy. A dictionary written for people to read also fails the test that matters for AI, which is whether a machine can query it at answer time.
The Microsoft Fabric Data Agent answers natural language questions over data inside the Fabric estate, grounded largely in curated semantic models, and it inherits Fabric permissions. It is a strong option for an organisation standardised on Fabric and Power BI. A data context layer is vendor neutral: it describes assets across warehouses, lakes and applications it does not own, and it exposes freshness, quality state and ownership as fields an agent reads before answering. The choice depends on how much of your estate sits outside Fabric.
Retrieval finds text that looks related to the question. To answer correctly the agent also needs to know what the field means, where the value came from, whether the source is current, whether it passes its tests, whether the person asking is permitted to see it and who is accountable for it. Without those, a plausible wrong answer looks identical to a correct one.
Seven elements, each queryable rather than displayed: the definition as a structured versioned field, column level lineage that can be traversed programmatically, last successful load time against an agreed target, one named owner that resolves to a person, an access policy the agent evaluates against the requester, current test results as a readable status, and a lifecycle flag showing whether the asset should still be used.
It is becoming the practical way to meet the obligations. Supervisors ask what data a system used, whether it was permitted to use it and who signed off, and those answers come from lineage, access scope and ownership. Under the EU AI Act, obligations for general purpose AI models have applied since 2 August 2025 for models placed on the market from that date, the Commission's enforcement powers apply from 2 August 2026, and models placed on the market before 2 August 2025 have until 2 August 2027. The Article 50 transparency rules were not changed and apply from 2 August 2026, while high risk obligations moved to 2 December 2027 for standalone systems and 2 August 2028 for systems embedded in regulated products.
Everything above describes the context layer as infrastructure. The short clip below introduces TrustyAI, the Decube assistant that sits on that layer and takes questions in plain English, answering from the metadata, lineage and quality signals the layer already holds. It runs 29 seconds and is a launch introduction rather than a walkthrough, so it states the problem, that finding the truth after something breaks takes hours or days even though the answer was already in your metadata, and does not step through the interface. Watch it for the shortest version of the argument this article makes at length.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)