The notice is rarely a lawsuit
The way a data dependency actually fails is undramatic. An email arrives from an account manager. The renewal terms have changed. The per-seat model is now per-call, or the license carves out machine learning training as a separate right, or the field you depend on is being deprecated at the end of the quarter, or the provider was acquired and the acquirer sells to your largest competitor. Nobody breached anything. There is no dispute to escalate. There is a date, and after that date the thing you built on is not there in the form you built on it.
Three weeks later, someone in engineering discovers that the model in production was trained on a corpus nobody kept a copy of, that the copy they do have is under a license that permitted evaluation and not retention, and that the feature which drives forty percent of the model's signal has no substitute in any source the company already holds. That is the real incident. It is a supply chain failure wearing the costume of a contract renewal, and it takes six to fourteen months to work through if the groundwork was not laid.
This is now a common enough shape that it deserves a named playbook rather than an improvisation. What follows is the failure mode in detail, what each version of it costs, and the specific engineering and contract work that turns a company-stopping event into a quarter of managed inconvenience.
How data dependencies break — relative frequency of the trigger
Editorial weighting from public sources and practitioner reading. Illustrative, not a measured statistic. Note that outright termination for cause is not on the list.
Four kinds of disappearance, priced differently
Treating all of these as one risk is the mistake that leads to one generic mitigation that fits none of them. They fail differently and cost differently.
Repricing is the mildest and the most common. The data still exists, the terms still permit what you do, and the bill went up by a factor. This is a margin problem, not an engineering problem, unless the new price is above the value the feature produces. The countermeasure is knowing that number before the negotiation, which almost nobody does.
Restriction is where the data keeps flowing but a use you depend on stops being permitted. The clause that matters is usually the one that separates "use" from "train." A license written in 2021 that said nothing about machine learning is being renewed in 2026 with an explicit carve-out, and the model you trained under the old agreement is now a derivative work of uncertain standing. The data has not gone anywhere. Your right to have used it that way has.
Deprecation is partial disappearance. The feed continues, but a field is removed, an identifier scheme changes, or historical depth is truncated to two years. Deprecation is the version that most often goes undetected until model performance drifts, because the pipeline keeps running and the nulls look like data.
Termination is the full stop. Acquisition and sunset, an upstream rights failure that forces a withdrawal, or a jurisdictional restriction. This is the version people imagine and the least frequent one, and it is the only one where having a retained copy is not itself the whole answer, because retention rights usually end when the agreement does.
The question that has to be answerable in an afternoon
Before any mitigation is worth designing, one thing has to be true: somebody can say, in a single afternoon and without a meeting, exactly what stops working if a named provider goes dark tomorrow. Most companies with a real data dependency cannot do this. The knowledge is distributed across a procurement folder, a terraform file, three notebooks, and one engineer's memory.
The artifact that fixes it is a dependency register, and it is boring on purpose. One row per external data source. For each: the contracting entity and the actual signed instrument, the renewal and termination dates with notice periods, the specific rights granted for use, retention, derivative works, and training, the systems and models that consume it, the fields consumed rather than the whole feed, whether a retained copy exists and under what right, and the named substitute if there is one. Two weeks of work for a company with a dozen sources. It is the cheapest insurance in the whole discipline, and it is the document a diligence team, an auditor, or a model risk function asks for first.
The register also settles arguments about scope. A feed with fourteen fields where you consume three is a different exposure from one where you consume all fourteen and joined them into a derived key. The second is often unrecoverable by substitution and the first frequently is not, and nobody knows which case they are in until the fields are written down.
What the model actually remembers
A trained model is a form of retention that most licenses did not anticipate. The weights are not the data, but they were produced from the data, and the question of whether a model trained under a lapsed license may continue in production is genuinely unsettled in a way that makes counsel nervous and should.
The practical posture that survives review has three parts. Keep the training corpus separable, so the contribution of each source is identifiable rather than blended irreversibly into one pile. Keep the training pipeline reproducible, so a model can be rebuilt from a defined input set rather than existing only as an artifact whose provenance is a story. And record, per model version, which sources under which agreement versions produced it. That last item is one column in a model registry and it is the difference between answering the question in an hour and answering it in a forensic project.
Financial institutions have had a version of this discipline for years. The Federal Reserve and OCC guidance on model risk management, SR 11-7, requires that model inputs be documented, that data quality and relevance be assessed, and that models be capable of being validated by someone who did not build them. A model that cannot be rebuilt cannot be independently validated. ISO/IEC 42001, the AI management system standard, pushes the same direction for organizations outside banking, and the NIST AI Risk Management Framework's Map function asks for exactly this provenance record. The frameworks converged because the underlying problem is the same one.
Retention rights are a negotiation, not a technicality
The single highest-leverage clause in a data agreement is the one covering what happens to data already received when the agreement ends. Most standard forms say it is deleted or returned. That default is what turns a repricing into an emergency, because it means the company has no fallback position at all and the provider knows it.
Three variations are worth asking for, and providers grant them more often than buyers expect because none of them cost the provider ongoing revenue. A wind-down right: continued use of data already received for a defined period after termination, commonly six to twenty-four months, sometimes at a stepped-down fee. A derivative survival clause: models, aggregates, and derived features built during the term survive termination even though the underlying records do not. And a historical archive right: retention of the data received during the paid term, for internal use, in perpetuity or for a long fixed period.
The third is the one that changes the character of the relationship most, because a buyer who holds five years of history is negotiating a renewal about future increments rather than about existence. That is a different conversation and it prices differently.
Recovery time by preparation level — when a primary source is lost
Ranges reflect time to a validated production model on a replacement source, not time to first ingest. Illustrative, not a measured statistic.
Escrow works for software and mostly does not work for data
Source code escrow is a mature instrument. A third party holds a copy, release conditions are defined, and the buyer gets something usable if the vendor fails. People reach for the same structure with data and are disappointed for reasons worth understanding before spending on it.
Code is small, static, and self-describing. Data is large, continuously updated, and useless without the transformation logic and reference tables around it. An escrowed snapshot of a feed is stale the day after deposit, and a release condition triggered by bankruptcy does not fire on the far more common events of repricing, restriction, and acquisition. Worse, the escrow agreement usually grants a license to use the deposit only under the release conditions, which means the buyer still cannot verify that what is in the vault is complete and loadable.
The structure that does work is a retained rolling archive under the primary agreement rather than a third-party deposit. The buyer receives and keeps the data continuously, under a retention right negotiated at signing, and periodically proves it can rebuild a model from the archive alone. Verification is the part that gets skipped and the part that matters. An untested archive is an assumption with a storage bill attached.
Substitution: the work you do before you need it
The expensive part of losing a source is almost never the ingest. It is the equivalence work. A replacement source has different coverage, different update cadence, different identifier scheme, different definitions of the same-sounding field, and different error characteristics. A model retrained on it does not perform the same, and proving what changed takes longer than building the connector.
The preparation that collapses that timeline is a shadow evaluation. Pick the two most plausible substitutes for each critical source. Ingest a sample. Build the identifier crosswalk on that sample and measure the match rate. Retrain the model on the substitute and record the performance delta. This is roughly two to five weeks of engineering per source and it produces three durable things: a known match rate, a known performance delta, and a connector that has already run.
It also produces leverage. A renewal negotiation where the buyer has measured the alternative and can state what switching costs is a different negotiation from one where the buyer is guessing. That single fact frequently pays for the shadow evaluation before any disruption happens at all.
Designing so the swap is small
Most of the pain in a source migration is caused by architecture decisions made years earlier that felt harmless. Vendor field names propagated straight through to warehouse columns and model features. Vendor identifiers used as primary keys in tables nobody wants to rewrite. Vendor-specific handling scattered across twelve transformations instead of one.
Three properties keep the blast radius small, and each is cheap when built and expensive to retrofit. First, an internal canonical schema: every source maps into a company-defined shape at the boundary, and nothing downstream ever sees a vendor field name. Second, internal entity identifiers, with vendor identifiers held as attributes in a crosswalk table rather than as keys. Third, source attribution at the row level, so the exact records and the exact model features touched by one provider can be listed by a query instead of estimated in a meeting.
A system with those three properties treats a source change as a boundary change. A system without them treats it as an archaeology project. The gap between those two is the six-to-fourteen months, and it is decided long before the notice arrives.
What changes when government is in the picture
If the system touches a federal customer, the data rights framework governs rather than the vendor's preferred terms. DFARS 252.227-7013 covers technical data, 252.227-7014 covers noncommercial computer software, and 252.227-7017 requires that restrictions be asserted before award rather than discovered afterward. A third-party dataset embedded in a deliverable, without the rights to let the Government exercise what the contract says it gets, is a problem that surfaces at delivery when it is most expensive.
Two additional constraints show up regularly. Data carrying controlled unclassified information brings handling obligations under 32 CFR Part 2002 and the NIST SP 800-171 control set, and those obligations follow the data into a training pipeline and into whatever holds the retained archive. And OMB Memorandum M-25-22 on AI acquisition puts vendor lock-in and interoperability near the front of what agencies are expected to manage, which means the question of what the Government holds if a data provider disappears is increasingly asked during evaluation rather than after award.
The order to do this in
For a company with real exposure and no current program, the sequence that produces the most protection per dollar is fixed. Build the dependency register first, because every other decision needs it and it takes two weeks. Then read the retention and derivative clauses in the three largest agreements and find out what you are actually permitted to keep, which is frequently not what people believe. Then start the rolling archive where the rights already allow it, and put the retention right on the negotiation list where they do not.
Then make the training pipeline reproducible and record source provenance per model version, which is the work that makes every later question answerable. Then run the shadow evaluation on the single most critical source. Then bring the canonical schema and identifier work into the normal roadmap rather than treating it as a project. Six steps, one to two quarters at a normal pace, and the exposure at the end is a different order of magnitude from the one at the start.
Bottom line
Data dependency risk is not managed by trusting the provider, and it is not managed by a clause alone or a copy alone. It is managed by knowing precisely what you consume, holding a retained copy you have proven you can rebuild from, having measured at least one substitute, and building so that a source swap is a change at the boundary instead of a rewrite through the middle. The company that has done that work receives the same email as everyone else and treats it as a procurement decision. The company that has not receives the same email and spends a year on it.
Frequently asked questions
It depends entirely on the derivative-works and retention language in the specific agreement, and standard forms usually do not address models at all. The durable fix is a survival clause negotiated at signing that says derived models and aggregates persist after termination even when the underlying records do not.
Rarely, on its own. Release conditions typically trigger on insolvency, while the common failures are repricing, restriction, and acquisition. A retained rolling archive under the primary agreement, verified by an actual rebuild, covers more scenarios for less money.
Two to six weeks with a register, a retained archive, and a tested substitute. Six to eighteen months with no retained copy and unrecorded model provenance. The connector is a small part of either number; the equivalence and revalidation work is most of it.
A retention right for data received during the paid term, explicit permission for model training and derived features, survival of derivatives after termination, a wind-down period of at least twelve months, and advance notice on field deprecation. Providers grant these more often than buyers assume, because none of them cost ongoing revenue.
Assert on semantics at the ingest boundary, not only on types. Track null rate, distinct-value count, and distribution per field per load against a historical band, and fail loudly on drift. A removed field usually arrives as nulls that pass every type check and quietly degrade a model for a quarter.