Request-response

A requester asks a bounded question and receives a bounded answer without the underlying data being shared.

Diagram

This diagram is free to copy into your own presentation. The responder answers a bounded question without disclosing the underlying data behind the answer.

When to use, when not to use

When to use. Use request-response when a requester asks a specific, bounded question and should receive a bounded answer, for example match or no-match, without the underlying data being shared. The exchange is pairwise and bilateral: two parties agree to it directly, and the response reveals the answer, not the data behind it. This is the right pattern when parties need to compare or confirm something without exposing the records that support the answer. The exchange itself is anchored, not just the payload. Each party can independently verify three things: that it happened, who asked, and on what basis the answer was reached. What backs those three is identified parties, an immutable audit record, and evaluation performed at the source. The guarantee therefore covers what happened to the data, not only that it stayed unshared.

When not to use. If a party needs the record itself rather than a bounded answer about it, use on-demand (pull) instead. If a producer needs to distribute a record to many readers, use broadcast or one-to-many.

Note (V1 boundary). This is the V1 request-response pattern: a bounded pairwise question and answer. It is not the deferred demand-aggregation mechanic (bundled demand across many parties), which is roadmap text only and is described on the patterns index. The two are distinct and should not be conflated.

Example configuration (YAML)

pattern: request-response
protocol_version: "0.1"
exchange:
  topology: pairwise
  participants:
    - requester
    - responder
  admission: bilateral
delivery:
  mode: request-response
  ordering: none
payload:
  encryption: field-level
  disclosure: selective
audit:
  anchor: public-audit-layer
  proof: per-record

Use case

This template fits a requester asking one counterparty a bounded question and receiving match or no-match without exposing data, illustrated by the fraud-signal sharing protocol, where parties compare patterns without sharing the underlying records. It configures the base data-sharing protocol.