Source escrow preserves access to deliverables when a supplier cannot provide agreed support. It works because the deposited artifact is the thing that produces the behaviour.
For a system whose behaviour depends on a hosted model, that assumption fails. The deposit contains application source, prompts, configuration, and tests. The model is not in it, cannot be put in it, and is the component most likely to disappear.
What the recovery trial reveals
A deposit containing application source and prompts, for an application depending on a hosted model that is no longer available, does not restore the original behaviour on release. The code builds. The service starts. The outputs are different.
The correct response is to record that limit and evaluate an authorised substitute against agreed questions — not to treat a successful build as evidence of continuity. Escrow guidance already treats these arrangements as tailored rather than automatic, covering release events, deposit updates, validation, version control, and cost, and identifying cases considered unsuitable. This is one of them, and saying so is more useful than depositing more source.
Lifecycle belongs to the provider
Model availability runs on a schedule the application does not control. Published lifecycle information distinguishes models with longer availability periods from short-term ones, lists retirement dates, and recommends testing mission-critical features during a replacement.
That means the provider dependency has a lifecycle beyond the application’s own release cycle, and a version identifier is not a guarantee of continued service. Neither a version lock nor an unchanged repository ensures continued operation.
The dependency record is therefore dated and owned: the resolved model and version where the platform exposes it, the endpoint, the SDK, prompts, tool schemas, output parsing, safety settings, retrieval inputs, sampling configuration, the owner, the notice channel, the announced retirement, and a tested fallback. Where the platform does not expose a resolved version behind an alias, that field says unknown rather than assuming stability.
And the account contact has to survive the transfer. An unread supplier notice is not a migration plan.
Abstraction helps and does not equalise
An abstraction layer isolates provider interaction behind an application-facing boundary. It addresses request compatibility. It does not make models interchangeable.
Five things stay separate: request compatibility, supported features, task behaviour, operating limits, and commercial and access conditions. Migration guidance is explicit that code regression and output-quality evaluation are different exercises, and that model-dependent security controls and regional availability are migration considerations in their own right.
The failure mode is an adapter that silently normalises away an unsupported capability. Two providers accepting the same normalised request object can return different structured-output failures and select different tools: the transport tests pass and the application task fails. An adapter should surface or reject an unsupported capability rather than invent a compatible result, and the requirement should not be quietly dropped to fit the common interface.
Fallbacks expire
Planning a response to a failed replacement means naming one of four outcomes: a still-supported and tested fallback, a narrower operating mode, manual handling where viable, or a deliberate stop.
The credibility condition is what gets forgotten. A fallback is credible only while its access, behaviour, and operating conditions remain supported by evidence — so the fallback carries its own review date, and an untested one recorded two years ago is a note.
Containment has limits worth stating in advance. An old hosted endpoint no longer exists. A database migration can change data irreversibly. A restored backup can reintroduce vulnerable software. How state, dependencies, and permissions affect recovery is part of the plan rather than a discovery during it.
The maintenance this implies
Dependency decay is the growing mismatch between a maintained service and its libraries, runtimes, APIs, models, tooling, and support arrangements. Model retirement is a concrete instance of it with a published date.
The process is inventory, urgency assessment, tested replacement, and post-rollout confirmation — the same structure as patch management, including verification that the change took effect and subsequent monitoring, and the same tradeoff between testing time and exposure.
The evaluation uses the same declared rules across the change, so that a behavioural difference is visible as a behavioural difference. A replacement accepting the same request shape while producing output that fails a downstream schema check on some tasks is a finding about the model, not about the transport.
And a provider’s recommended replacement is a candidate to assess. It does not transfer acceptance responsibility.
The rule
What stays fixed is that continuity requires a tested recovery path, not a deposited artifact. What changes is which component cannot be deposited, and for AI systems it is the one that determines the behaviour.
Not to be confused with
A release event. Escrow release makes assets available. Whether an operator can rebuild and run the system from them is a separate demonstration, and the acceptance record states what was actually recovered and what remained unresolved.
Portability. None of this establishes supplier-independent operation. Replacement effort and behavioural equivalence remain unverified until a replacement is actually evaluated against the declared tasks.