Standards Fit

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.

Quick chooser

Use this section when the question is not whether UAI-1, MCP, or A2A is better in the abstract, but which layer owns the work in front of you.

UAI-1 vs MCP

• MCP asks: what tools, resources, prompts, and context can this model client use in this host session?
• UAI-1 asks: what portable exchange record can another system validate, cite, replay, review, or attach to release evidence?
• Bridge rule: an MCP tool call can map into uai.intent.request.v1 and an MCP resource or tool result can map into uai.intent.response.v1. The mapping does not turn UAI-1 into the MCP session lifecycle.
• Use together when: a local tool result becomes cross-team evidence, a release artifact, a public fixture, or an implementation-support claim.

UAI-1 vs A2A

• A2A asks: which agent can do this work, how is the task delegated, and how does task state move while the work is running?
• UAI-1 asks: which request, capability statement, task-status record, response, error, or conformance result needs to remain portable after the runtime conversation ends?
• Bridge rule: an A2A Agent Card can map into uai.capability.statement.v1, and an A2A task update can map into uai.task.status.v1. The mapping does not make UAI-1 the A2A discovery, delegation, or streaming protocol.
• Use together when: delegated agent work needs a validator-backed handoff record, audit trail, public launch packet, or implementation evidence.

Decision questions

1. Is the main problem local tool/resource access inside a host session? Start with MCP.
2. Is the main problem peer-agent discovery, delegation, or task coordination? Start with A2A.
3. Does the record need to travel across teams, vendors, releases, audits, or public implementation claims? Add UAI-1.
4. Does the work need a public proof packet? Resolve UAI-1, schemas, registry, examples, and validator output before widening support language.

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.traceparent and 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.

Agentic systems architecture path

Use this path when a reader asks how UAIX fits a production agentic harness. The harness runs the work; UAIX preserves the portable evidence and handoff record that must survive the run.

The practical rule is: let runtimes execute, let MCP connect tools, let A2A coordinate agents, let observability systems trace behavior, and let UAIX publish the validator-ready record, conformance packet, and project-memory handoff that another party can inspect.

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.v1 record, 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.v1 and the result can map into uai.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

1. Keyed JSON: the human-readable source record for review, docs, validator output, and support claims.
2. 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.
3. 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.
4. Alias JSON: planned work until public alias maps, fixtures, normalization rules, and validator expectations exist.
5. 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"
  }
}

{"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"],null,null,[]]

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.