An open protocol for sharing data between organisations

The protocol defines an open way for organisations to share encrypted data directly with each other, address the right counterparties, and record every exchange verifiably. Nobody owns it. Anyone with the specification can rebuild it. It is designed to work across public and private collaborations because it standardises the shared interface once, then lets each field define the data it needs. The shared envelopes, addressing and discovery rules are detailed under Shared protocols & dependencies.

Three ways data moves

One-to-many. One party shares verified data with many receivers. A manufacturer publishing a product passport, or a public body publishing a verified register update, fits here. The sender controls the content; receivers verify it for themselves (the domain agreements live under Domain protocols).

Many-to-one. Many parties feed verified data to one receiver. Fraud-signal aggregation works this way: each contributor submits independently, and the receiver assembles the picture without any contributor seeing the others' data (the aggregation pattern is specified under Shared protocols & dependencies).

Peer-to-peer. Two parties exchange directly, with no intermediary holding the message in transit. A supplier and a buyer exchanging a verified claim is the simplest case (the addressing that makes this possible is described under Runtime concepts).

These forms are properties of the protocol's addressing model, and in practice most data-sharing situations an organisation meets map onto one of the three, so each case reuses an existing pattern instead of starting a new integration. The patterns are documented as ready-made configuration templates under Shared protocols & dependencies.

The same protocol in three situations

A public body, without a fixed service provider

A public body could explore verified data exchange with many external parties without committing to one permanent supplier. In the older model, the service depends on one supplier's implementation, and switching means re-integrating everyone. With an open protocol as the starting point, one or several independent service providers can connect to the same standard. In a pilot, the body could switch providers later, or run its own node, because the specification is designed to be self-contained enough to rebuild independently (what rebuilding involves is set out under Runtime concepts).

In this model, every exchange is recorded against a public audit layer, so who shared what, when, and on what basis can be verified independently of any provider, and no single supplier can lock the body in. The sector-specific agreements for a case like this live under Domain protocols; the audit behaviour is specified under Runtime concepts.

Fraud signals, compared without sharing personal data

Online shops, payment services and delivery firms each hold a piece of a fraud pattern, but none of them may share the personal data behind it across sectors. The protocol could let each party turn its own record into a scrambled fingerprint that cannot be turned back into the original. Two parties holding the same underlying fact produce the same fingerprint, so they can match without either seeing what the other holds (the fingerprinting mechanics live under Shared protocols & dependencies).

At sufficient overlap, one signal could go to one mandated receiver, which sees only that a match exists, never the underlying records. The public audit layer records that a match exchange occurred and when; it does not record what was compared. Each match could be a verifiable event in a continuing stream, recorded as having happened. The domain agreement for fraud signals lives under Domain protocols; the matching, addressing and envelope mechanics live under Shared protocols & dependencies.

Knowing your counterparty, without a central gatekeeper

Know-your-business checks typically mean chasing documents across registries and asking the same company for the same paperwork again. A public register standard on this protocol could let any organisation publish verifiable claims about itself to a known address. Any counterparty could look those claims up directly and verify their origin and integrity for itself. The claim is signed, and the signature is checkable by anyone (the signature and verification scheme live under Shared protocols & dependencies).

Perpetual KYC then becomes a continuous stream of verifiable updates instead of a periodic manual exercise: publishing is one-to-many, verifying is many-to-one. The register exists in this version as a concept and specification, not a live lookup service. Its domain rules live under Domain protocols; the register and discovery model under Shared protocols & dependencies.

One base layer, many domain agreements

The expensive layer to standardise exists only once. It covers encrypted exchange, addressing, discovery, verifiable recording and the reusable exchange patterns. Above it live many light, per-domain agreements about which data is shared and what it means, the way one internet transport carries many light document types (that shared base layer is described under Shared protocols & dependencies).

A fraud-signal agreement, a product-passport agreement and a press-release provenance agreement can all use the same underlying interface. A domain adding a rule does not change the base; a domain changing its rules does not break other domains. Many domain protocols share one foundation by design. The agreements are collected under Domain protocols; the foundation they reuse is described under Shared protocols & dependencies.

Verifiable by design

Every mechanism the protocol uses is drawn from open, standard cryptography and open identity standards, so any party can inspect the algorithms and run them independently. The specification is published openly, and the reference implementation, including the state machines that run it, is published source-available, free to inspect, fork, and self-host, with each version scheduled to become Apache-2.0 open source two years after its release under the licence being finalised. Every exchange leaves a record on a shared public audit layer that no single operator holds or can quietly rewrite, so participants verify records for themselves, and because the specification is designed to be self-contained, an organisation that wants to leave any particular implementation can build its own and connect to the same network. No proprietary component blocks that path. These are constraints in the design, and implementers, auditors and public decision-makers can check each one. How nodes read shared event streams, build their own state, handle keys and replay, and verify the audit layer is specified under Runtime concepts.

Where to go next

The site descends from concrete to foundational. Start at Domain protocols to see how a sector describes the data it shares. Continue to Shared protocols & dependencies for the envelopes, addressing, discovery and exchange templates every domain reuses. How implementations verify everything for themselves is the foundation, under Runtime concepts.