The UAI-1 message model makes cross-boundary state, delivery, trust, provenance, and integrity reviewable instead of implicit. Think of it as an evidence envelope plus a profile-specific body.
Envelope map
| Envelope field | What it tells the receiver | Why readers should care |
|---|---|---|
uai_version |
Which UAI release the payload claims to use. | Prevents an implementation from silently mixing incompatible contract expectations. |
profile |
Which published profile and schema family applies. | Determines the body shape and profile-specific validation checks. |
message_id |
The stable identifier for this exchange record. | Lets logs, conformance records, and retries refer to the same artifact. |
source and target |
The sender and receiver identity context. | Separates who produced the message from what the message says. |
conversation |
Conversation, turn, sequence, and trace context. | Connects one exchange to a larger workflow or distributed trace. |
delivery |
Sync/async mode, priority, expiry, replies, acknowledgements, and task references. | Clarifies whether the receiver should respond immediately, acknowledge, or track a task. |
trust |
Channel, scheme, principal, credential, signature, and replay-window context. | Preserves the trust assumptions behind a cross-boundary exchange. |
body |
The profile-specific payload. | Contains the actual request, response, capability statement, error, conformance record, or task status. |
provenance |
Trace, issue time, log reference, agent, model, and confidence context where provided. | Lets reviewers ask where the record came from and how it was produced. |
integrity |
Algorithm, canonicalization, checksum, and related reproducibility anchors. | Lets a verifier detect whether the reviewed payload changed. |
extensions |
Optional extension records outside the core profile shape. | Keeps additions visible instead of hiding them in undeclared fields. |
Body families
| Profile | Body usually needs to answer | Example body fields to inspect |
|---|---|---|
uai.intent.request.v1 |
What is requested, what subject it applies to, and which response profile is expected? | intent, subject, requested_profile, parameters, constraints, response_profile |
uai.intent.response.v1 |
Was the request accepted, rejected, completed, or redirected into async task state? | status, subject, result, task_ref, errors |
uai.capability.statement.v1 |
Which profiles, operations, transports, trust channels, and conformance levels can this implementation claim? | supported_profiles, operations, transport_bindings, trust_channels, conformance_levels |
uai.error.v1 |
Which named error occurred and what should the receiver inspect next? | code, message, target, details, remediation |
uai.conformance.result.v1 |
Which public artifacts were checked and what did validation prove? | checked_profile, result, issues, checked_artifact_urls, canonical_hash |
uai.task.status.v1 |
What is the task state and where can the result or blocker be found? | subject, state, progress, blocked_by, result_profile, result_ref |
How to read a payload
- Start with
profile. It chooses the schema family and body expectations. - Check identity and delivery. Make sure source, target, conversation, delivery, and trust fields match the boundary being crossed.
- Inspect the body against the profile. Do not borrow fields from another profile unless the registry and schema allow them.
- Verify provenance and integrity. Confirm trace context, issue time, log reference, and checksum evidence describe the exact payload.
- Use UAIX validator output. Treat typed errors as the route to the next schema, registry, field-registry, trust, or transport record.
Compact-transfer note
UAIX also publishes field-registry material for compact or keyless transport cases. LlmWikis should describe that as a published UAIX behavior, not as a local invention. If a compact packet cannot be expanded through the public field registry into the same keyed record, it should not be used as support evidence.