Interoperability is a seam, not a merger

Most interoperability efforts fail for the same reason: they try to make two systems identical instead of agreeing on how they talk to each other. Mosaic’s working definition is narrower and more useful — interoperability is the smallest set of shared agreements that lets independent systems exchange meaning without losing their own authority over their own data.

This framework is the checklist a working group runs through before it calls anything “standardised.”

The four layers

  1. Legal — who is allowed to ask for what, under what consent, and who is liable if the exchange goes wrong. Skipping this layer is the single most common reason a technically-sound integration stalls in production.
  2. Governance — who can change the standard, how a dispute between two implementers gets resolved, and what happens when an issuer stops operating. A standard with no governance process is a draft, not a rail.
  3. Semantic — the same field means the same thing everywhere. A “verified” status, a date format, a currency unit — ambiguity here is where silent data corruption happens.
  4. Technical — the API shape, the credential format, the transport. This is the layer everyone starts with and the one that matters least without the three above it.

What stays sovereign

A system that adopts a Mosaic-convened standard keeps:

  • Its own data holdings and the infrastructure they run on.
  • Its own decision about whether to grant a specific request.
  • Its own user experience, business logic, and roadmap above the seam.

Only the exchange layer — the fields, the trust mechanics, the legal basis — is shared. Nothing in this framework asks an institution to run someone else’s software or hand over its data by default.

How a use case graduates

A use case moves from “explored” to “standardised” when:

  • At least two independent implementations can exchange data against the same specification without a bespoke integration.
  • The legal and governance layers have an actual owner, not just a technical spec.
  • Open questions (see each use case’s detail page) have been either resolved or explicitly assigned to someone to resolve.

This is a working draft. If you’re implementing against it, tell us where it broke — see how to participate.