Your riskiest change ticket says low risk

Pre-change impact analysis for data estates that feed AI

The scenario is illustrative but familiar to anyone who runs a large data estate. A data engineering team consolidates two reference-data feeds into one. The change ticket says low risk. The cutover runs clean and nothing pages. Three weeks later, a pricing model that learned its behavior from the deprecated feed is scoring customers on outdated assumptions, and the first person to notice works in a business unit the ticket never mentioned.

Every enterprise measures impact. Most measure it in the postmortem, where the only available question is what the change broke. The valuable question comes earlier, while the change is still a ticket. For data ecosystems that feed AI systems, impact analysis has to move from a forensic exercise after the incident to a pre-change computation, run on the data lineage graph before anything ships. Teams that make that move stop discovering their dependencies from incident reports.

The impact runs deeper than monitoring can see

Application monitoring is built for problems that announce themselves. A failed job retries, an error rate crosses a threshold, and someone gets notified via Slack. When a machine learning (ML) model loses an upstream assumption, nothing triggers a notification. The model was trained on data as it looked at a point in time, and it carries that snapshot in its weights. When a data feed consolidation changes an encoding or a default value, the model continues to produce confident predictions based on dated assumptions that are no longer valid. Every upstream system reports healthy, because nothing in the software failed. What changed is the meaning of the data, the underlying assumptions, and nothing in the typical monitoring stack watches for meaning.

Data science teams that have deployed ML inside regulated banks learn to draw an operational line through model drift. Data drift that follows an upstream change is structural and can be detected and flagged to downstream owners as part of the change process itself. Concept drift, where the world moves away from the training data, resists prediction. Drift caused by your own change ticket is knowable in advance, which makes it the portion of model risk that an architecture prevents. Machine learning systems are brittle in this specific way, and data environments that respect the brittleness treat an upstream change to a model’s inputs as a model risk event until the lineage shows otherwise.We have written before about how a two-line change to an address field can significantly impact a model’s accuracy, and that story starts in the data supply chain, and so does the fix.

The impact is wider than one team’s ticket

The depth problem compounds as consumers multiply. A traditional report reads from a handful of curated tables. An AI agent assembling a decision pulls from whatever sources its task requires, at whatever moment it runs. Hence, a single reference column now sits inside the dependency set of consumers its owner has never met.

US supervisors have started to write this arithmetic into guidance. SR 26-2, the model risk guidance that replaced SR 11-7 this April, directs banks to manage aggregate risk, the exposure that builds when many models lean on the same data, assumptions, or methods, as noted in our piece on forensic lineage. The key signal for architects sits in the guidance’s third footnote, where the agencies placed generative and agentic AI outside its scope and told banks to extend the principles to those systems through their own governance programs, with a request for information signaled to follow.¹ The set of consumers a change can reach is widening faster than the rulebook that governs it.

When an examiner asks what else moves when this input moves, the answer has to exist before the change does.

Computing the impact on the current estate

Computationally, data lineage impact analysis is a graph traversal. It starts at the element a change ticket proposes to affect and follows every downstream edge, collecting the consumers, owners, and obligations it passes through. Two properties of the underlying lineage graph decide whether that result can be trusted.

1. Column-level resolution: A graph that resolves at table level returns every consumer of the table rather than every consumer of the changed field. Oversized impact sets train teams to ignore them. The lineage built into most data catalogs maps flows at the system or table level, which answers inventory questions and stops short of detailed impact analysis. Column-level data lineage lets the traversal separate the consumers of the field you are changing from the neighbors that happen to share a table.
2. End-to-end coverage: Scanner-based lineage tools capture flows where connectors exist and stop at the first system they cannot read, whether that is a mainframe, a bespoke application, or a spreadsheet hop. The traversal completes, the impact set looks finished, and the consumers beyond the unreachable system never appear. A truncated impact set is more dangerous than none, because it looks like an answer. Coverage has to span modern platforms, legacy systems, and mainframes, with modeled lineage filling in what automation cannot reach.

Both properties decay unless capture runs continuously. A graph that was accurate at last quarter’s audit computes last quarter’s impact, and systems change every week. Gartner’s research on agentic AI risk points in the same direction, recommending lineage tracked at the column or attribute level so teams can pinpoint which data modification produced which inaccuracy, and warning that manual tracking cannot be sustained across modern cloud and hybrid architectures.²

Modeling the change before it exists

Traversing the current data estate answers what a change will touch. The stronger discipline models the change itself before it exists. Software engineering solved this years ago with staging environments, where a change runs against a faithful copy of production before anyone trusts it. A version-controlled lineage graph gives the data estate the same machinery. Branch the model, apply the proposed change, and diff the branch against production to see what moves.

Royal London Asset Management (RLAM) plans change this way at scale. The firm, which manages £162.3 billion in assets, modeled its migration from thinkFolio and Murex to BlackRock Aladdin, alongside a cloud replatforming, as future states in Solidatus. The underlying graph spans 2,000 source tables and more than 175,000 fields, with 126 reports and 99,000 data attribute flows across 41 source systems.³ Version history and branching let the team assess candidate scenarios before committing, with downstream dependencies and the transformation path visible for each option.

Run the opening scenario through the same discipline, and the outcome changes. The feed consolidation exists as a branch before becoming a cutover. The diff lists the pricing model among the affected consumers with its owner attached, and the conversation about retraining happens before the change ships instead of three weeks after.

An impact analysis without owners is just a node list

A traversal that returns 40 downstream nodes has not yet answered anything a change board can use. Physical-only lineage tools stop there. The node list says which columns, jobs, and reports sit downstream. It does not say which of those reports carries a regulatory obligation, who owns the consuming application, or whose quarter is about to be ruined. Someone still has to do that archaeology by hand, and the ticket usually ships while they do it.

Business context converts the node list into a decision. When owners, policies, and regulatory obligations are shown on the same graph as the physical flows, the traversal returns the people to notify and the obligations at stake, rather than a set of node IDs. Large banks now run data governance as federated teams embedded in business units, and a shared impact analysis workflow lets a change proposed in one unit reach the right owner in another before it lands.

“The true brilliance of Solidatus lies in its capability to capture the physical aspects of data and seamlessly link them back to your catalogs and critical business information.”

— Lynn Watts, Head of Data Management and Governance, RLAM

One discipline for every author of change

AI systems now author changes as well as consume them. The Solidatus AI Lineage Assistant drafts mappings and proposes connections across the lineage model, enriching technical and business metadata as it works. Every proposal it makes is staged for validation, shown as a visual diff, and held for human approval before anything reaches production. An agent’s proposed change and an architect’s proposed change flow through the same gate, and the same pre-change impact computation evaluates both. As agentic tooling authors a growing share of the data estate’s changes, that single gate is how change review keeps pace with the volume of change.

Where to start

Three moves turn impact analysis from an aspiration into an operating practice.

1. Enumerate one production model’s upstream impact set at the column level. Pick the model whose output would be hardest to explain to an examiner and trace its inputs back to their sources. Where the enumeration stops, at a system no scanner reaches or a graph that goes no deeper than tables, you have found your truncation point, and most teams find it sooner than they expect. It marks the coverage to fix, not the boundary of your exposure, and closing it requires a lineage that pairs automated capture with modeled coverage for what automation cannot read.
2. Require a computed impact analysis on any change ticket that touches a shared feed. The feeds that many models and reports lean on are your aggregate-risk set, the same concentration SR 26-2 tells banks to manage. Attach owners and regulatory obligations to the computed result so the ticket names who to notify, which only works when the lineage is column-level, end-to-end, and carries business context.
3. Run your next migration as a future-state model first. Branch the lineage graph, build the target state, and diff it against production before anything moves. RLAM’s migration planning shows the pattern at full scale, and the same branching discipline works for a single feed consolidation.

If you would rather see the computation run against your own estate than read about it, ask for a technical demo or an architecture workshop, and bring the change ticket you are least sure about.

¹Board of Governors of the Federal Reserve System, FDIC, and OCC. “Supervisory Guidance on Model Risk Management.” SR Letter 26-2, April 17, 2026.
https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm.

²De Simoni, Guido. “Data Lineage Is Essential to Manage the Risks of Agentic AI.” Gartner, March 24, 2026. G00847339 (subscription required).

³Solidatus. “Royal London Asset Management Builds Operational Data Blueprint with Solidatus Data Lineage.” 2024.
https://www.solidatus.com/wp-content/uploads/2024/06/RLAM-Case-study.pdf.