When the Model Changes and No One Documents It: The Provenance Problem

An enterprise AI system in production on the date a workout begins is rarely the system that was approved on the date it was procured. The gap between the two is populated by vendor-initiated model deprecations, default-model swaps, prompt revisions, retrieval-source changes, and integration expansions — most of them made without any formal notice to the customer.

None of this is misconduct. It is the normal operating cadence of a foundation-model market that treats the model layer as a rapidly iterating service, not a versioned asset. It is nonetheless a serious problem for anyone who needs to describe, value, defend, or unwind the asset the enterprise is carrying.

The chain-of-title analogue

The closest institutional precedent is the mortgage-note chain-of-title crisis that surfaced during the post-2008 workout of residential loan portfolios. Loans had changed hands, been re-securitized, and been serviced by parties whose paperwork did not always match the underlying note. Where the chain of title could not be reconstructed, foreclosure actions failed and portfolios were discounted.

AI provenance is the same problem in a different medium. If the enterprise cannot say which model, on which date, with which prompt scaffolding and which retrieval sources, produced the output that a customer relied on, then any decision that rests on that output — a refund liability, a compliance defense, a valuation, a sale — is exposed.

What silently changes

• The underlying foundation model, when a vendor deprecates a version or reroutes a default endpoint.
• The prompt scaffolding, when an internal team revises system prompts without a change record.
• The retrieval corpus, when documents are added, removed, re-indexed, or re-permissioned.
• The integration surface, when new tools, connectors, or agents are attached to the same assistant.
• The permission model, when identity and access controls change around the data the system can see.

Why after-the-fact reconstruction is hard

Provider-side logs are the natural first source. In practice they are frequently incomplete, retained on short windows, or not exposed at the granularity the reconstruction requires. Internal application logs may capture inputs and outputs but not the exact model version or the retrieval context. Prompt libraries are often edited in place. Change-control processes designed for conventional software rarely cover the layers that matter here.

The result is that reproducibility — the ability to re-run an old output and obtain the same result — degrades quickly. In many engagements, outputs older than a few months cannot be reproduced. Some can only be inferred. Some are unrecoverable. The reconstruction has to be defensible about which category each fact belongs to.

The valuation consequence

Enterprise software has historically been valued in part on the demonstrability of what it does. AI assets without a provenance record fail that test. In sale, restructuring, and impairment scenarios, buyers and auditors alike discount for provenance uncertainty — often more heavily than for the technical or contractual uncertainty that receives more attention.

The remediation is the same as it was after 2008. Reconstruct the chain of title. Document what is confirmed, what is inferred, and what is unrecoverable. Take the workout decision the reconstructed record supports, not the one the original business case assumed — the six-disposition framework is the discipline the reconstructed record enables.