Portability Checklist¶
Readiness checklist / verification protocol — instantiates Dependency Concentration Control
A standing list of the concrete things — data, contracts, interfaces, credentials, skills, runbooks — that must be movable before an alternative provider counts as real rather than nominal.
A diversification plan assumes you can actually move to the alternative. Portability Checklist tests that assumption one line at a time. Its defining move is to convert "we could switch providers if we had to" from a comforting belief into a verified inventory of movable assets — data, contracts, interfaces, credentials, skills, and operational runbooks — each checked against a named destination, not against the abstract idea of "a competitor." It says nothing about how concentrated you are and does not perform the switch; it establishes whether substitution is even possible, so that a nominal second source is not silently counted as a real one.
Example¶
A lender relies on a single identity-verification (KYC) vendor and assumes it could move to a competitor "if it ever needed to." Running the checklist against a specific alternative dissolves the assumption. Can the verified-identity records and audit trail be exported in a usable form, or are they trapped in the vendor's proprietary schema? Is the integration behind an abstraction layer, or are vendor-specific fields wired through ≈30 code paths? Does the contract permit exit without a multi-quarter notice period and a data-deletion delay? Do any engineers actually know the competitor's API? Four of nine items come back red: the "alternative" is not real until a data-export path and an interface adapter are built. The surprise was never concentration — it was non-portability hiding behind a name on a vendor list.
How it works¶
- Enumerate the portability dimensions. Data, interface/API, contract/legal, credentials/keys, skills/knowledge, operations/runbooks — the categories that together decide whether reliance can move.
- Check each against a named destination. An item passes only against a specific alternative provider, because "portable in general" is how lock-in stays invisible.
- Set the pass bar honestly. "Green" means demonstrably movable — a test export ran, an adapter exists — not "probably exportable if we tried."
- Assert the interface requirement. Where a dimension fails, the fix is often a standard or abstraction the dependency must sit behind so it stays swappable next time.
Tuning parameters¶
- Dimension set — which categories apply (a data vendor stresses data + contract; a compute provider stresses interface + skills).
- Destination specificity — checked against one named alternative vs. generic portability; specific is harder and more truthful.
- Pass bar — "exportable in principle" vs. "exported in a rehearsal"; raising the bar costs effort but removes false green.
- Interface-abstraction strictness — how hard you insist a dependency sit behind a portable interface or open standard, trading build cost now for cheap switching later.
- Refresh trigger — re-run on contract renewal, vendor change, or a fixed cadence, so a once-portable dependency does not silently ossify.
When it helps, and when it misleads¶
Its strength is timing: it surfaces lock-in before you are forced to move, when the fixes are cheap — negotiate an exit clause, add an adapter, cross-train an engineer — rather than during the outage that makes the switch urgent.[n1]
Its failure mode is that a checklist can be fully green on paper while the move still collapses under real load and real clocks: "exportable" is not "switched over a weekend," and a tidy set of ticks can breed exactly the false confidence a live rehearsal would puncture. It is also the archetype's easiest box-ticking ritual — items marked green against no real destination. The discipline that guards against this is to keep the pass bar empirical where it matters and to hand the load-and-timing proof to the Substitution Drill rather than treating a green checklist as the finish line.
How it implements the components¶
Portability Checklist fills the can-we-move-at-all side of the machinery:
substitution_feasibility_map— the completed checklist is the feasibility map: for each dependency, which alternatives are genuinely reachable and precisely what blocks the rest.portable_interface_requirement— its interface line-items assert the standard or abstraction layer a dependency must sit behind to remain swappable.
It does not prove the switch survives real load and timing, nor exercise the standby capacity and firebreaks (shadow_capacity_reserve, segmentation_or_firebreak_boundary) — that is the Substitution Drill; the checklist certifies movability on paper, the drill certifies it in practice.
Related¶
- Instantiates: Dependency Concentration Control — it verifies that a diversification target is reachable before anyone relies on it.
- Consumes: Top-K Exposure Share points the checklist at the overweight providers worth checking first.
- Sibling mechanisms: Substitution Drill · Provider Load Split Table · Multi-Sourcing Rule · Weighted Dependency Graph · Top-K Exposure Share · Effective Independent Provider Count · Dependency Concentration Heatmap · Common-Mode Dependency Audit · Dependency Concentration Stress Test · Concentration Cap Policy · Residual Concentration Risk Register
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Portability Checklist operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a standing list of the concrete things — data, contracts, interfaces, credentials, skills, runbooks — that must be movable before an alternative provider counts as real rather than nominal.
Independent corroboration: The frozen evidence defines Portability Checklist as 'A standing list of the concrete things — data, contracts, interfaces, credentials, skills, runbooks — that must be movable before an alternative provider counts as real rather than nominal', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Data, interface, credential, and environment portability are rooted in software architecture and interoperability practice.
Related originating lineages:
- Law & Governance — Law contributes contractual exit rights and restrictions.
- Organizational & Management Science — Organizational management contributes skills, runbooks, and provider-transition readiness.
Review resolution: Both blind reviewers agree that computer science is the primary origin. Reconciliation resolves reported ambiguity, alternate origin disagreement. Formative alternate lineages are retained as law_governance, organizational_management; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.
Attribution caveat: The checklist generalizes technical portability into an organizational exit-readiness instrument.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
Portability is a precondition for the whole diversify-and-rebalance move: you cannot split load onto an alternative you cannot actually move to. The checklist therefore gates the Provider Load Split Table and the Substitution Drill — a red checklist means the rebalance plan is fiction until the blocking items are fixed.
[n1] Vendor lock-in is the cost and difficulty of leaving a provider; data portability — the ability to extract your data in a usable, reusable form, codified for personal data in GDPR Article 20 — is one of its largest components and, in practice, the first checklist line to fail. ↩