Exchange patterns
Reusable configuration templates on the base data-sharing protocol, so a new case reuses an existing template instead of designing an exchange from scratch.
Exchange patterns are reusable configuration templates on the base data-sharing protocol. They are not a separate layer and they do not change what the protocol guarantees. Each pattern fixes a small set of choices, who is admitted, whether records are pushed or pulled, how much of a record is disclosed, and how proof is anchored, so that a new case reuses an existing template instead of designing an exchange from scratch. Every pattern below configures the same base protocol; the diagrams and configurations are free to copy into a presentation or a proof of concept.
The five V1 patterns
| Pattern | Page | In one line |
|---|---|---|
| One-to-many | /patterns/one-to-many | One producer pushes a verifiable record to a bounded, named set of recipients. |
| Broadcast | /patterns/broadcast | One producer publishes to an open topic that any admitted party subscribes to and reads. |
| On-demand (pull) | /patterns/on-demand | A recipient pulls a specific record when it is needed, and verifies it at read time. |
| Request-response | /patterns/request-response | A requester asks a bounded question and receives a bounded answer without the underlying data being shared. |
| Cross-sector | /patterns/cross-sector | Parties in different sectors exchange verifiable references across domain boundaries, each verifying independently. |
Where this section sits
The exchange patterns live in the middle of the descent, "Shared protocols and dependencies". The domain protocols above (content authenticity, fraud-signal sharing) reference this section upward as a shared dependency, and each pattern here references the base data-sharing protocol below it. This keeps the one logical descent intact: a reader arrives at a concrete domain protocol, follows it to the exchange pattern it uses, and follows that to the base protocol both build on.
Only anchors reach the public audit layer. Every pattern below keeps its record payloads in the parties' own environments, with the keys held by the parties; what is published to the public audit layer is a proof (a hash), never the record itself.
Roadmap (not in V1)
Request-distribution and demand-aggregation, sometimes described as bundled demand, are explicitly out of V1. They are carried only as roadmap text here, with no page, no configuration, and no diagram, and they are a later growth mechanic, not a template a reader can use today. Note in particular that demand-aggregation is not the same as the request-response pattern below: request-response is a bounded pairwise question and answer that ships in V1, whereas demand-aggregation would bundle demand across many parties and is deferred to a later iteration.