UAI-1 is the current public message standard for structured AI-to-AI communication.
UAIX shield mark Public interoperability charter UAIX.org Universal Artificial Intelligence Exchange Public standards publication
Current UAI-1
  • Current version UAI-1
  • Plain-English definition Open message format for auditable AI-to-AI exchange
  • Current attribution Michael Joseph Kappel, MCP
  • Start here Get Started, Project Handoff, UAI-1, validator, roadmap, and changelog

Roadmap

Roadmap

Current forward roadmap for UAI-1 launch hardening, standards-fit explanation, conformance maturity, developer support, interoperability evidence, and compact-transfer discipline.

  • Record UAIX-DOC-0063
  • Path /en-us/roadmap/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-DOC-0063
Surface
Roadmap
Access
Public and linkable

How to use this page

Use this page to distinguish current support from next, planned, and research-track work before repeating roadmap claims.

Proof path

UAI-1ValidatorAPI ReferenceConformance Pack

Forward Boundary

What is current, what is next, and what is not a launch claim

Use the roadmap to keep future-facing interoperability and conformance ideas attached to clear public evidence before they become support language.

Current

Published record first

Treat UAI-1, the operating registries, validator, implementation tracks, and conformance pack as the current public support surface.

Next

Launch hardening

Keep package checks, discovery files, locale routes, security headers, accessibility QA, and Chinese copy aligned before broad publication.

Planned

Evidence before claims

Bridge profiles, normalization modes, compact transfer, and developer tooling need fixtures and validator-backed evidence before support claims widen.

Proof path

UAI-1Current normative contract.ValidatorEvidence before public support claims.API ReferenceRoute handbook and OpenAPI export.Conformance PackReusable launch-review packet.ChangelogDated migration and support posture.
Roadmap JSONMachine-readable future-work boundary
curl -s http://uiax.org/wp-json/uaix/v1/roadmap

Resolve the roadmap route when automation needs the same current, next, planned, research-track, metric, and non-claim boundaries that readers see on this page.

Roadmap boundary map

How future work becomes current public support

Use this matrix to keep launch hardening, interoperability evidence, compact transfer, and developer handoff work separate from claims that are already published.

Work areaPublished nowVerify hereFuture boundary
Standards fitUAI-1 is positioned as the public envelope, trust, and release-evidence layer beside A2A, MCP, OpenAPI, DID/VC, Trace Context, and Problem Details.Bridge evidence examples are current; formal bridge profiles still need broader fixtures and validator expectations before they become support claims.
Compact transferReadable keyed JSON, minified keyed JSON, and field-registry-backed keyless JSON are current validator normalization modes.Alias and binary formats stay planned or research-track until round-trip fixtures, route behavior, and validator normalization are published.
Conformance maturityThe validator and conformance pack publish today's evidence path for schemas, registry records, examples, keyed/minified/keyless normalization, implementation evidence checklist answers, bridge evidence examples, canonical-hash equivalence, invalid traceparent, DID/VC trust evidence, required-field, undeclared-field, keyless-overflow, and support boundaries.Alias normalization, binary-envelope normalization, raw duplicate-key detection, CI fixtures, and formal bridge-profile fixtures are still future evidence work.
Developer handoffProject Handoff, AGENTS.md .uai linking guidance, API Reference, Adoption Kit, OpenAPI, implementation evidence checklist, bridge evidence pack, and Conformance Pack are the current developer handoff bundle.Reusable .uai generators, starter template ZIPs, upload validators, SDKs, CLI tools, public repositories, and broader runtime catalogs need fixtures, ownership, and maintenance before launch copy can claim them.

The roadmap is a public planning surface, not a certification statement. A planned idea becomes current support only when the page copy, machine artifact, validator behavior, implementation evidence, and release trail agree.

Roadmap promotion path

How planned work becomes current support

Use this sequence when a roadmap idea moves into published behavior or public support language.

  1. Step 1

    Publish the canonical page change

  2. Step 2

    Publish the matching machine artifact

  3. Step 3

    Add fixture and validator expectations

  4. Step 4

    Attach implementation or package evidence

  5. Step 5

    Record the dated release trail

If one of these steps is missing, the idea should stay planned or research-track rather than being described as current support.

How to read this roadmap

Use this page as the public forward plan for the UAI-1 launch surface. It is synchronized with the canonical workspace roadmap, but it stays scoped to what readers and implementers can verify on the site.

  • Current means the record is already published as a page, route, package, validator behavior, or release note.
  • Next means launch-hardening work that should happen before a broader public push.
  • Planned means adopted future work that still needs fixtures, tooling, or governance before it becomes a public claim.
  • Research-track means useful input that is not a current launch commitment.

Already current, not roadmap work

  • UAI-1 already publishes the shared envelope, six profiles, field registry, transport bindings, trust channels, error registry, conformance levels, schemas, registry entries, examples, validator guidance, implementation tracks, API Reference, Adoption Kit, OpenAPI route, Conformance Pack, implementation evidence checklist, conformance fixture pack, bridge evidence pack, mock exchange, and release trail.
  • Public launch routes are clean locale-prefixed paths. Query-string URLs are not the public launch surface.
  • The launch package path is scripted and smoke-tested through the WordPress publishing workflow.
  • Project Handoff, the AGENTS.md .uai linking specification, the Reports index, and the refining report are current public pages; .uai generators, templates, validators, SDKs, and CLI tools remain future support work.

Now before launch

  1. Production hardening: keep package output, root discovery files, sitemap delivery, security headers, locale routing, and launch audits aligned before going public.
  2. Content and accessibility QA: re-check mobile readability, headings, copy controls, validator flows, long route examples, and Chinese release copy when page text changes.
  3. Public operating layer: keep governance, references, policy pages, changelog entries, Project Handoff, AGENTS.md .uai guidance, reports, and the roadmap synchronized so readers do not need private notes.
  4. Standards-fit explanation: keep explaining how UAI-1 sits beside A2A, MCP, OpenAPI, DID/VC, Trace Context, JCS, and Problem Details without claiming to replace them.
  5. Conformance maturity: keep validator results, conformance packets, implementation evidence checklist answers, fixture-pack expectations, bridge evidence examples, and implementation-track evidence together before widening support claims.

Current bridge evidence and next interoperability work

The strongest near-term interoperability story is bridge evidence, not replacement claims. UAI-1 should remain the public envelope and release-record layer while adjacent systems keep their runtime roles.

  • A2A: use current bridge evidence examples and future formal bridge profiles to show how agent discovery, delegation, and task-flow coordination can carry UAI-1 records.
  • MCP: use the current tool-call and resource-result evidence examples to show how host-client-server tool sessions can produce or consume UAI-1 messages when a record needs to travel outside a local application boundary.
  • OpenAPI: keep the published OpenAPI document tied to the REST surface while UAI-1 remains the message-contract layer.
  • DID/VC and signing: keep trust material declared in the envelope without making one identity stack mandatory.
  • Trace Context: keep traceparent support testable where distributed tracing is part of the workflow.

Compact transfer and canonicalization

Compact forms are useful only if they preserve the reviewable keyed source record. The field registry is the public map for keyless transport; canonicalization and public conformance evidence should operate on reconstituted keyed JSON.

  • Keyed JSON remains the readable source of truth.
  • Keyless JSON must reconstruct through the field registry before schema validation, hashing, signing, or conformance evidence.
  • JCS canonicalization should apply to the reconstructed keyed JSON record, not to an ambiguous transport shortcut.
  • Alias-key and binary-envelope variants remain planned or research-track work until fixtures, validator normalization, and route behavior are published.

Evidence metrics

  • Public conformance packet count.
  • Normalization mode coverage for keyed, minified-keyed, keyless, alias, and future binary paths.
  • Positive and negative conformance fixture coverage, canonical-hash equivalence coverage, traceparent and DID/VC trust-boundary coverage, and required-field, undeclared-field, and keyless-overflow regression coverage.
  • Bridge evidence example count and future formal bridge-profile fixture coverage for A2A, MCP, OpenAPI, DID/VC, Trace Context, and Problem Details mappings.
  • Project-handoff route coverage, AGENTS.md link-guidance coverage, and loader-guardrail coverage for repository-context handoffs.
  • Implementation-evidence checklist completion, implementation-track evidence count, and byte-size deltas across compact formats.
  • Release-note completeness for every public artifact, route, policy, or validator change.

What this roadmap does not claim

  • UAIX is not publishing a certification program today.
  • UAI-1 does not replace A2A, MCP, OpenAPI, identity, signing, tracing, or transport systems.
  • Current bridge evidence examples are mapping examples, not completed bridge profiles, SDK support, or certification claims.
  • Alias and binary transport formats are not public support until validator-backed fixtures and route behavior are published.
  • Project Handoff and AGENTS.md-linked .uai files are draft repository-context guidance, not UAI-1 conformance evidence, certification, or endorsement by themselves.
  • One passing validator result is evidence for one reviewed packet, not blanket ecosystem support.

Machine-readable roadmap

The public roadmap is also available as /wp-json/uaix/v1/roadmap. Use that route when automation needs the current priority list, interoperability adjacency map, normalization-mode boundary, metrics, and non-claims.

Follow the active proof path

When a roadmap item moves from planned work to current support, it should update the affected public page, the machine artifact, the validator expectation, the implementation evidence checklist, fixture pack, and the release trail together. Start from UAI-1, verify with the Validator, use the API Reference, carry the Adoption Kit and Conformance Pack, answer the checklist, then record the change on the Changelog and News.