Standards Fit

Purpose#

标准定位 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 模式 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? 解析 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 模式: 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 接入套件 and 一致性包 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.

紧凑传输 ladder#

1. 有键 JSON: the human-readable source record for review, docs, validator output, and support claims.
2. 精简有键 JSON: 同一条有键记录去掉空白，适用于可读性不那么重要的简单传输；验证器会将其视为同一条有键记录。
3. 无键 JSON: 一种紧凑数组形式，会使用公共 field registry 在验证前重建有键记录；验证器当前接受此模式。
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.

规范化 rule#

当前验证器支持 keyed-json, minified-keyed-json, and keyless-json. 每一种被接受的紧凑形式，都必须先规范化回完整有键 JSON，然后才能进行模式验证、JCS 规范化、哈希、签名、验证器证据、发布说明或公共支持声明。字段顺序是传输映射；重建后的有键 JSON 记录才是审查与完整性基线。

示例 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"
    ]
]

{"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"
    ]
]

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

当前 public support boundary#

• 当前 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 实施轨道.
• 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 模式, DID/VC systems, tracing, signing, or transport protocols.

Where to verify the current record#

Use UAI-1 for the contract, 模式, 注册表, 示例, and the 验证器 for evidence, API 参考 and 一致性包 for machine-facing handoff, and 路线图 plus 变更日志 for the future boundary and release trail.