Interoperability Mandate¶

Compatibility obligation — instantiates Network Effect Governance

Requires a dominant operator to expose defined, compatible interfaces so participants aren't trapped behind one gatekeeper and value can flow across competing providers.

An Interoperability Mandate compels ongoing compatibility across providers when incompatibility is the specific mechanism holding participants captive. Where a voluntary open standard invites everyone to converge and a portability rule lets you export and leave, a mandate forces a dominant operator to keep its interfaces open to competitors under defined conditions — so a participant can reach the whole network without being trapped inside one operator's walls. Its defining move is that compatibility is required and continuous, not offered and one-time: the gatekeeper must let others connect, at a defined quality, for as long as it stays dominant.

Example¶

A messaging service so widely used that leaving means losing contact with everyone is required to let users exchange messages with people on competing apps through a defined interface, subject to security and consent safeguards. A person can now choose a different messaging app for privacy, features, or price and still reach their existing contacts — the network's reach survives the switch, and no single operator owns the ability to communicate. Requirements of this kind appear in gatekeeper-interoperability rules under regimes like the EU's Digital Markets Act.^[1]

How it works¶

Identify the lock-in interface. Pinpoint the specific chokepoint — the interface whose closedness is what traps value behind the gatekeeper.
Mandate exposure under conditions. Define which functions must interoperate, for whom, and at what quality, so compliance can't be satisfied with a degraded stub.
Attach safeguards. Security, privacy, consent, and reliability constraints, because forcing interfaces open carelessly trades lock-in for exposure.
Require parity. The exposed interface must work about as well as the operator's own, or "interoperability" becomes a second-class channel nobody can rely on.

Tuning parameters¶

Interface scope — which functions must interoperate; too narrow and the lock-in survives around the edges, too broad and it strains security and quality.
Quality and latency parity — how closely the open interface must match the first-party experience.
Security and consent constraints — how much protection is built in, especially where opening interfaces touches private data or end-to-end encryption.
Eligibility — who is allowed to connect, and under what vetting.
Reciprocity — whether connecting parties owe symmetric obligations back.

When it helps, and when it misleads¶

Its strength is that it breaks incompatibility-based lock-in without dismantling the network, reduces dependence on a single gatekeeper, and enables competition on top of a shared graph. Its failure modes are real: forcing interfaces open can open security and privacy holes, especially against end-to-end encryption; a mandated interface can be quietly degraded to technical-compliance-only quality; and freezing a required interface can slow the innovation that would otherwise route around it. The classic misuse is exposing a deliberately poor interface that satisfies the letter of the mandate while defeating its purpose. The discipline is to pair the mandate with security, consent, and quality-parity requirements so that "interoperable" means genuinely usable — otherwise the mandate trades lock-in for insecurity or for a channel no one can depend on.

How it implements the components¶

interoperability_rule — it defines the compatible interfaces and obligations that keep network value from being trapped behind one gatekeeper; it is that rule, made binding.
resilience_and_dependency_review — mandated multi-provider compatibility reduces the network's dependence on any single operator, addressing the single-provider fragility the resilience review flags.

It compels compatibility but doesn't write the shared spec it points at — that's Open Standard — nor govern one operator's own voluntary API (that's API Governance Policy), nor provide one-time export of your data (that's Data Portability Rule).

Instantiates: Network Effect Governance — it is the compatibility lever used specifically when incompatibility is the mechanism of lock-in.
Consumes: Open Standard — the specification a mandate typically forces adoption of.
Sibling mechanisms: Open Standard · API Governance Policy · Data Portability Rule · Competition or Antitrust Remedy · Federation Protocol

Notes¶

A mandate needs something to point at: it usually references or forces an open standard, since "expose a compatible interface" is empty without a defined interface. And without security and quality-parity conditions, a forced-open interface can swap one harm for another — trading lock-in for a channel that is either insecure or too degraded to use.

References¶

[1] Lock-in and the switching costs that create it are the harm this mechanism targets — the economics of a network where the cost of leaving, not the value of staying, is what holds participants. Mandated interoperability attacks lock-in directly by lowering the cost of connecting from outside the dominant operator. ↩