TLDR
Executive briefThe export succeeded and the service disappeared
- Define portability as preservation of a critical business outcome, evidence trail and minimum control posture, not movement of files or licence rights.
- Test seven layers: data, context, evaluation, model policy, orchestration, operations and the human workflow that turns components into a capability.
- Execute export, clean reconstruction, substitute acceptance and bounded operation against the same frozen cases before commercial leverage declines.
- Design a Minimum Viable Substitute that retains protections and evidence while deferring noncritical features; a perfect clone is usually the wrong recovery target.
- Record intentional and accidental dependence, price the switching burden and change architecture or terms when exit is not actually executable.
The supplier meets its export promise. Within hours, the buyer receives a large set of JSON files containing conversations, outputs and timestamps. The transfer is machine-readable and complete by record count. A clean team attempts to rebuild the service and fails. Identifiers have undocumented meanings, policy history is absent, retrieval versions cannot be matched, acceptance cases live inside the vendor's platform and tool events do not show their downstream state. Data moved. The capability did not.
This failure is common in concept because a functioning AI service is more than a database. It contains context, evaluation logic, model and policy choices, orchestration, controls, operating knowledge and human routines. Some assets belong to the provider, some to the buyer and some emerge in their interaction. An open licence can leave environment setup and maintainership trapped. A documented API can hide shared upstream dependencies. A second provider can pass average quality while failing the population slice that defines the buyer's duty.
Portability should therefore mean the demonstrated ability to preserve a defined outcome, evidence trail and minimum control posture when a supplier, model, platform or component is removed. It does not require zero dependence or a feature-complete clone. It requires a deliberate boundary between advantage the organisation chooses to rent and capability it can recover. The best time to expose that boundary is before commitment, while the workflow is still small, acceptance evidence is fresh and the buyer still has commercial leverage.
The Portability Proof Stack and Four Portability Tests in this paper turn that principle into evidence. A clean team exports, reconstructs, substitutes and operates a Minimum Viable Substitute against frozen acceptance cases. Hidden dependencies enter a Portability Debt Register. Time, cash, outcome degradation, human burden and control loss form a Switching Friction Curve. A pre-commitment rehearsal then changes the architecture, conditions or decision before dependency hardens.
This is distinct from the map of lock-in in Paper 123. That paper asks where dependency accumulates and how continuity is designed. Paper 129 asks whether a specific option can survive an executed removal test before award. It also differs from Paper 128, which allocates transition and evidence duties during the contract. The proof produced here supplies the artefacts, recovery time, substitute conditions and debt that those duties must reference. Paper 130 will govern the full exit plan later in the lifecycle.
Portability Proof StackSeven layers must move or be deliberately replaced
The Portability Proof Stack is this article's synthesis. Each layer identifies portable assets, dependencies, evidence and a recovery owner. A layer may be recreated rather than copied, but the replacement must preserve the accepted outcome and control. Green lights in one layer cannot compensate for a missing critical layer. A perfect data export beside a lost evaluation system produces a well-organised failure.
Data and rights covers inputs, outputs, feedback, labels, metadata, lineage, schemas, lawful use, retention and deletion evidence. Context and knowledge includes prompts, retrieval content, taxonomies, business rules, embeddings, feature definitions, instructions and expert decisions. These assets explain how generic model capability became locally useful. Export them without semantics and the destination receives values without meaning.
Evaluation and acceptance preserves cases, ground truth, graders, thresholds, slice definitions, incident replays and regression history. It tells the destination what “good enough” meant and how that conclusion was reached. Model and policy records interfaces, buyer-controlled parameters, safety and refusal rules, routing, calibration and substitute candidates. Model weights or access alone do not carry the accepted policy.
Orchestration and integration contains APIs, tool contracts, identities, events, queues, adapters, observability and downstream state. Operations and control covers deployment, access, monitoring, runbooks, incidents, rollback, audit, support and cost telemetry. These layers determine whether a substitute can act, be observed and recover rather than merely respond to a test prompt.
Workflow and capability includes roles, review queues, exception knowledge, training, decision rights, adoption and benefit-capture routines. Tacit supplier knowledge and undocumented buyer workarounds often collect here. If no accountable team can operate a substitute, the capability is not portable regardless of the artefacts delivered.
| Layer | Portable object | Failure signal | Recovery evidence |
|---|---|---|---|
| Data and rights | Current documented assets with lineage and usable rights | Identifiers, provenance or destination rights missing | Parsed sample, legal-use receipt and deletion state |
| Context and knowledge | Prompts, retrieval, rules, taxonomies and expert choices | Outputs cannot be reproduced or explained | Versioned context rebuilt independently |
| Evaluation and acceptance | Cases, labels, graders, slices and history | Substitute judged by a different or average-only test | Frozen acceptance suite runs in destination |
| Model and policy | Interfaces, parameters, routing and safety policy | Nominally compatible model changes authority or refusals | Substitute passes behavioural and control gates |
| Orchestration and integration | APIs, tools, identity, events, queues and state | Model works but workflow actions or receipts fail | Interface and downstream-state reconciliation |
| Operations and control | Deployment, monitoring, runbooks, rollback and audit | No team can sustain or evidence degraded operation | Bounded operated service and incident exercise |
| Workflow and capability | Roles, exceptions, training, review and benefit routines | Tacit staff intervention is required | Named team completes representative work |
Four Portability TestsMove the same acceptance cases through every stage
The Four Portability Tests are this article's synthesis. They operate sequentially but generate separate findings. Export asks whether the buyer can retrieve complete, current, documented and legally usable artefacts in a defined time and format. Reconstruct asks whether a separate team can rebuild the accepted state in a clean environment without tacit supplier intervention. Substitute asks whether an alternate component or provider can pass the same evaluation and control gates through declared interfaces. Operate asks whether the buyer can sustain the minimum service, monitor it, handle exceptions and preserve evidence for a bounded period.
Freeze the acceptance cases, configuration receipt and critical outcomes before the test. The source and destination should face the same normal, edge, population-slice, prohibited, failure, recovery and incident-replay cases. This does not require identical probabilistic outputs. It requires the substitute to remain inside the accepted outcome and control envelope. A new model that is better on average but worse for a high-consequence language group fails even if a vendor benchmark improves.
The buyer, not the incumbent supplier, should control the test record. The provider can support export and explain authorised interfaces, but a clean team performs reconstruction. The destination team records every missing artefact, undocumented assumption, manual conversion, supplier call, buyer workaround and new control. Human hours, revalidation, degraded service and evidence repair belong in the result, not outside the migration estimate.
Tests can stop early. A legally unusable export does not deserve an elaborate substitute build. A failed reconstruction can become a named condition before award. A substitute that cannot preserve a non-negotiable control should not be rescued by cosmetic feature matching. The purpose is a decision, not a ceremonial demonstration of motion.
| Test | Pass evidence | Hidden failure | Stop or route |
|---|---|---|---|
| Export | Complete, current, documented, usable artefacts inside the time bound | Readable format but missing semantics, rights or history | Close the named gap before reconstruction |
| Reconstruct | Clean team rebuilds accepted state from delivered assets | Supplier staff or undocumented buyer workaround is required | Capture knowledge, redesign boundary or ring-fence |
| Substitute | Alternate passes frozen outcome, slice, control and recovery gates | Average quality masks consequential failure | Dual-run, narrow or reject substitute |
| Operate | Named team sustains minimum service, evidence and exception handling | Technical demo works but queues, incidents or monitoring fail | Fund capability or do not commit |
Minimum Viable SubstitutePreserve the critical service, not every feature
The Minimum Viable Substitute is this article's synthesis. It is the smallest alternate configuration that preserves critical business outcomes, affected-party protections, evidence, continuity and an acceptable temporary operating cost. It may have lower throughput, fewer channels, more human review or no advanced optimisation. It cannot discard a critical population, legal safeguard, decision record or stop authority merely to claim that switching is possible.
Start with the minimum continuity state. Name the work that must continue, the populations and consequences involved, the maximum recovery time, the decisions that remain human, the evidence that must survive and the cost period the enterprise can tolerate. Then divide features into critical, temporarily degradable and deferrable. A substitute can be superior to a full clone when it avoids proprietary coupling and restores accountable operation sooner.
A useful test compares three routes: alternate AI component, simplified deterministic or manual fallback, and full supplier replacement. The minimum service may combine them. For example, retrieval and drafting can move to a simpler model while consequential classification returns to staff. This is portability because the business can continue inside a known control envelope, not because the technical stack looks identical.
Portability Debt RegisterMake dependence explicit, owned and expiring
Portability debt is the future switching burden created by a dependency that is not currently removable or independently operable. The Portability Debt Register is this article's synthesis. Each entry records the asset, stack layer, holder, proprietary element, open interface, export method, reconstruction knowledge, substitute, last test, recovery time, expected loss, remediation cost, owner and expiry.
Debt can be intentional. A proprietary capability may deliver a distinctive, verified advantage whose replication cost exceeds the credible exit exposure. The buyer can accept that dependence when its scope is bounded, the critical portable core remains intact, the recovery loss is measured, the commercial price reflects the burden and a funded remediation path exists. This is different from accidental debt discovered through a failed incident or renewal.
Debt should increase after material change when portability evidence is stale. It should decrease only after an executed test, not after a roadmap promise or new contract sentence. Expiry forces a decision: rehearse, remediate, accept again with updated evidence, reduce scope or stop expansion. A register with no operating owner becomes a list of future surprises.
| Dependency | Evidence now | Exposure | Decision and expiry |
|---|---|---|---|
| Managed evaluation grader | Cases export; grading logic does not | Substitute cannot reproduce acceptance | Rebuild buyer-held grader before award |
| Proprietary routing optimisation | Verified outcome gain and bounded fallback | Higher cost and slower service during switch | Accept for six months; fund alternate route test |
| Undocumented tool event | API exists; downstream receipt absent | Reconstruction cannot reconcile actions | Change interface or ring-fence supplier |
| Specialist supplier runbook | Named staff solve rare exceptions | Operated substitute fails under incident | Shadow, document and rehearse with buyer team |
Switching Friction CurveMeasure the difficult last mile of recovery
The Switching Friction Curve is this article's synthesis. It plots five separate dimensions as the switch progresses: elapsed time, cash cost, outcome degradation, human burden and control loss. These dimensions should not be compressed into one score. Their peaks occur at different stages and imply different remedies. Data transfer may finish early while clean reconstruction, revalidation, queue retraining and incident readiness consume most of the recovery period.
Plot both partial substitution and full exit. Partial substitution may preserve meaningful choice at lower burden by replacing the model, retrieval layer or tool while the rest of the service remains stable. Full exit may be necessary when identity, evidence or commercial control cannot be separated. The curve should show the recovery objective, maximum permitted degradation and the point at which a fallback becomes operational, not only the date when files arrived.
Friction includes people. Count destination engineering, data mapping, legal review, retraining, human-review surge, exception handling, supplier coordination and independent assurance. Also record opportunity cost and the temporary loss of benefit. A low migration fee can coexist with severe operational exposure. Conversely, a costly but short and well-controlled migration may be acceptable for a high-value capability.
| Dimension | Early phase | Hard last mile | Decision use |
|---|---|---|---|
| Time | Request and transfer | Rebuild, validate and stabilise | Set recovery objective and support period |
| Cash | Export, egress and licence | Parallel run, assurance and specialist labour | Price dependence and fund option |
| Outcome | Little visible change | Slice failure, delay or feature loss | Define minimum substitute and degradation bound |
| Human burden | Planning and mapping | Review surge, exceptions and retraining | Reserve operating capacity |
| Control loss | Records still available | Monitoring, incident and evidence gaps | Block commitment or constrain scope |
Pre-Commitment Exit RehearsalRemove the preferred supplier while leverage still exists
The Pre-Commitment Exit Rehearsal is this article's synthesis. Freeze the proposed acceptance configuration and cases. Trigger the contractual export, remove the preferred supplier from one meaningful component, rebuild in a clean environment, connect a credible substitute, operate the minimum service, reconcile outputs and evidence, then record every hidden dependency. The incumbent can answer bounded questions through a logged channel but cannot run the destination test.
The rehearsal should include one shared-dependency challenge. Verify whether apparent alternatives use the same upstream model, cloud region, data service, identity provider or specialist team. Commercial names do not establish independence. It should also invoke transition support: request the named artefacts, response times and people that the draft agreement promises. A right that has never reached the responsible team remains an assumption.
The result is not simply pass or fail. A gap can become an architecture change, a paid deliverable, a pre-award condition, a price adjustment, a ring-fenced interface, a dual-running requirement or a reason not to commit. Preserve the clean environment and script so the test can be repeated after material change. Portability evidence expires when the service configuration, acceptance envelope or supplier chain changes.
Ten pre-commitment testsMake each portability claim survive removal
Each case identifies the critical outcome, proof stack, four test results, hidden dependency, friction, recovery objective, debt, commercial implication and owner. These are decision records, not miniature migration plans.
1. Complete JSON, missing decision history
Outcome and stack: Preserve defensible customer-support decisions across data, context, evaluation and evidence. Export passes record count but fails documented semantics because identifiers and policy versions are absent. Clean reconstruction cannot explain earlier decisions; no substitute or operated test proceeds. The friction curve is flat during transfer and rises sharply at evidence repair. The recovery objective requires interpretable history inside two business days. Portability debt is accidental. Make identifier dictionaries, policy lineage and replay evidence pre-award deliverables, owned by the buyer data and service leads.
2. Open model with closed operating knowledge
Outcome and stack: Continue a specialised document classifier with auditable population performance. Weights and code export, but fine-tuning data, environment setup, tests and maintainership practice remain proprietary or tacit. A clean team cannot reproduce the accepted model, so substitution and operation fail. Friction concentrates in skills and validation rather than licensing. The recovery objective is a reproducible build and buyer-held acceptance suite. Record knowledge and environment debt, require an automated build, documentation, test artefacts and shadow maintainership, with platform engineering accountable.
3. Base model switches, managed context disappears
Outcome and stack: Preserve policy-compliant case drafting. The base-model interface is portable, but prompt versions, retrieval indexes, safety rules and evaluation cases remain inside a platform. Export fails layers two and three; model substitution alone produces an unaccepted service. Friction arises late when teams rediscover local context. The recovery objective keeps buyer-owned source documents, prompts, rules and cases continuously versioned outside the platform. Ring-fence the managed service behind a replaceable context interface and make the architecture owner close the debt before scale.
4. Average quality passes, critical slice fails
Outcome and stack: Maintain safe triage for all required language groups. Export and clean reconstruction pass. The substitute matches average quality but fails the high-consequence slice and produces poorly calibrated refusals. It cannot enter operated continuity. The friction curve shows low technical cost and unacceptable outcome degradation. The recovery objective preserves slice thresholds and human escalation. Dual-running may continue only while the slice remains on the incumbent or manual route. Procurement and the capability owner require a qualified second model, not a benchmark claim.
5. Two providers share one upstream model and region
Outcome and stack: Preserve service during an upstream outage or policy withdrawal. Both providers export correctly and expose different APIs, yet dependency mapping reveals the same foundation model and cloud region. Reconstruction succeeds while substitution fails independence. The friction curve understates common-mode loss because both routes fail together. The recovery objective requires a different upstream lineage or a non-AI fallback. Record concentration debt, amend the dual-running claim and assign architecture and resilience owners to qualify a genuinely independent route.
6. A partial substitute outperforms the full clone
Outcome and stack: Continue urgent benefit decisions with lawful evidence and appeal. A simpler substitute handles retrieval and drafting, while staff perform classification and final approval. Advanced personalisation and automated routing are deferred. All seven layers are smaller, export and reconstruction pass, critical slices and controls pass, and the team operates the service with more review. Friction peaks in human burden but remains inside the funded continuity window. This Minimum Viable Substitute is superior to a slow full clone. Accept it as the recovery route, owned by operations.
7. Fast export is legally unusable
Outcome and stack: Move labelled training and feedback data to a destination lawfully. Export meets the promised time and format, but provenance, consent constraints and distribution rights are absent. Reconstruction may be technically possible but cannot lawfully proceed. The friction curve should show a hard legal gate rather than an optimistic transfer milestone. The recovery objective requires rights and source lineage attached to every asset class. Add warranties, entitlement receipts and a remediation path before commitment; legal and data owners share accountability.
8. Clean reconstruction exposes tacit work
Outcome and stack: Sustain maintenance recommendations and incident response. The clean team rebuilds the technical service, then fails rare exceptions because supplier engineers and buyer operators use undocumented judgement and workarounds. Substitution passes ordinary cases but operated continuity fails the exception queue. Friction lies in training, staffing and knowledge capture. The recovery objective is a bounded run with named staff handling representative exceptions. Fund shadowing, decision records and runbook rehearsal; the operating owner, not procurement alone, closes the debt.
9. Deliberate dependence earns its place
Outcome and stack: A proprietary multimodal diagnostic feature produces a verified outcome advantage unavailable elsewhere. The buyer preserves data, context, evaluation, integration receipts and a degraded manual fallback but cannot reproduce the feature. The Minimum Viable Substitute meets safety and continuity with slower outcomes and higher cost. The friction curve is known and capped. Accept intentional debt for a fixed term, price the transition burden, prohibit wider coupling and fund periodic fallback operation. The executive capability owner renews the exposure only if advantage still exceeds tested exit cost.
10. Failed rehearsal changes the architecture
Outcome and stack: Preserve an agent-assisted fulfilment workflow and its evidence. The pre-commitment rehearsal finds unavailable logs, trapped evaluation data and undocumented tool contracts. Export, reconstruction and substitute tests fail before operated recovery. The hidden dependencies would make incident investigation and exit unverifiable. The recovery objective cannot be met under the proposed architecture. Do not accept transition-support wording as compensation. Move logs and cases to buyer control, require action receipts and modularise tools before award, with the programme architect and commercial owner accountable.
Portability Test BenchResolve the proof into one of five commitments
The Portability Test Bench is this article's synthesis. It returns exactly five outcomes: commit with a verified portable core; commit only after closing a named gap; use dual-running to preserve a viable substitute; ring-fence the supplier behind a replaceable interface; or do not commit because exit is not executable. It does not compute a portability score or treat machine-readable export as recovery.
Strong rival and failure boundaryFull portability can destroy the advantage worth buying
The strongest rival is correct in some circumstances. Optimising for the lowest common denominator can remove the proprietary capability that justified a supplier. A technically available substitute may produce poorer outcomes or much higher cost. Clean-room rehearsals consume scarce engineering, legal and operating capacity. Some managed services cannot be faithfully reconstructed outside the provider, and a permanent dual-running arrangement can double complexity without creating real independence.
The answer is consequence-weighted portability. Preserve a portable core for critical data, evidence, controls and workflow continuity. Accept deliberate dependence where incremental advantage is material, the recovery loss is measured, the affected scope is bounded and a practical substitute retains essential protection. Rehearse the boundary where failure would remove meaningful choice. Do not spend more to eliminate a trivial dependency than the dependency can plausibly cost.
This discipline rejects two symmetrical errors. “Everything must be portable” mistakes strategic flexibility for technical sameness. “The contract says we can export” mistakes permission for capability. Open source supplies important rights but not automatically the build, tests, dependencies, maintainership and people required to operate. A proprietary service can be a rational choice when its portable core, recovery burden and break conditions are evidenced.
Use sources according to their authority. OMB guidance and the EU Data Act provide public-policy and legal switching mechanics in their applicable domains. UK playbooks and standards guidance support modular, interoperable and exit-aware procurement. NIST, CISA and NCSC inform lifecycle, dependency and recovery practice. AISI and documentation research show why evaluation and system artefacts matter. Research on soft lock-in and reproducible ML workflows provides empirical and engineering insight, not a universal legal rule. The constructs in this paper are a commercial synthesis.
The decisive question before commitment is not whether another supplier exists. It is whether a named team can preserve the minimum outcome and controls, with usable evidence, inside an agreed recovery window after the preferred option is removed. When the answer is demonstrated, dependence becomes a choice. When the answer is assumed, dependence is already governing the deal.
Evidence spineSources checked 3 September 2026
- US OMB, M-25-22.
- European Union, Regulation (EU) 2023/2854, Data Act.
- GSA, Buy AI.
- UK Government, Digital, Data and Technology Playbook.
- UK Government, Technology Code of Practice.
- UK Government, Make Use of Open Standards.
- NIST, Artificial Intelligence Risk Management Framework.
- NIST, Generative Artificial Intelligence Profile.
- UK AI Security Institute, Inspect Evals.
- CISA, NSA and ODNI, Securing the Software Supply Chain: Guide for Customers.
- UK NCSC and partners, Guidelines for Secure AI System Development.
- UK NCSC, Mapping Your Supply Chain.
- Mitchell et al., Model Cards for Model Reporting.
- Gebru et al., Datasheets for Datasets.
- Arnold et al., FactSheets: Increasing Trust in AI Services.
- Hickok, Public Procurement of Artificial Intelligence Systems.
- Persson and Linåker, Soft-lockins in Public Sector Acquisitions of Open Source Software-solutions.
- Fursin, The Collective Knowledge Project.
About this paperEvidence that meaningful choice still exists
The Portability Proof Stack, Four Portability Tests, Minimum Viable Substitute, Portability Debt Register, Switching Friction Curve, Pre-Commitment Exit Rehearsal and Portability Test Bench are this article's synthesis. They treat export, reconstruction, substitution and operation as separate proof obligations without demanding zero dependence or a perfect clone.