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 respondent waits until the requested timing condition is satisfied, then validates the query and applies local policy. If consent is required, silence is not approval. Expired queries must not be answered.
3. Submission and acknowledgment
The respondent sends one response using the selected binding. The collector validates authority, schema, subject binding, expiry, consent, and replay state, then returns a receipt. Retrying the same responseId must be idempotent.
4. Supersession and withdrawal
A corrected response references the prior response in supersedesResponseId. A withdrawal is binding-specific. Collectors must preserve enough lineage to avoid silently treating an obsolete answer as current.
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, consent, and policy failures are not retryable without a meaningful state change.