Purpose
Standards Fit explains where UAI-1 belongs beside adjacent agent, tool, API, identity, tracing, schema, and transport systems. It is a launch-stage boundary page: useful for implementers, reviewers, and public readers who need the fit without turning current bridge evidence examples into overbroad support claims.
Core comparison
A2A coordinates agents, MCP connects tools and resources, UAI-1 records the portable exchange. OpenAPI describes HTTP APIs, JSON Schema validates message structure, DID/VC-style systems can support trust evidence, Trace Context carries distributed trace linkage, and CBOR or MessagePack can become future compact transport bindings only when the evidence path exists.
Adjacent standards map
- A2A: can own peer-agent discovery, delegation, task streaming, and collaborative task state. UAI-1 can record the portable request, result, task status, or capability evidence that should remain reviewable outside the runtime session.
- MCP: can own host-client-server tool calls, resource reads, prompts, and application-local capability negotiation. UAI-1 can record the public exchange when a tool result or request needs to leave that local boundary.
- OpenAPI: describes HTTP operations and route contracts. UAIX publishes OpenAPI for its REST surface while UAI-1 describes the message record that can travel through or beside those routes.
- JSON Schema: checks structure for current UAI-1 profiles. It is the validation companion to the written specification, not a replacement for semantic guidance or release discipline.
- DID/VC, mTLS, and signed envelopes: can support trust assertions declared through
trust,credential_ref,signature_ref, and companion transport layers without becoming one mandatory identity stack. - Trace Context: can travel through
conversation.traceparentand related provenance fields when distributed tracing already exists. - Problem Details: informs the style of typed public failures, while UAI-1 keeps profile-specific error records and validator issue codes attached to its own registry.
Bridge-profile boundary
The Adoption Kit and Conformance Pack now carry validator-backed bridge evidence examples. Formal bridge profiles should still map evidence into UAI-1 records without taking over adjacent runtime behavior.
- An A2A Agent Card can map into a
uai.capability.statement.v1record, but A2A still owns native discovery and task execution. - An A2A task update can map into
uai.task.status.v1, but UAI-1 does not become the streaming task protocol. - An MCP tool call can map into
uai.intent.request.v1and the result can map intouai.intent.response.v1, but MCP still owns session lifecycle and tool invocation. - An OpenAPI operation reference can appear in UAI-1 provenance or body metadata, but OpenAPI still describes the HTTP API.
- DID/VC trust evidence and Trace Context linkage can be declared in the envelope, but UAI-1 does not require one global credential or tracing stack.
Compact transfer ladder
- Keyed JSON: the human-readable source record for review, docs, validator output, and support claims.
- Minified keyed JSON: the same keyed record without whitespace for simple transfer where readability is less important; the validator treats it as the same keyed record.
- Keyless JSON: a compact array form that uses the public field registry to reconstruct the keyed record before validation; the validator currently accepts this mode.
- Alias JSON: planned work until public alias maps, fixtures, normalization rules, and validator expectations exist.
- CBOR or MessagePack: research-track or future transport work until encode/decode parity, route behavior, and conformance evidence are published.
Normalization rule
The current validator supports keyed-json, minified-keyed-json, and keyless-json. Every accepted compact form must normalize back to full keyed JSON before schema validation, JCS canonicalization, hashing, signatures, validator evidence, release notes, or public support claims. Field order is a transport map; the reconstituted keyed JSON record is the review and integrity baseline.
Example comparison
The examples below are intentionally small. They show the relationship between readable, minified, and keyless forms without presenting alias or binary support as current public behavior.
{
"uai_version": "1.0",
"profile": "uai.intent.request.v1",
"message_id": "msg-demo-001",
"body": {
"intent": "resolve-profile",
"subject": "uai.task.status.v1"
}
}[
"1.0",
"uai.intent.request.v1",
"msg-demo-001",
null,
null,
null,
null,
null,
[
"resolve-profile",
"uai.task.status.v1"
]
]Field order follows the keyed JSON example, the published schema order, and the public field registry.
{"uai_version":"1.0","profile":"uai.intent.request.v1","message_id":"msg-demo-001","body":{"intent":"resolve-profile","subject":"uai.task.status.v1"}}[
"1.0",
"uai.intent.request.v1",
"msg-demo-001",
null,
null,
null,
null,
null,
[
"resolve-profile",
"uai.task.status.v1"
]
]Field order follows the keyed JSON example, the published schema order, and the public field registry.
["1.0","uai.intent.request.v1","msg-demo-001",null,null,null,null,null,["resolve-profile","uai.task.status.v1"],null,null,[]][
"1.0",
"uai.intent.request.v1",
"msg-demo-001",
null,
null,
null,
null,
null,
[
"resolve-profile",
"uai.task.status.v1"
],
null,
null,
[]
]Field order follows the keyed JSON example, the published schema order, and the public field registry.
Current public support boundary
- Current support includes keyed JSON, minified keyed JSON, keyless JSON normalization, schemas, registry records, examples, the field registry, validator behavior, canonical-hash equivalence evidence, bridge evidence examples, the conformance pack, and implementation tracks.
- Keyless transfer is tied to the public field registry and must remain reversible into keyed JSON.
- Alias maps, binary envelope media types, formal bridge profiles, SDKs, CLIs, and formal certification stay planned or research-track until public evidence moves them forward.
- No standards-fit language should imply that UAI-1 replaces A2A, MCP, OpenAPI, JSON Schema, DID/VC systems, tracing, signing, or transport protocols.
Where to verify the current record
Use UAI-1 for the contract, Schemas, Registry, Examples, and the Validator for evidence, API Reference and Conformance Pack for machine-facing handoff, and Roadmap plus Changelog for the future boundary and release trail.