UAIX Org Expanded Roadmap

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-expa-141feaa3/
Source reference	raw/system-archives/uaix/internal-memory-reorg/2026-05-01/docs/uaix_expanded_roadmap.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-04-24T18:47:06.1897274Z
Content hash	sha256:141feaa3c3f07609adb7a54ba22d74c94eae5e2983b9feff28e4b24d041cd8f4
Import status	unchanged
Raw source layer	data/sources/uaix/raw-system-archives-uaix-internal-memory-reorg-2026-05-01-docs-uaix-expanded-roadmap-md-141feaa3c3f0.md
Normalized source layer	data/normalized/uaix/raw-system-archives-uaix-internal-memory-reorg-2026-05-01-docs-uaix-expanded-roadmap-md-141feaa3c3f0.txt

Current File Content

Structure Preview

• UAIX.org Expanded Roadmap
• Status
• How To Use This Document
• Current Alignment With The Site
• Working title
• Core positioning
• Strategic goals
• Goal 1: Make UAIX credible as a public standards surface
• Work items
• Success metric
• Goal 2: Make token efficiency a first-class design pillar
• Token-efficiency principles
• Current compression opportunity
• Token-efficiency warning
• System comparison roadmap
• A2A comparison
• Action items
• MCP comparison
• OpenAPI comparison
• JSON Schema comparison
• DID / Verifiable Credential comparison

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: 23046
• Preview characters: 11934

# UAIX.org Expanded Roadmap

Updated: 2026-04-24

## Status

This is an expanded roadmap input and idea bank.

It is not the canonical roadmap. Use `docs/roadmap.md` for current open roadmap work.

## How To Use This Document

- Use this note for deeper rationale around standards-fit, token efficiency, A2A/MCP bridge evidence, compact transfer, governance, and roadmap metrics.
- Use `docs/UAIX_roadmap_and_interoperability_report.md` as the companion source for field-registry governance, JCS canonicalization, validator normalization modes, bridge-profile names, conformance fixtures, and compact-transfer benchmark rationale.
- Treat the route proposals and backlog items below as source ideas, not current site truth.
- When this file conflicts with `docs/roadmap.md`, `docs/Mission and Site Plan for UAIX.md`, `docs/deploy.md`, or `docs/uaix-terminology.md`, those canonical docs win.

## Current Alignment With The Site

Several ideas below are already complete or have current route equivalents:

- API Reference is already published at `/en-us/tools/api-reference/`.
- Adoption Kit is already published at `/en-us/tools/adoption-kit/`; treat older `/en-us/adoption-kit/` language as a route idea, not current IA.
- Conformance Pack is already published at `/en-us/tools/conformance-pack/`.
- OpenAPI is already published through the machine-facing UAIX route family.
- Privacy, accessibility, analytics, policy/security, launch-readiness, and changelog pages already exist under `/en-us/governance/...`.
- The public record already includes six profiles, the field registry, transport bindings, trust channels, error registry, conformance levels, validator, live mock exchange, schemas, registry, examples, and implementation tracks.

The still-useful ideas adopted into `docs/roadmap.md` are:

- public standards-fit explanation: A2A coordinates agents, MCP connects tools and resources, UAI-1 records the portable exchange
- token efficiency as measurable, reversible, validator-backed, and auditable
- bridge evidence for A2A and MCP as future evidence profiles or examples, not replacement claims
- implementation-evidence checklists and roadmap metrics
- future CBOR, MessagePack, alias dictionary, streaming, federation, and certification work kept as research tracks until ownership and validation exist

## Working title
**Universal Artificial Intelligence Exchange (UAIX): Public Exchange Contract, Compact AI-to-AI Communication, and Evidence-Based Interoperability**

## Core positioning
UAIX should present UAI-1 as a **public, validator-backed exchange contract** for AI-to-AI communication. It should not try to replace agent runtimes, tool-calling protocols, API-description standards, identity systems, or observability systems. Its strongest role is to define the portable record that can move across all of them.

**Simple statement:**
UAI-1 is the stable public record layer for structured AI-to-AI exchange: identity, intent, workflow state, delivery semantics, trust posture, provenance, integrity, results, and errors.

**What UAIX should own:**
- A public message envelope.
- Profile IDs and profile semantics.
- JSON Schema validation.
- Field-order registry for compact/keyless transport.
- Transport bindings.
- Trust-channel declarations.
- Error registry.
- Conformance levels.
- Validator exports.
- Release evidence packets.
- Implementation-track records.

**What UAIX should complement, not replace:**
- A2A for peer agent discovery, task collaboration, streaming, and long-running work coordination.
- MCP for model/application access to tools, APIs, data sources, and workflows.
- OpenAPI for describing conventional HTTP APIs.
- JSON Schema for data validation and documentation.
- W3C Trace Context / OpenTelemetry-style tracing for distributed observability.
- DIDs / Verifiable Credentials for identity and trust assertions.
- CBOR / MessagePack / other binary encodings for compact wire transfer when human-readable JSON is not required.

---

# Strategic goals

## Goal 1: Make UAIX credible as a public standards surface
UAIX should feel like a standards site, not a product landing page. Every major claim should point to a durable record: specification, schema, example, validator output, changelog, or implementation-track evidence.

### Work items
- Consider a public roadmap page only if it can stay synchronized with `docs/roadmap.md`.
- Consider a public comparison or standards-fit page that explains A2A, MCP, OpenAPI, JSON Schema, DID/VC, Trace Context, CBOR, and MessagePack boundaries.
- Consider a public token-efficiency page or section.
- Keep the already-published Adoption Kit at `/en-us/tools/adoption-kit/` current.
- Keep the already-published Conformance Pack at `/en-us/tools/conformance-pack/` current and add a clearer implementation-evidence template.
- Add a public contributor/contact path.
- Keep the existing privacy, accessibility, analytics, launch-readiness, and policy/security governance pages aligned with observable behavior; add terms or licensing pages only when the policy language is ready.

### Success metric
A new implementer can answer these questions in under 10 minutes:
1. What is UAI-1?
2. What does it validate?
3. How does it compare to A2A and MCP?
4. How do I send a minimal valid message?
5. How do I send a compact message?
6. How do I prove conformance?
7. What is currently supported versus experimental?

---

## Goal 2: Make token efficiency a first-class design pillar
Token reduction should be treated as an engineering constraint, not a gimmick. The system should preserve semantics while reducing repeated labels, excess prose, and redundant context.

### Token-efficiency principles
1. **Measure before optimizing.** Use exact model token counters when possible because tokenization varies by model and payload shape.
2. **Separate human-readable records from compact transfer.** Keep keyed JSON for readability and keyless or binary transport for machines.
3. **Short stable identifiers beat invented symbolic alphabets.** Custom Unicode may look compact but can tokenize poorly across models.
4. **Field registries reduce repeated labels.** Once both sides know the field order, repeated JSON keys can be omitted.
5. **Profile IDs reduce negotiation cost.** A compact profile ID tells the receiver how to interpret the body.
6. **Capability manifests reduce repeated instructions.** Send a capability hash or profile ID instead of re-sending long descriptions.
7. **Caching matters.** Put static specification/profile/tool context first and variable user/task data last.
8. **Use references for large data.** Send URIs, hashes, fixture IDs, file IDs, and result references instead of full repeated payloads.
9. **Summarize state, do not replay whole conversations.** Use conversation IDs, turn IDs, task IDs, and state summaries.
10. **Binary transport is optional but important.** JSON is the public record; CBOR/MessagePack can be a compact transport option later.

### Current compression opportunity
UAIX already publishes both keyed JSON and optimized keyless JSON. This is the correct pattern. The roadmap should formalize it:

- **Level T0:** Human-readable keyed JSON.
- **Level T1:** Minified keyed JSON.
- **Level T2:** Keyless JSON using the public field registry.
- **Level T3:** Keyless JSON plus short profile/field aliases.
- **Level T4:** Binary binding such as CBOR or MessagePack.
- **Level T5:** Binary binding plus dictionary/profile negotiation.

### Token-efficiency warning
Do not promote hidden or covert machine language as the primary efficiency mechanism. For safety and adoption, UAIX should prefer declared semantics, public registries, validator-readable records, and auditable compact encodings.

---

# System comparison roadmap

## A2A comparison
A2A is strongest for peer agent interaction: discovery, task lifecycle, streaming, push notifications, multimodal exchange, and enterprise agent collaboration.

**UAIX fit beside A2A:**
- Use A2A to coordinate the task.
- Use UAI-1 as the portable public exchange/evidence record.
- Add a UAIX extension profile for A2A Agent Cards.
- Add an adapter that maps A2A message/task/artifact objects into UAI-1 profiles.
- Add conformance fixtures for A2A-to-UAI and UAI-to-A2A translation.

### Action items
- Publish `uai.a2a.bridge.v1` profile.
- Add sample A2A Agent Card advertising UAI-1 support.
- Add mapping table: A2A Task -> UAI delivery/task.status; A2A Message -> UAI body; A2A Artifact -> UAI result/ref; A2A AgentCard -> UAI capability.statement.
- Create validator fixture: A2A request converted into UAI-1 exchange record.

---

## MCP comparison
MCP is strongest for connecting AI apps/agents to tools, APIs, files, databases, workflows, and external resources.

**UAIX fit beside MCP:**
- Use MCP for tool/resource execution.
- Use UAI-1 to record the public exchange, provenance, trust posture, and result contract.
- Add an MCP bridge profile that can capture MCP server identity, tool call summary, tool schema hash, and result reference without forcing the full MCP session into every UAI message.

### Action items
- Publish `uai.mcp.bridge.v1` profile.
- Add an MCP tool-call evidence record example.
- Add security guidance for prompt injection, tool permissions, and least-privilege resource access.
- Add a compact field registry for MCP bridge fields.

---

## OpenAPI comparison
OpenAPI is strongest for conventional HTTP API description, docs, code generation, testing, and gateway tooling.

**UAIX fit beside OpenAPI:**
- Use OpenAPI to describe UAIX REST endpoints.
- Use UAI-1 to describe the message contract flowing through those endpoints.
- Publish `/openapi.json` for UAIX WordPress REST endpoints.

### Action items
- Publish OpenAPI description for `/wp-json/uaix/v1/...` endpoints.
- Link each endpoint to the matching UAI profile and JSON Schema.
- Add generated client examples for C#, TypeScript, and Python only after support evidence exists.

---

## JSON Schema comparison
JSON Schema is the validation foundation for UAI-1. UAIX should continue using it, but clarify that schemas validate structure while the validator also checks policy and semantic constraints.

### Action items
- Add “schema validates structure; validator validates policy” explanation.
- Add schema version matrix.
- Add fixture corpus organized by profile.
- Add CI sample for validating fixtures.

---

## DID / Verifiable Credential comparison
DIDs and VCs are trust-layer technologies. UAI-1 should declare trust hints and references without mandating a single identity stack.

### Action items
- Publish trust binding examples:
  - `public-web`
  - `private-api`
  - `mtls`
  - `signed-envelope`
  - `credentialed`
- Add examples for `did:web`, credential reference, signature reference, replay-window hints, and trust degradation.
- Avoid claiming certification or identity assurance beyond what the message actually proves.

---

## W3C Trace Context / Observability comparison
Trace context is for distributed tracing across services. UAIX should carry trace IDs and traceparent values where systems already use them.

### Action items
- Add field guidance for `conversation.traceparent` and `provenance.trace_id`.
- Add example showing a task spanning A2A, MCP, and UAI-1 records with a shared trace context.
- Add logging guidance: log IDs and hashes, not sensitive payloads by default.

---

## CBOR / MessagePack comparison
Compact binary formats can reduce message size but are less human-readable than JSON. UAIX should treat them as optional transport bindings after the JSON public record is stable.

### Action items
- Research `application/vnd.uaix.uai+cbor`.
- Research `application/vnd.uaix.uai+msgpack`.
- Publish binary binding only after deterministic canonicalization, integrity hashing, validator support, and round-trip fixtures are ready.

---

# Roadmap phases

## Phase 0: Current-state cleanup

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.org Expanded Roadmap; Status; How To Use This Document; Current Alignment With The Site; Working title; Core positioning; Strategic goals; Goal 1: Make UAIX credible as a public standards surface. 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-098 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "UAIX Org Expanded Roadmap",
    "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-expa-141feaa3/",
    "source_reference":  "raw/system-archives/uaix/internal-memory-reorg/2026-05-01/docs/uaix_expanded_roadmap.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:141feaa3c3f07609adb7a54ba22d74c94eae5e2983b9feff28e4b24d041cd8f4",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-04-24T18:47:06.1897274Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-098",
    "duplicate_role":  "primary",
    "related_files":  [

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