UAIX Roadmap And Interoperability Report

Updated: 2026-04-24

Metadata

Field	Value
Source site	uaix.org
Source URL	https://uaix.org/
Canonical AIWikis URL	https://aiwikis.org/uaix/files/raw-system-archives-uaix-internal-memory-reorg-2026-05-01-docs-uaix-road-ec17db8e/
Source reference	raw/system-archives/uaix/internal-memory-reorg/2026-05-01/docs/UAIX_roadmap_and_interoperability_report.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-04-24T02:40:51.1196917Z
Content hash	sha256:ec17db8e6230ab35857461572354d505c775a0e14c03323d38723d1273567178
Import status	unchanged
Raw source layer	data/sources/uaix/raw-system-archives-uaix-internal-memory-reorg-2026-05-01-docs-uaix-roadmap-and-interoperability-ec17db8e6230.md
Normalized source layer	data/normalized/uaix/raw-system-archives-uaix-internal-memory-reorg-2026-05-01-docs-uaix-roadmap-and-interoperability-ec17db8e6230.txt

Current File Content

Structure Preview

• UAIX Roadmap And Interoperability Report
• Status
• How To Use This Document
• Adopted Into Canonical Docs
• Executive summary
• Current UAIX public record
• Comparative positioning and bridge profiles
• Tokens, bytes, and compression
• Measurement basis and assumptions
• Byte and token table
• Reversible compression ladder
• Canonicalization strategy
• Validator changes and conformance tests
• Prompt-caching and reference best practices
• Twelve-month roadmap
• Priority table
• Timeline
• Living refinement and limitations

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 29996
• Preview characters: 11509

# UAIX Roadmap And Interoperability Report

Updated: 2026-04-24

## Status

This is a background roadmap and interoperability analysis.

It is not the canonical roadmap. Use `docs/roadmap.md` for current open roadmap work, `docs/Mission and Site Plan for UAIX.md` for public positioning and information architecture, and `docs/uaix-terminology.md` for naming.

## How To Use This Document

- Use this report for deeper rationale around interoperability positioning, bridge profiles, compact transfer, canonicalization, validator modes, conformance fixtures, and release cadence.
- Treat the profile names, timing, owners, token counts, and bridge examples below as source recommendations unless `docs/roadmap.md` adopts them.
- When this file conflicts with `docs/roadmap.md`, `docs/current-reference.md`, `docs/Mission and Site Plan for UAIX.md`, `docs/deploy.md`, or `docs/uaix-terminology.md`, those canonical docs win.

## Adopted Into Canonical Docs

The durable ideas adopted into the current doc set are:

- UAI-1 should be framed as the durable, reviewable, publishable exchange record that travels beside A2A, MCP, OpenAPI, JSON Schema, DID/VC, Trace Context, OpenTelemetry, and optional binary transports.
- The field registry should be treated as a versioned release artifact for compact/keyless transport, while JCS canonicalization remains the cryptographic source of truth for hashes and signatures.
- Validator and conformance work should prove round-trip normalization across keyed, minified-keyed, alias, keyless, and future binary-envelope forms before any compact-transfer claim becomes public support language.
- A2A, MCP, OpenAPI, DID/VC, and Trace Context bridge work should stay declarative and evidence-oriented; UAIX should map records, not take over runtime sessions, tool lifecycles, identity systems, or tracing stacks.
- Token-efficiency work should separate prompt-facing text formats from non-prompt binary transport, publish byte/character/keyed/minified/keyless deltas, and only add exact model token counters when a maintainable benchmark path exists.
- The conformance pack should mature into an interoperability kit with positive and negative fixtures, canonical hashes, benchmark tables, and implementation evidence.

## Executive summary

UAIX's public site now presents UAI-1 as more than a message envelope. The public record explicitly says the current release includes the specification, schemas, field registry, transport bindings, trust channels, error registry, conformance levels, examples, validator guidance, implementation tracks, and the changelog. The machine-facing surface also now advertises an API reference, an OpenAPI 3.1 export, and a conformance pack. The public field registry JSON identifies the current release as UAI-1 / `uai_version` `1.0`, with a `release_date` of April 22, 2026, and publishes ordered root fields, component orders, and body orders for six message profiles. That combination is already strong enough to support a serious "portable exchange record" strategy.

The clearest strategic position is the one UAIX itself now hints at: do **not** try to replace runtime protocols. A2A is for agent-to-agent collaboration and task management; MCP is for agent-to-tool/resource interaction; OpenAPI is for HTTP API surface description; JSON Schema is for structural validation; DIDs and Verifiable Credentials are for decentralized identity and tamper-evident claims; W3C Trace Context and OpenTelemetry are for distributed tracing and observability. UAIX fits best as the durable, reviewable, publishable record that travels across those systems, not as a replacement for them.

On compactness, the most important result is simple: for LLM-facing text, **minified keyed JSON is already a good baseline, keyless JSON is materially better, and binary encodings only win decisively if they travel out-of-band or on non-LLM transport paths**. Using the official UAIX request example published on the site, exact UTF-8 bytes fall from about 1,199 bytes for minified keyed JSON to 660 bytes for keyless JSON, 807 bytes for a short-alias object form, and roughly 579-581 bytes for raw MessagePack/CBOR. But if those binary forms must be base64-wrapped to enter a text-only prompt, they rebound to about 772-776 bytes. In practice this means the roadmap should prioritize a **reversible compression ladder**: human-readable keyed JSON, minified keyed JSON, short-alias JSON, keyless JSON, then binary transport for non-prompt channels. Calculations below are mine from the official example payloads.

The most important next-12-month moves are therefore: freeze the canonical field-order and profile-code registries; make JCS-based canonicalization fully normative; add validator support for keyed, minified, alias, keyless, and binary round-trips; publish bridge profiles for A2A, MCP, OpenAPI, DID/VC, and tracing; and turn the conformance pack into a release-quality interoperability kit with fixtures, canonical hashes, and benchmark tables. That is the shortest path from an interesting public contract to a durable interoperability standard.

## Current UAIX public record

The strongest part of UAIX today is that the site's own public narrative is already aligned with a standards-release posture. The homepage says UAI-1 is the current published release, that it is meant for exchanges that must stay portable, reviewable, and publishable, and that the public proof path runs through the specification, examples, field registry, validator, implementation tracks, API reference, and conformance pack. That is exactly the right framing if UAIX wants to become the publishable evidence layer around agent and API systems rather than "yet another runtime protocol."

The field registry is especially important because it turns "compact transport" from an informal trick into public, versioned governance. It defines the twelve root fields in order - `uai_version`, `profile`, `message_id`, `source`, `target`, `conversation`, `delivery`, `trust`, `body`, `provenance`, `integrity`, `extensions` - and also publishes component orders for `source`, `target`, `conversation`, `delivery`, `trust`, `provenance`, `integrity`, and `extension_item`. It further publishes body orders for six current profiles: `uai.intent.request.v1`, `uai.intent.response.v1`, `uai.capability.statement.v1`, `uai.error.v1`, `uai.conformance.result.v1`, and `uai.task.status.v1`. That is the kernel UAIX needs for deterministic keyless transport, compact fixtures, profile-aware validation, and reliable round-trips.

The official example payload also shows that UAIX already has the right conceptual primitives. The readable JSON example carries explicit source and target objects, conversation state, delivery semantics, trust hints, a profile-specific body, provenance, and integrity. The example uses `mode: "async"`, a `did+vc` trust scheme, a `trace_id`, and `canonicalization: "jcs"`, which means the standard is already reaching toward async workflows, credential-linked trust, trace linkage, and deterministic hashing. The same example is then rendered as keyless JSON, with the site stating that field order follows the keyed source plus the published schema order and field registry.

The public site also now advertises a "launch-stage policy and release posture" that includes policy/security, governance, references/contributors, and a dated changelog. That is promising because technical interoperability standards fail in practice when release ownership, change discipline, and support boundaries are implicit. UAIX is explicitly trying to make those visible. The site also names the current public implementation tracks as the WordPress Publication Track and the .NET Bridge Track, which indicates that the project already distinguishes normative public artifacts from specific implementation lanes.

There are still meaningful gaps. The public surfaces clearly exist, but in this environment not every linked page was directly retrievable line-by-line, so some audit conclusions rely on UAIX's own homepage description of those artifacts plus the accessible field registry JSON. In particular, I could verify the existence and intended role of the validator, API reference, conformance pack, governance, policy/security, and changelog surfaces from UAIX's public landing page, but not inspect every subpage in full. That means the roadmap should treat governance hardening, validator transparency, and conformance-pack completeness as still in-progress rather than fully matured.

| Audit area | High-confidence finding | Why it matters | Roadmap implication |
|---|---|---|---|
| Specification scope | UAIX positions UAI-1 as a versioned public exchange contract and evidence path | Strong strategic focus | Keep scope narrow; do not absorb runtime orchestration |
| Field registry | Public, versioned order registry exists and is already detailed | Enables keyless transport and deterministic transforms | Make registry normative and immutable by release |
| Examples | Official readable and keyless examples are published | Enough to anchor conformance fixtures | Expand fixture set with alias and binary forms |
| Validator | Public validator/workbench is part of proof surface | Crucial for support claims | Add round-trip and canonicalization modes |
| Governance/changelog | Public trust-surface pages are linked and framed as release discipline | Necessary for real standardization | Formalize authority model and approval workflow |
| Implementation tracks | WordPress and .NET tracks are explicitly scoped | Healthy separation of spec vs implementation | Add neutral SDK / reference-transcoder track |

Audit sources: UAIX homepage public record, launch-kit descriptions, example payloads, and field registry JSON.

## Comparative positioning and bridge profiles

A2A and MCP are the most important adjacent systems to compare directly because they occupy the two runtime layers UAIX should avoid re-implementing. The A2A specification says it is designed to let independent agent systems discover capabilities, negotiate modalities, manage collaborative tasks, and securely exchange information without exposing internal state; it requires A2A servers to publish an Agent Card, and its JSON-RPC binding uses HTTP and SSE for streaming. The A2A documentation also explicitly says A2A and MCP address "distinct but highly complementary needs," with A2A focused on agents partnering on tasks and MCP focused on agents using capabilities.

MCP's architecture, by contrast, is a JSON-RPC-based client-server protocol with a rigorous initialize/operate/shutdown lifecycle, explicit capability negotiation, and server primitives for tools, resources, and prompts. Its standard transports are stdio and Streamable HTTP, with optional SSE and session management for HTTP flows. MCP is therefore a runtime bus and capability surface, not a public release record.

OpenAPI and JSON Schema sit one layer lower. The OpenAPI Initiative defines OpenAPI as a language-agnostic interface description for HTTP APIs, used for documentation, code generation, testing, and other tooling. JSON Schema's current version is 2020-12; its specification is split into Core and Validation and it publishes meta-schemas and recommended output schemas. Together they are perfect for route description and data validation, but they do not solve UAIX's central problem of a portable, auditable, semantically rich exchange record that survives beyond a local runtime.

Why This File Exists

This is a memory-system evidence file from uaix.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: UAIX Roadmap And Interoperability Report; Status; How To Use This Document; Adopted Into Canonical Docs; Executive summary; Current UAIX public record; Comparative positioning and bridge profiles; Tokens, bytes, and compression. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-1132 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "UAIX Roadmap And Interoperability Report",
    "source_site":  "uaix.org",
    "source_url":  "https://uaix.org/",
    "canonical_url":  "https://aiwikis.org/uaix/files/raw-system-archives-uaix-internal-memory-reorg-2026-05-01-docs-uaix-road-ec17db8e/",
    "source_reference":  "raw/system-archives/uaix/internal-memory-reorg/2026-05-01/docs/UAIX_roadmap_and_interoperability_report.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:ec17db8e6230ab35857461572354d505c775a0e14c03323d38723d1273567178",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-04-24T02:40:51.1196917Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-1132",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}