Foundations · Explore this field ↗ · Practice · 4 min read
Provider exit portability: rehearse the reversible path
Preserve owned records, documented tool contracts, and asset rights so leaving a provider is a tested transition rather than an emergency assumption. This field note supplies an inspectable artifact, counterexample, and release checks.
Part of the 20-guide fieldwork edition.
Rehearse an exit without changing production
- 01Inventory assets and rights
- 02Export a test subset
- 03Verify owned formats
- 04Replay contracts
- 05Test restoration
An export is not equivalence. Record missing fields, rights restrictions and failed transitions before choosing a replacement.
Original conceptual diagram · not a live trace or measured result.Inventory what must move
A provider exit plan starts with an owned-asset inventory: conversation records under their retention policy, knowledge source pointers, tool contracts, evaluation fixtures, prompts or policies, embeddings where export is permitted, audit references, configuration, visual assets, and licenses. For each item, name the owner, source format, export method, import target, integrity check, and deletion or retention decision. Do not assume that an API response is a durable export format.
Separate data portability from functional portability. A JSON transcript may be exportable while the tool adapter, state machine, safety rule, authentication integration, and playback behavior remain tied to a service. The rehearsal should expose that gap before an incident or procurement deadline makes careful analysis impossible.
Own interfaces at the boundary
Describe application-controlled tools in an owned contract and test them independently of a provider adapter. OpenAPI publishes interface specifications that can make HTTP contracts inspectable; use an applicable owned description where it matches the interface. Preserve request and response examples, error semantics, authentication boundary, version policy, and compatibility tests. Do not call a contract portable merely because it is written down: another implementation must be able to satisfy it.
Hypothetical example: a team saves a tool description and a set of local fixtures, then runs an adapter against a replacement runtime in an isolated test. A pass means the adapter produced the declared calls and handled failure cases; it does not show that the replacement has the same model quality, policy, price, or terms.
Treat assets and rights separately
Character models, voices, photographs, fonts, music, screenshots, and vendor-generated assets may have different ownership and reuse rights from the application code. Record the actual license or agreement reference, permitted export, derivative-use condition, attribution requirement, and owner review status. Do not infer a right to move an asset because it was visible in a dashboard or downloadable from a runtime.
SPDX publishes formats for software component and license information. It can help structure component provenance, but it does not grant copyright, establish a commercial right, or verify a provider agreement. Escalate ambiguous asset terms to the accountable owner rather than writing a migration promise into an engineering checklist.
Rehearse a reversible exit
Run a bounded, local rehearsal: export a representative nonproduction record set; verify counts and hashes; import into a neutral owned format; start an alternate adapter; replay tool-contract fixtures; and compare expected state transitions and citations. Keep the original system unchanged during the exercise. A rehearsal is successful when it documents what moved, what transformed, what could not be verified, and how to reverse the test.
Counterexample: exporting raw conversation text without tool outcome records can make a demo appear portable while pending actions cannot be reconciled. Another failure is exporting source URLs but dropping lifecycle and access metadata, which turns a knowledge corpus into an unauthorized archive. Include these boundaries in the acceptance record.
Maintain an exit decision record
Version the inventory, runbook, contact-independent ownership map, test fixtures, and last rehearsal result. Record dependencies that are provider-specific, including undocumented behavior discovered during testing, but do not speculate about contractual rights or vendor performance. Define the condition that triggers a fresh rehearsal: major tool-contract change, new licensed character asset, retention-policy change, or significant data-model migration.
Acceptance checks: each material asset has an owner and source format; tool contracts have local fixtures; export/import checks record known losses; licensed assets are reviewed separately; and the exit test is reversible. Portability reduces switching risk; it does not guarantee that a replacement will be available, equivalent, permitted, or operationally cheap.
Practice restoration as well as export
An exit rehearsal should test whether exported records can be restored into a controlled owned environment without duplicating an action or broadening access. Verify mappings for deleted records, revoked grants, pending jobs, and references to unavailable assets. Document how the rehearsal data is disposed of after the test. Preserve checksum and mapping evidence with the rehearsal record.
A successful archive is not enough if restoring it breaks privacy boundaries or loses the ability to explain a past decision. The recovery test makes these limits visible while the original provider remains available for comparison.
Take it into the review
Exit rehearsal inventory
| Asset | Owned format | Export evidence | Import check | Rights/status | Known loss |
|---|---|---|---|---|---|
| tool contract | versioned API description | hash + fixture set | alternate adapter run | application-owned | provider extension |
| conversation state | documented record schema | count + checksum | state replay | retention-reviewed | unsupported metadata |
| character asset | source file or license record | owner inventory | render review | owner review required | reuse may be barred |
| knowledge pointers | resource IDs + lifecycle data | manifest | access-aware import | source-owner controlled | embedding unavailable |
A starting artifact to adapt to your service—not a ready-made policy, compliance certificate or test result.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.
What the sources establish
OpenAPI Initiative specifications
The OpenAPI Initiative publishes authoritative renderings of its interface specifications.
Limits: It does not prove provider export compatibility or a contractual right.
Checked 2026-09-19 · OpenAPI Initiative · source publication date not established.
Open original source ↗SPDX specifications
SPDX publishes an open standard for software component and license information.
Limits: It does not grant asset rights or verify an agreement.
Checked 2026-09-19 · SPDX · source publication date not established.
Open original source ↗Procedures and worked examples are editorial synthesis. Preparation/review dates are not claimed historical publication dates.