Browse documentation
Query lifecycle
From an offered query to an acknowledged, superseded, or withdrawn response.
1. Request
The requester creates a unique query identifier, a stable subject, a typed prompt, an allowed response shape, a delivery destination, and an expiry. A query may be ignored; its presence never compels a respondent to act.
2. Evaluation
The host and respondent validate the query, wait for its timing condition, and apply local policy. The respondent kind must match the request. Expired queries must not be answered.
3. Submission and acknowledgment
The respondent sends one response using the selected binding. The collector validates authority, answer schema, respondent kind, subject binding, expiry, and replay state, then returns a receipt. Retrying the same responseId must be idempotent.
4. Continuation, supersession, and withdrawal
An accepted receipt may return one new bounded query. A corrected response references the prior response in supersedesResponseId. Collectors preserve both query and response lineage rather than mutating completed exchanges.
Evidence stages
Offered, discovered, attempted, accepted, and rejected are separate facts. HTTP metadata proves only that a query was offered. Only a valid receipt proves collector acceptance.
Failure behavior
Query processing must not change the result of the interaction that carried it. Clients may retry transient collector errors within the query expiry. Validation, authorization, approval, and policy failures are not retryable without a meaningful state change.