Requests, Responses, Messages, and Operations
Use one typed communication model for questions, answers, progress, negotiation, chat, provider facts, and executable operation calls.
Business coordination is more than RPC#
Participants ask, answer, negotiate, clarify, report progress, and explain why they are present. A separate API log and chat transcript make it difficult to reconstruct the causal business process.
Blue Coordination uses typed Messages so communication and execution can share one inspectable trace.
The common fields#
A Message can carry:
requestId— an application correlation key;threadId— a conversation grouping key;recipientChannel— the addressed participant role;inResponseTo— an exact reference to the Message being answered.
These fields solve different problems. A string request ID groups retries or provider jobs. An exact inResponseTo reference anchors the Response to one precise occurrence.
Requests solicit answers#
A Request may ask a provider for availability, legal review, delivery evidence, identity verification, payment action, or another result. A Request can itself respond to an earlier Message, as in a counter-offer or clarifying question.
Responses are attributable answers#
A Response references the exact Request occurrence. One Request can receive several Responses: accepted, progress, delivered, declined, failed, or multiple provider answers.
A provider Response is still not automatically authoritative for every purpose. The provider role and the document's rules determine what claim it contributes and what consequence follows.
Chat remains useful but not magical#
A Chat Message records human-readable text. It can explain, discuss, or comment on a structured Request. It does not perform a machine action unless a concrete contract explicitly treats that content as an operation.
Operation Request joins communication and execution#
An Operation Request names the target operation, effective channel, request payload, and optional exact document-state precondition. The Timeline Entry envelope separately states who wrote the action and how it reached the provider.
This distinction is essential:
entry.actor → who or what submitted the action?
message.channel → which document role or authority is being exercised?
For direct action, the source and effective channel align. For a Mandate-backed agent action, the entry remains attributed to the agent while the effective channel may represent the principal.
Purpose explains presence; it grants nothing#
A participant Purpose can say why a person, agent, or provider is at the table and which Requests it intends to handle. Purpose is explanatory. It does not create authority, access, or commercial obligation.