Provenance Without Portability Is Not Provenance. It's a Rental.

Residency was never the ownership test. A decision corpus that cannot be queried once the vendor's runtime is gone is not an asset — it is a rental, and it dies from the past forward.

---

What follows extends a practitioner hypothesis from Essay I, incorporating a public correction directly rather than around it: stated with enough precision to be falsified, and intended to be.

EDITOR'S NOTE, V1.0

A public comment on Essay I's Palantir analysis, from Dr. Monika Mkhitaryan (Chief Strategy Officer, Malogica Group), sharpened the central claim of this essay and is credited directly. Her argument: Foundry and AIP deploy on-premises and air-gapped, so the residency objection Essay I raised does not hold. But residency was never the right test.

The corpus can sit inside the organisation's own building and still not become the organisation's asset. The deciding condition is whether the decision records stay readable once the vendor's runtime is gone. If a company cannot query its decision records without the vendor, it does not own them.

That test — ownership as query-independence from the vendor rather than location of the bytes — is the spine of this essay.

ABSTRACT

Essay I established that enterprise systems record what happened but not why it was decided, and named decision time a third temporal axis beyond ANSI SQL:2011's valid- and transaction-time axes.²⁷ It closed by asking what that absence costs at the point of AI training. This essay answers that question, and corrects its own prior argument in doing so. Essay I's residency objection to Palantir Foundry was wrong: Foundry deploys on-premises and air-gapped, through Apollo. Residency was never the test. Ownership is determined by whether records remain queryable once the vendor's runtime is withdrawn, a distinction independently codified in GDPR Article 20⁶ and the EU Data Act's functional-equivalence requirement.⁷ A corpus that requires a vendor's runtime to be read is not an asset. It is a rental, and every rental terminates on the landlord's schedule, not the tenant's.

This essay argues the same mechanism that makes decision records untrainable also makes them differentially mortal: runtime dependency and format obsolescence destroy a corpus unevenly. They destroy it from the past forward, because older records accumulate more points of failure — migrations, format translations, retired software versions — before a training run or audit reaches them. The result is a corpus that appears complete but is silently truncated toward the recent, not because recent decisions matter more but because they have had less time to be forgotten. This compounds, rather than corrects, a cognitive bias with a two-thousand-year paper trail.¹³ The essay distinguishes this infrastructural mechanism from recency bias and the recency effect, often wrongly treated as interchangeable, presents survey evidence on its scale,²⁴²⁵²⁶ and closes with four falsifiable conditions for revision.

Keywords: data portability, vendor lock-in, decision provenance, AI fine-tuning, recency bias, catastrophic forgetting, digital preservation, EU Data Act, GDPR Article 20

1. THE CORRECTION ESSAY I OWES

Essay I argued that Palantir Foundry and AIP do not support on-premises or air-gapped deployment, and used that claim to dismiss Foundry as a candidate for holding decision provenance. Dr. Monika Mkhitaryan identified the error in a public comment. She was right, and the correction has already been made to Essay I directly. Foundry and AIP deploy on-premises and in air-gapped networks through Apollo. The residency objection does not apply.

What she added is more consequential than the correction itself. Essay I's fallback argument — that even with residency solved, Foundry's decision writeback pattern is a customer-configured design pattern rather than a native schema — was correct but incomplete, because it implied residency was at least a partial answer, with the schema gap as the remaining problem. Dr. Mkhitaryan's comment removes that implication entirely:

The corpus can sit inside the organisation's own building and still not become the organisation's asset. The deciding condition is whether the decision records stay readable once the vendor's runtime is gone. I would put the ownership test there rather than on residency controls, which govern where data rests and say nothing about what can read it. If a company cannot query its decision records without the vendor, it does not own them.

This is not a softer version of the residency argument. It is a different argument, and a stronger one, because it survives every case that defeats the residency argument. An organization can deploy fully on-premises, in an air-gapped facility it owns outright, with data that never touches a vendor's cloud, and still fail the ownership test, if the only thing capable of interpreting that data as decisions is software the organization licenses rather than possesses. Residency answers where the data sits. It says nothing about what happens the day the license lapses, the contract isn't renewed, or the vendor discontinues the product line.

The test Essay I should have used from the start is: can the organization query its decision records without the vendor's runtime present. This essay is built on that test.

2. RUNTIME DEPENDENCY IS NOT A PALANTIR PROBLEM

It would be convenient, and wrong, to treat this as a critique of one vendor. Palantir's own documentation confirms that structured data exports from Foundry to CSVs and databases are straightforward;¹¹ the residency and raw-export objections both fail, and should. What does not export cleanly is what this essay will call the semantic layer: the ontology and executable logic (object types, link types, action types, and the business rules bound to them) that render a raw record legible as a decision rather than a row. Palantir's own documentation on Foundry's interoperability model confirms this layer is a customer-configured construct built on Palantir's proprietary representation, not an export of an open standard.¹¹ There is no OWL file to write out and hand to a competing platform, because the semantic and executable logic that makes the data legible as a decision is bound to the runtime that interprets it. An organization that migrates away from Foundry keeps its action log. It does not keep the judgment.

The same structure recurs wherever decision logic and decision data are fused inside a single vendor's execution environment, which is nearly everywhere in current enterprise AI tooling. A fine-tuned model hosted through a commercial API is not something the customer can download and run elsewhere: the accessible surface is the API, not the weights.³ An organization that has spent a year having its decisions interpreted, scored, and refined by a vendor-hosted model owns the inputs it uploaded and the outputs it received. It does not own the trained artifact that did the interpreting, and cannot extract it, because the platform was never built to be left.

This is not a defect anyone concealed. It is the ordinary shape of a runtime-bound product, and it is well understood in the vendor-lock-in literature that predates AI by decades.⁴⁵ What has changed is the stakes. A locked mainframe migration in 1997 cost an organization money and time.⁵ A locked decision corpus in 2026 costs an organization the one asset that was supposed to compound: the record of its own judgment, structured well enough to train on.

The Foundry characterization above reflects capabilities as of mid-2026, confirmed directly against Palantir's own product documentation rather than third-party commentary. The underlying principle — that a semantic layer bound to a vendor's runtime is not the same asset as the data it interprets — does not depend on Foundry's specific feature set and should be re-checked against current documentation before being cited as a standing fact about any named vendor.

THE OWNERSHIP TEST

Residency governs where data rests. Query-independence governs what can read it.

Resident on own infrastructure	Query-independent: NO	Query-independent: YES
YES	Rented — residency without portability. Data sits on the organization's own infrastructure, but only the vendor's runtime can interpret it as decisions. Ownership is an illusion of location. Palantir Foundry via Apollo: on-prem, semantic layer runtime-bound.	Owned — residency + portability. Data sits on organization infrastructure and remains fully queryable without the vendor's runtime. This is the rare case.
NO	Exposed — neither residency nor portability. Data lives off-site and only the vendor's runtime can read it. No control at any layer. Hosted fine-tuned model: API-only access.	Governed — portability, not residency. Data lives off-site but exports in an open format that stays readable independent of the vendor. GDPR Art. 20 and the EU Data Act's "functional equivalence" target this quadrant.

Figure 1. The ownership test: residency governs where data rests; query-independence governs what can read it. Foundry via Apollo sits in the "Rented" quadrant: resident, not portable.

3. THE PRECONDITION ARGUMENT

Essay I closed by naming the question this essay answers: what does the absence of decision provenance cost at the point of AI training. The honest answer is not a cost. It is a precondition failure.

Fine-tuning a model on an organization's own decision history requires that history to exist as an extractable, structured corpus before training can begin.¹² This is not a preference among engineering approaches; it is the mechanical shape of the task. An organization cannot fine-tune on decisions it can only access by querying a vendor's hosted interface, for the same reason it cannot fine-tune on a conversation it is having rather than has had: training requires a corpus, and a corpus requires extraction.

Return to Essay I's own example. A procurement team, mid-disruption, switches a primary supplier: the three alternatives evaluated, the risk scores available at the time, the executive who approved the deviation, and the reasoning that weighted speed over cost, all captured in a decision-support platform's writeback layer. Three years later, that platform's contract comes up for renewal on worse terms and the organization migrates to a competitor. The transaction survives the migration as a CSV row: supplier changed, timestamp, user ID. The decision record — the alternatives, the authority level, the evidence state, the expected outcome — does not, because it existed only as an interpreted object inside the first vendor's ontology. Two years after that, someone tries to fine-tune a supply-risk model on five years of the organization's sourcing decisions. The model trains on two years of fully structured, richly reasoned records and three years of bare transactions with the judgment missing. Nobody decided to lose those three years. The runtime that made them legible as decisions was simply no longer running by the time anyone needed them for anything beyond the original transaction log.

This is not a hypothetical edge case. Survey data collected across 2026 puts firm numbers behind it: two in three enterprises have already attempted to migrate between AI platforms, and more than half of those migrations either failed outright or required significantly more effort than expected.²⁴ Half of enterprise technology leaders cite vendor lock-in as a critical or major issue,²⁵ and the overwhelming majority of IT professionals report concern about it, with nearly half describing that concern as significant.²⁶ The precondition failure described above is not a rare misfortune. It is close to the median experience of an organization that has tried to move.

A decision record that exists only as a live query against a vendor's runtime is not a degraded training asset. It is not a decision-provenance training asset. The precondition for training was never met, and prompt engineering or API access does not recover it, because neither produces the thing training requires: weights updated on the organization's own structured judgment history, owned and retrainable independent of the vendor that hosted the interaction. Retrieval-augmented generation does not escape this either, and arguably has less room to: a RAG system queries the corpus live rather than baking it into weights once, which makes query-independent, portable access to that corpus a harder requirement, not a softer one. A RAG pipeline pointed at a vendor's runtime is exactly as rented as a fine-tuning pipeline would be, it just fails on every query instead of once at training time.

This reframes the stakes of Section 2. The schema gap in Foundry's writeback pattern and the runtime-boundedness of a hosted fine-tuned model are not two separate problems. They are the same problem at two points in the pipeline. Upstream, the decision was never captured in a structured, portable schema. Downstream, even if it had been, the model trained on it would not be extractable either. An organization can fail the ownership test twice, once on the way in and once on the way out, and the migration data above suggests this is common rather than exceptional,²⁴²⁵²⁶ because nothing in the current enterprise AI stack was built to prevent either failure.

4. WHAT THE TEST LOOKS LIKE WRITTEN DOWN

Dr. Mkhitaryan's ownership test is not a novel legal theory. It is the practical form of a distinction that data-portability law and policy research have been converging on for years, independently of this essay, which is itself evidence the test is the right one rather than a rhetorical convenience.

The GDPR's Article 20 right to data portability requires that personal data be provided in a structured, commonly used, machine-readable format.⁶ Regulatory guidance is consistent on the point that a PDF scan or a proprietary export locked to the originating vendor's software does not satisfy this. The standard is not "the data left the building." It is "the data arrived somewhere else usable."

The EU Data Act goes further and closer to Dr. Mkhitaryan's language than any other source found for this essay.⁷ Cloud and data-processing providers must remove obstacles to switching and, for infrastructure services, help the customer achieve functional equivalence on the replacement platform: not a data dump, but the ability to actually operate once the vendor is gone. Functional equivalence is, in statutory form, query-independence from the original vendor.

The Information Technology and Innovation Foundation's 2026 analysis of cloud sovereignty policy arrives at nearly the same sentence Dr. Mkhitaryan wrote independently: server location is not sovereignty, and domestic or on-premises ownership is a weak proxy for actual control.⁸ The report's structural control layer is defined by whether an organization can switch providers, and names the absence of portability as what turns dependence into "a constraint on future decisions"⁸, language that could sit directly inside this essay's argument about decision records without alteration.

The OECD's and FTC's independent work on data portability and interoperability as distinct competition-policy tools reaches the same underlying distinction from a market-structure angle rather than a data-architecture one: portability alone is a one-off extraction right, while sustained interoperability is what actually prevents lock-in from reasserting itself.⁹¹⁰ None of these sources were written about decision provenance. They were written about cloud infrastructure, personal data rights, and platform competition policy. That they converge, independently, on the same test Dr. Mkhitaryan proposed for decision records is the strongest evidence available that residency was always the wrong question, in every domain it has been asked, not only this one.

5. THE MECHANISM: WHY THE OLD RECORD DIES FIRST

Runtime dependency does not merely make a decision corpus untrainable in the moment. It makes the corpus decay unevenly over time, and it does so in a specific direction: backward.

Consider what a decision record survives between the moment it is written and the moment someone tries to train on it or audit it. A schema migration. A vendor contract renewal, or non-renewal. A platform version upgrade that deprecates the query interface the record depended on. A reorganization that moves ownership of the system to a team without the institutional memory of how to read it. Each of these events is a point of failure specific to runtime-bound records, because a portable, open-format record does not care which vendor's software last touched it. A runtime-bound record does. This is the same reason Essay I, following Kleppmann,²⁸ argued the event log rather than current state is the durable ground truth: an event log survives precisely because it does not depend on any one system's runtime to remain interpretable, and a decision record bound to a vendor's ontology has exactly the opposite property. Every year a decision record sits unmigrated inside a vendor's proprietary interpretation layer is another year in which one of these failure points might occur, and once it occurs, the record does not become slightly harder to read. It becomes unreadable, in the same way a WordStar file from 1989 is not degraded text, it is bytes with no interpreter left willing to run them. This is the oldest documented failure mode in digital preservation, and it has a name: digital information lasts forever, or five years, whichever comes first.²⁰

The consequence is a selection effect, not a random loss. A decision corpus assembled today from what actually survives inside a runtime-dependent system will systematically over-represent recent decisions, not because recent decisions are more important, but because they have accumulated fewer opportunities to be orphaned by a migration, a version deprecation, or a vendor exit.²¹ The corpus that looks complete is quietly truncated from the back, and the truncation point moves forward every year, silently, without anyone deciding it should.

CORPUS SURVIVAL: PORTABLE VS. RUNTIME-DEPENDENT DECISION RECORDS

Years since decision was recorded	Portable, open-format record	Runtime-dependent record
0	100	100
1.5	98	98 → 80
3.2	95	80 → 60
5	92	60 → 38
7.5	88	38 → 20
10	86	18

Figure 2. Portable, open-format records decay slowly and evenly. Runtime-dependent records step down at each migration, contract non-renewal, and version deprecation: losing the oldest records first.

This is an infrastructural mechanism, and it is important to keep it precisely distinct from a psychological one, because the two are easy to conflate and conflating them would be exactly the kind of imprecision Essay I's falsifiability standard exists to prevent. Recency bias, the cognitive bias that gives disproportionate weight to recent events in judgment, is well documented from Livy's observation that readers hurry past early history toward modern times,¹³ through its contemporary appearance in employee evaluations and investor behavior, where it skews decision-makers toward assuming a recent trend will continue. It is also directly relevant to sequential decision-making itself: belief-adjustment research shows decision-makers processing evidence step by step tend to overweight whatever arrived most recently, effectively tracking a moving average rather than integrating all evidence equally.¹⁶ Recency bias is distinct from the recency effect, the narrower finding from serial-position memory research that items presented last in a sequence are recalled better,¹⁴¹⁵ which is a memory phenomenon, not a judgment distortion. And both are distinct from recency illusion, the mistaken belief that a word or usage is newly coined when it is in fact old, which belongs to linguistics and has no bearing on this argument at all. Essay I held itself to a standard of not conflating adjacent technical terms. This essay holds itself to the same standard for adjacent psychological ones.

What this essay claims is narrower and more specific than any of the three: that runtime dependency and format obsolescence function as an infrastructural analogue to recency bias, producing the same skew toward the present through an entirely different mechanism, one made of migrations and license terminations rather than neurons. The two compound. A decision-maker already inclined to over-weight recent evidence,¹⁶ drawing on a corpus that has already lost a disproportionate share of its older records to runtime attrition, is reasoning from a sample that confirms the bias by construction. The corpus does not correct the bias. It launders it.

6. THE SAME PATTERN, RESTATED IN MACHINE LEARNING: TWO DISTINCT MECHANISMS, NOT ONE

The parallel is not merely poetic, but it is two separate parallels, not one, and the distinction matters enough to state precisely.

The first mechanism applies to any static-corpus model the moment time moves past its training cutoff, which happens immediately and continuously in production. Language models trained on a fixed corpus measurably degrade at predicting content that falls outside their training period, and the degradation is not symmetric: models perform increasingly worse the further a query falls past the end of what they were trained on.¹⁷¹⁸ This is a direct technical demonstration that a model trained once and left alone has a shelf life, not a permanent competence, regardless of how good the training corpus was at the moment of training. The practical consequence is that staying accurate requires retraining on a rolling basis, not training once. That requirement is precisely what routes an organization into the second mechanism below.

The second mechanism applies specifically to continual or incremental retraining done on new data alone rather than the full accumulated corpus, a common but not universal pattern for organizations that retrain their decision-support model periodically as new decisions accumulate, rather than training once and stopping or replaying the full history on every retrain. Here the relevant finding is catastrophic forgetting: neural networks overwrite the synaptic weight patterns encoding older knowledge when trained on new data, unless something is specifically done to protect them.¹⁹ This does not describe what happens within a single static-corpus fine-tune; it describes what happens across a sequence of them, and specifically a sequence where each step trains on the delta rather than the whole. Retraining on the full accumulated corpus each cycle avoids this mechanism, at the cost of the compute and time that made incremental retraining attractive in the first place. Where the cheaper, incremental pattern is used, the implication is uncomfortable: the organizations most committed to keeping their model current are, without specific mitigation, the ones most exposed to systematically erasing their own institutional past with every retrain.

Put the two mechanisms next to Section 5's argument and a causal chain emerges, not three independent coincidences. A decision corpus assembled from runtime-dependent enterprise systems is already skewed toward the recent before a single model is trained on it. Whatever model is trained on that corpus then decays on its own shelf-life clock, per the first mechanism, which forces retraining to stay current. If that retraining is done the cheap way, on new decisions alone rather than the full accumulated corpus, the second mechanism applies and the model's internal representation of older decisions erodes further, on top of the erosion already done to the source corpus by attrition. None of this was designed as a system. Each step is a locally reasonable response — extract what's readable, retrain to stay current, retrain cheaply — that compounds into a corpus and a model both biased toward the present, for reasons that have nothing to do with the present mattering more.

7. WHAT RENTAL ACTUALLY COSTS

Return to the abstract's claim. Provenance without portability is not provenance. It is a rental, and every rental terminates on the landlord's schedule.

The cost is not a single failure at a single moment, the way a data breach or an outage is. It is a compounding one, invisible in any given quarter and severe over a multi-year horizon, and the survey data in Section 3 suggests it is already the median rather than the exception: most enterprises that have tried to leave an AI vendor have already hit this cost directly, whether or not they had a name for it.²⁴²⁵²⁶ Every year a decision corpus remains inside a runtime-dependent system without a portable, open-format export is a year in which the corpus's oldest records become slightly more likely to be one migration away from unreadable, is a year in which the organization's eventual training run will draw on an increasingly recency-skewed sample, and is a year in which the organization has paid for infrastructure that will, on its own schedule and not the organization's, eventually hand back data without the judgment.

This is the throughline from Essay I. Essay I argued that no current enterprise system holds decision provenance natively. This essay argues that even the systems positioned as the closest approximation, deployed under the most favorable conditions Essay I could name — on-premises, air-gapped, fully residency-compliant — still fail a sharper test: not where the data sits, but whether the organization can read it without the landlord. And the records most at risk of failing that test silently, without anyone noticing until they are needed, are the oldest ones: exactly the ones a training run or an audit most needs, and exactly the ones a rental was never built to keep.

8. WHAT WOULD INVALIDATE THIS

[F1] Show a vendor, including Palantir via Apollo, that exports a decision record's full semantic layer (the ontology and executable logic that render the record legible as a decision, as defined in Section 2) in an open, self-describing format that remains queryable with the vendor's runtime absent, and the rental claim fails for that vendor.

[F2] Show that fine-tuning or equivalent training can be performed directly against in-place vendor-runtime data without first extracting the semantic layer into a portable corpus. This is a distinct claim from F1, since F1 is about exportability and F2 is about whether extraction is even necessary, and the precondition argument in Section 3 fails.

[F3] Show, through an audit of a real enterprise decision corpus, that the age distribution of surviving records matches the age distribution of records originally created, with no disproportionate loss of older records, and the infrastructural recency mechanism in Section 5 fails.

[F4] Show an organization that achieved genuine query-independence from its vendor through residency controls alone, without open export formats or functional equivalence guarantees, and the distinction this essay draws between residency and portability collapses.

If any of these can be demonstrated, this essay requires revision. That is not a hedge. It is the standard Essay I set, and this essay is held to it.

9. WHERE ESSAY III GOES

This essay has argued that decision provenance fails twice: once when it is never captured in a portable schema, and again when the systems that do capture something render it unreadable the moment the vendor relationship ends, with the oldest and most consequential records failing first and most silently. Essay III examines what this costs not at the point of training, but at the point of accountability: what happens when an organization is asked, after the fact, to produce the reasoning behind a decision it can no longer read.

REFERENCES

1. [1]Mathav Raj J., Kushala V.M., Warrier, H., Gupta, Y., Fine Tuning LLM for Enterprise: Practical Guidelines and Recommendations, arXiv:2404.10779, 2024. https://arxiv.org/pdf/2404.10779↩
2. [2]Strategic Decision Framework for Enterprise LLM Adoption, arXiv:2511.18589, 2025. https://arxiv.org/pdf/2511.18589↩
3. [3]Stanford Research Computing, Fine-Tuning Open Source Models, RCpedia, Nov 7, 2025. https://rcpedia.stanford.edu/blog/2025/11/07/fine-tuning-open-source-models/↩
4. [4]Opara-Martins, J., Sahandi, R., Tian, F., "Critical analysis of vendor lock-in and its impact on cloud computing migration: a business perspective," Journal of Cloud Computing, 5:4, 2016. https://link.springer.com/article/10.1186/s13677-016-0054-z↩
5. [5]Greenstein, S., "Lock-in and the Costs of Switching Mainframe Computer Vendors: What Do Buyers See?," Industrial and Corporate Change, 6(2), 1997.↩¹↩²
6. [6]Regulation (EU) 2016/679 (GDPR), Article 20: Right to data portability. https://gdpr-info.eu/art-20-gdpr/↩¹↩²
7. [7]Regulation (EU) 2023/2854 (Data Act), Chapter VI, Articles 23-31.↩¹↩²
8. [8]Zhang, L., From Sovereignty to Control: A Clear-Eyed View of Canadian Cloud Policy, Information Technology and Innovation Foundation, Apr 27, 2026. https://itif.org/publications/2026/04/27/from-sovereignty-to-control-a-clear-eyed-view-of-canadian-cloud-policy/↩¹↩²
9. [9]OECD, Data Portability, Interoperability and Digital Platform Competition, OECD Competition Committee background note, June 9, 2021.↩
10. [10]Federal Trade Commission, Data To Go: The FTC's Workshop on Data Portability, staff summary, 2020/2021. https://www.ftc.gov/system/files/documents/public_events/1568699/data-portability-workshop-summary.pdf↩
11. [11]Palantir Technologies, Ontology Manager: Export, edit, and import an Ontology, product documentation. https://www.palantir.com/docs/foundry/ontology-manager/export-import (confirms Ontology schema exports only as a Foundry-proprietary JSON file, re-importable to Foundry, not to a W3C-standard OWL/RDF/SPARQL format another platform could reason over)↩¹↩²
12. [12]Moreau, L., Missier, P. (eds.), PROV-DM: The PROV Data Model, W3C Recommendation, 30 April 2013. https://www.w3.org/TR/prov-dm/
13. [13]Livy, History of Rome, Preface, 1st century BC.↩¹↩²
14. [14]Murdock, B.B., "The serial position effect of free recall," Journal of Experimental Psychology, 64(5):482-488, 1962.↩
15. [15]Glanzer, M., Cunitz, A.R., "Two storage mechanisms in free recall," Journal of Verbal Learning and Verbal Behavior, 5(4):351-360, 1966.↩
16. [16]Hogarth, R.M., Einhorn, H.J., "Order effects in belief updating: The belief-adjustment model," Cognitive Psychology, 24(1):1-55, 1992.↩¹↩²
17. [17]Lazaridou, A. et al., Mind the Gap: Assessing Temporal Generalization in Neural Language Models, NeurIPS 2021, pp. 29348-29363. https://proceedings.neurips.cc/paper/2021/hash/f5bf0ba0a17ef18f9607774722f5698c-Abstract.html↩
18. [18]Dhingra, B. et al., "Time-Aware Language Models as Temporal Knowledge Bases," Transactions of the ACL, 10:257-273, 2022. https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00459/↩
19. [19]Kirkpatrick, J. et al., "Overcoming catastrophic forgetting in neural networks," PNAS, 114(13):3521-3526, 2017. https://www.pnas.org/doi/10.1073/pnas.1611835114↩
20. [20]Rothenberg, J., "Ensuring the Longevity of Digital Documents," Scientific American, 272(1):42-47, 1995.↩
21. [21]Digital Preservation Coalition, Digital Preservation Handbook: File formats and standards. https://www.dpconline.org/handbook/technical-solutions-and-tools/file-formats-and-standards↩
22. [22]Walsh, J.P., Ungson, G.R., "Organizational Memory," Academy of Management Review, 16(1):57-91, 1991.
23. [23]De Long, D.W., Lost Knowledge: Confronting the Threat of an Aging Workforce, Oxford University Press, 2004.
24. [24]Zapier, Inc. (Flanigan, R.), Nearly 3 in 4 enterprises say losing AI vendors would disrupt core business operations, Apr 1, 2026. Survey via Centiment, n=542 U.S. C-level/decision-makers. https://zapier.com/blog/ai-vendor-lock-in-survey/↩¹↩²↩³↩⁴
25. [25]SUSE, Cloud and AI Pulse Survey, Mar 19, 2026. n=596 global enterprise tech leaders, US/UK/Japan/India/Germany.↩¹↩²↩³↩⁴
26. [26]Parallels, 2026 State of Cloud Computing Survey, Feb 17, 2026. n=540 IT professionals, US/UK/Germany.↩¹↩²↩³↩⁴
27. [27]Roche, J., The Tool Is Not the Answer. The Tool Is the Problem., Roche on Strategy, Jul 21, 2026 (rev. Jul 24, 2026). Essay I of III. rocheonstrategy.com; SSRN Abstract ID 7157878, https://papers.ssrn.com/sol3/papers.cfm?abstract_id=7157878↩
28. [28]Kleppmann, M., Designing Data-Intensive Applications, O'Reilly Media, 2017. ISBN 978-1491903124.↩

Jack Roche is a Strategic Partnerships leader and the founder of Roche on Strategy (rocheonstrategy.com), a journal on governance, systems, and the architecture of decisions. This essay is published under CC BY 4.0. Citation, adaptation, and distribution are permitted with attribution.

Roche on Strategy | rocheonstrategy.com | CC BY 4.0 | v1.0, July 2026 | Essay II of III