Your AI context layer cannot tell you what it said in March

What your data lineage has to prove before an examiner asks about a past decision

Gartner now advises data and analytics leaders to “establish a context layer as a core component of their D&A infrastructure,” because schema-based data models on their own lack the business context and data meaning that AI agents need.¹ Governance and data platform vendors have answered with a run of products and definitions built on the same phrase. In the sense most of them use, an enterprise context layer is the set of business definitions, ownership and policy records, and data lineage that an AI agent reads before it answers a question or takes an action. Agents without that context guess, so the demand behind the category is well founded.

Little of the published material addresses one question, and a model risk validator or bank examiner will eventually ask it. When an agent made a decision on a specific day in March, what did its context say on that day? Every definition in a context layer, along with the owner, policy, and lineage attached to it, was true as of some date. A context layer that keeps only the latest version of each can tell you what the business believes now, and it cannot show you what the agent was given.

Every piece of context an AI agent reads has a date

The context an AI agent consumes is a collection of facts that change on their own schedules. A data steward revises the definition of a customer segment after a product launch, and a reorganization moves ownership of a risk dataset to another team. Policies get re-approved with new retention rules, and platform migrations replace the golden source behind a regulatory report, which reroutes the lineage path that feeds it. None of these changes is unusual, and a large bank makes several of them every week.

Each fact in that collection also has two dates. One is when the fact was true in the business, such as a segment definition that applied from January 1, and the other is when the organization recorded it, such as the day in September when a steward entered a corrected version. The two dates match when everything goes to plan, and they diverge whenever someone corrects an error after the fact, which is the situation an audit tends to probe. Data architects call storing both dates for every change bi-temporal storage. It lets a lineage platform answer two different questions about March 14: what the bank believed was true on that day, and what the bank now knows was true on that day. Most context layers are built around retrieving the current answer, and an edit log, where one exists, records only that something changed. Rebuilding the March state from that log means replaying edits by hand across every definition, ownership record, and lineage path the agent touched, and hoping that nothing was changed outside the tool.

When a data steward fixes a definition, the March answer disappears

An illustrative case shows how this plays out. A bank deploys an AI agent that answers credit exposure questions for relationship managers. The agent draws on its context layer for the definition of “small business customer,” for the policy that sets exposure limits for that segment, and for the lineage that shows which source systems feed the exposure figures.

In September, a data steward notices that the segment definition wrongly excludes sole proprietors, corrects it, and records the change. The same month, a platform migration swaps the golden source for customer turnover data, and the lineage behind the exposure figure now runs through a new system. Both changes are good governance, and nobody reviewed either one against the decisions the agent had already made.

In November, an examiner selects an exposure recommendation the agent made in March and asks the bank to show what the agent relied on. The model risk validator opens the context layer and finds September’s definition, the current lineage path, and the policy as approved today. An edit history confirms the definition changed, but it cannot show that definition alongside the owner, policy, and lineage it had on the day of the decision. The validator spends days rebuilding March from change tickets, email threads, and a migration runbook, and the result still depends on the memories of the people who made the changes. The stewardship that improved the context layer also erased the evidence the examiner asked for. The same problem appears one level down, at the model itself, where lineage tools forget what your AI model saw when it made a prediction.

Supervisors already expect traceability after the fact

None of the major supervisory texts use the phrase “context layer.” The European Central Bank’s (ECB) May 2024 guide on effective risk data aggregation and risk reporting (RDARR), which builds on the BCBS 239 principles, expects banks to maintain “complete and up-to-date data lineages on data attribute level.”² The guide also defines data lineage by what it lets a bank do, including the ability to “track back the source of the issue in a timely manner” after a data quality incident and to “allow traceability for (external) validation.”³ Both uses look backward. A validator tracing an incident needs the lineage as it stood when the incident occurred, and a lineage record kept up to date by overwriting its own history cannot provide it.

In the United States, SR 26-2, the April 2026 model risk management guidance from the Federal Reserve, the Federal Deposit Insurance Corporation, and the Office of the Comptroller of the Currency, places generative and agentic AI outside its scope. A footnote adds that a bank’s “risk management and governance practices should guide the determination of appropriate governance and controls” for the tools the guidance does not cover.⁴ Agents therefore answer to the governance expectations a bank already holds, including the lineage traceability the ECB guide spells out. Gartner points the same way, expecting that “regulators will demand greater semantic transparency.”⁵ Evidence also loses value as the underlying data changes, a problem your BCBS 239 evidence expires the day you file it examines in detail.

What a context layer needs before you trust it with an agent

A context layer that an examiner can rely on needs three capabilities, and each one depends on keeping both dates for every change:

1. Compare any two points in time: A validator should be able to select the decision date and today and see exactly what changed between them in the definitions, ownership and policy records, and lineage, at the level of individual data attributes. The platform should directly provide the comparison, without exporting data or stitching change logs together.
2. Approve changes before they take effect: Model a correction to a definition or lineage path in a sandboxed copy and check for downstream impact, then have an accountable expert approve it before it reaches production. The same review should apply when an AI assistant proposes the change, so the history records who approved each version and when.
3. Reconstruct the joined record as of any date: Agents rarely draw on a single platform. Reconstructing March requires following the agent’s inputs through catalogs, data platforms, and legacy systems, attaching business context at each step, and reaching systems no single platform can trace.

Solidatus is a data lineage platform built on this model. Its lineage model keeps both dates for every change, so teams can compare any two points in time and reconstruct the lineage model as it stood on a past date. Every change, including one drafted by the AI Lineage Assistant, goes through a review workflow of forks, comparisons, and pull requests before it reaches the production lineage model. Lineage from catalogs, data platforms, and legacy systems sits in one model alongside the business definitions, owners, and policies attached to it.

Run the March test before an examiner does

You can run this test on your own context layer this quarter in three steps:

1. Pick one decision and one critical data element: Choose an AI-assisted decision from last quarter and a critical data element it used. Ask whoever runs your context layer to reproduce that element’s definition exactly as it stood on the decision date, along with its owner, policy, and lineage, and to show what has changed since. The test passes only when the platform returns that state in one view, with every record dated to the decision.
2. Put context changes through review: Treat a change to any definition or lineage path an agent consumes the way you treat a code change. Model it, check its downstream impact, and have an accountable owner approve it before it goes live, and apply the same rule to changes an AI assistant proposes.
3. Trace the element upstream until its lineage stops: Follow the same critical data element back toward its sources and note the first system where the lineage ends. The March reconstruction ends at the same system, so extend lineage coverage there first.

An examiner’s questions about agentic AI go further than a single decision. The six audit questions agentic AI will force banks to answer set out the full chain of evidence, from the data an agent accessed to the reconstruction of any decision on demand, along with what your lineage architecture needs to answer each question.