Interoperability and Portability Mandate¶
Mandated interface and standard — instantiates Bottleneck Power Governance
Requires the controller to expose standardized interfaces and let users take their data and connections elsewhere, so rivals can plug in and dependence on the bottleneck falls over time.
An Interoperability and Portability Mandate requires the bottleneck controller to publish standardized interfaces — so other systems can interconnect — and to let users export and move their data and relationships out — so they can leave. Its defining move is to attack the "no substitutes" premise directly rather than policing the controller's conduct: it shrinks the chokepoint's leverage by making it bypassable. A rival can plug into the point instead of rebuilding it, and a captive user can migrate off it. Two parts do the work: a technical interface and standard for interconnection and portability, and a transition plan that ratchets real dependence down over time.
Example¶
A regional hospital network runs the electronic health record everyone is locked into; a clinic that leaves loses its patient histories, so nobody leaves and the vendor faces no pressure. An interoperability and portability mandate requires that vendor to support a standardized health-data exchange format and export interface — for instance the HL7 FHIR standard — so a departing clinic can pull complete, structured patient records, and a competing records system can interconnect for referrals and lab results.[n1] Because a wholesale switch is disruptive, the mandate is paired with a transition plan: bulk-export rights from day one, interconnection for new referrals within a year, full portability by a set date, with residual dependence measured and reported at each milestone.
Over the transition window the records vendor stops being a trap. Because clinics genuinely can leave, the vendor must now compete on quality rather than on lock-in — and the chokepoint's power drains without anyone having to run it.
How it works¶
- Mandate a standardized interface. A published, testable interconnection and portability spec — not a bespoke one the controller can quietly vary or deprecate at will.
- Require real portability. Structured, complete export of the user's own data and relationships, not a lossy or partial dump that leaves the lock-in intact.
- Set a transition plan with milestones. Phased dependency reduction — export, then interconnect, then full portability — each with a deadline.
- Measure residual dependence. Track whether switching is actually becoming feasible, not merely nominally permitted.
Tuning parameters¶
- Interface openness — a fully open standard versus a controller-published API it can change or deprecate; the more the controller owns the spec, the more it can re-lock.
- Portability completeness — what must be exportable (raw data, derived data, the social graph, history); thin exports preserve the lock-in they pretend to remove.
- Quality and latency parity — whether the interface must match what the controller gives itself; an intentionally slow, undocumented API is compliance in name only.
- Transition pace — how fast dependence must fall; too fast is disruptive, too slow lets the controller entrench during the grace period.
- Reciprocity — whether rivals must interoperate back, so the mandate is not one-way free-riding.
When it helps, and when it misleads¶
Its strength is that it shrinks the bottleneck rather than merely disciplining it — sometimes the best chokepoint governance is to make the chokepoint optional. Its weaknesses are that interfaces are gameable (a technically-open API that is slow, undocumented, or constantly changed), that portability can be hollowed to a useless export, and that building and maintaining interoperability carries real cost and genuine security and privacy trade-offs. The classic misuse is malicious compliance — shipping an interface that satisfies the letter while being unusable in practice. The discipline is parity and testability requirements, and measuring actual switching rather than nominal permission. Note the frame: this checks a bottleneck's power by creating exit — it is not a program for governing adoption dynamics.[1]
How it implements the components¶
interoperability_and_portability_interface— it specifies the standardized interconnection-and-export interface itself, the technical substitute-path.transition_and_dependency_reduction_plan— it phases real dependence downward on a milestone schedule, converting nominal exit into feasible exit.
It builds the exit path but does not compel the controller to license a protected input — that is Mandatory Licensing or Access Pool — nor re-tender the franchise (Franchise or Concession Rebid), nor set the price and non-discrimination terms of use (Common Carriage / Non-Discrimination Access Tariff).
Related¶
- Instantiates: Bottleneck Power Governance — the mechanism that reduces the need for governance by making the bottleneck bypassable.
- Consumes: Market-Power Screen — justified where the screen shows lock-in is the actual source of power.
- Sibling mechanisms: Mandatory Licensing or Access Pool · Franchise or Concession Rebid · Open Access Mandate · Structural Separation or Unbundling · Common Carriage Obligation
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Interoperability and Portability Mandate operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it requires the controller to expose standardized interfaces and let users take their data and connections elsewhere, so rivals can plug in and dependence on the bottleneck falls over time
Independent corroboration: The frozen evidence defines Interoperability and Portability Mandate as 'Requires the controller to expose standardized interfaces and let users take their data and connections elsewhere, so rivals can plug in and dependence on the bottleneck falls over time', so its operative form is Rule, Policy & Commitment.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Law & Governance
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Obligating a controller to provide compatible interfaces and user portability is principally a regulatory and rights-based legal intervention.
Related originating lineages:
- Computer Science & Software Engineering — Technical interoperability and data-export standards materially define the compliance surface.
- Economics & Finance — Competition economics materially supplies the bottleneck-power, switching-cost, and lock-in diagnosis.
- Ethics of Technology & AI Governance — Data rights and governance of dominant digital platforms materially shape contemporary mandates.
Review resolution: Both independent reviews place the primary lineage in law_governance. The queued differences (alternate_origin_disagreement, encyclopedia_synthesis_disagreement) concern secondary metadata rather than primary provenance. The final retains computer_science, economics_finance, tech_ethics_ai_governance only where a reviewer supplied a formative-lineage rationale; this does not convert downstream applicability into origin. origin_mode=cross_disciplinary_synthesis because the entry's present form deliberately composes methods from the documented lineages. domain_reach=specialized records application breadth separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Keep it distinct from an Open Access Mandate: interoperability lets rivals interconnect and users port out of the existing system, whereas open access opens a defined system to third parties on set terms. They often pair, but the mandate here is about exit and connection, not about admitting third parties to run on the incumbent's platform.
[n1] HL7 FHIR is a real, widely-adopted standard for exchanging health-care data, and a general "right to data portability" (for example, GDPR Article 20) is a real legal analogue for personal-data export. Both are cited illustratively as examples of a mandated interface and portability right, not as claims about any specific deployment's results. ↩
References¶
[1] Crémer, J., de Montjoye, Y.-A., & Schweitzer, H. Competition Policy for the Digital Era. European Commission, Directorate-General for Competition (2019). Explains that data portability can counter lock-in and facilitate switching. registry ↩