Skip to content

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.[1] 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).

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.

References

[1] 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. ↩