Specification

Standards Fit

How UAI-1 sits beside A2A, MCP, OpenAPI, JSON Schema, DID/VC, Trace Context, compact transfer, and current bridge evidence examples.

  • Record UAIX-SPEC-0047
  • Path /en-us/specification/standards-fit/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-SPEC-0047
Surface
Specification
Access
Public and linkable

How to use this page

Use this page to explain how UAI-1 sits beside A2A, MCP, OpenAPI, JSON Schema, DID/VC, Trace Context, and compact transfer work.

Verify fit

UAI-1Field RegistryRoadmapConformance Pack

Standards Fit

UAI-1 as the portable public exchange record

Use this page when a reader needs the boundary between UAI-1 and adjacent agent, tool, API, identity, tracing, schema, or compact-transfer systems.

Boundary

Record, not replacement

UAI-1 records portable exchange evidence while adjacent protocols keep their runtime jobs.

Transfer

Reversible compact forms only

Compact transfer remains useful only when it can reconstruct keyed JSON before validation, hashing, signing, or support claims.

Evidence

Fixtures before bridge claims

Bridge evidence examples are current; formal bridge profiles stay planned until broader validator expectations and release evidence exist.

Verify fit

UAI-1Current public exchange contract.Field RegistryKeyed and keyless field-order map.RoadmapCurrent bridge evidence and compact-transfer boundary.Conformance PackReusable release evidence packet.

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

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"
  }
}
Transfer formatOptimized (Keyless) JSON
[
    "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"}}
Transfer formatOptimized (Keyless) JSON
[
    "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,[]]
Transfer formatOptimized (Keyless) JSON
[
    "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.