Skip to content
aiWikis.org

UAIX Roadmap

Updated: 2026-05-02

Metadata

FieldValue
Source siteaiwikis.org
Source URLhttps://aiwikis.org/
Canonical AIWikis URLhttps://aiwikis.org/files/aiwikis/raw-system-archives-uaix-recent-work-sweep-2026-05-03-docs-roadmap-md-e656937b/
Source referenceraw/system-archives/uaix/recent-work-sweep/2026-05-03/docs/roadmap.md
File typemd
Content categorymemory-file
Last fetched2026-05-03T02:48:13.1276041Z
Last changed2026-05-02T19:39:17.7057324Z
Content hashsha256:e656937b9413a1f35f07a926f3f3292accb3bfa935296e83ec11018cd072c010
Import statusunchanged
Raw source layerdata/sources/aiwikis/raw-system-archives-uaix-recent-work-sweep-2026-05-03-docs-roadmap-md-e656937b9413.md
Normalized source layerdata/normalized/aiwikis/raw-system-archives-uaix-recent-work-sweep-2026-05-03-docs-roadmap-md-e656937b9413.txt

Current File Content

Structure Preview

  • UAIX Roadmap
  • Status
  • How To Use This Document
  • No Longer Roadmap Items
  • Roadmap Principles
  • Today Focus Path
  • Roadmap Work Documentation Ledger
  • Current Roadmap Work Queue
  • Evidence Promotion Gates
  • Support Claim Checklist
  • Near-Term Priorities
  • 1. Production Launch Hardening
  • 2. Accessibility And Content QA
  • 3. Public Operating Layer
  • 4. Standards-Fit And Token-Efficiency Explanation
  • 5. Conformance Program Maturity
  • 6. Developer Support
  • 7. Runtime And Release Architecture
  • Medium-Term Priorities
  • Longer-Horizon Research Tracks
  • Historical Inputs
  • Roadmap Metrics

Raw Version

# UAIX Roadmap

Updated: 2026-05-02

## Status

This is the canonical forward roadmap for the UAIX workspace.

Use this document for future priorities, roadmap planning, and deciding whether older recommendations are still open work.

## How To Use This Document

- Use this file for current and future roadmap decisions.
- Use `docs/Mission and Site Plan for UAIX.md` for mission, information architecture, and launch-surface ownership.
- Use `docs/deploy.md` for packaging, release, routing, and production validation.
- Use `docs/uaix-terminology.md` for naming.
- Treat older roadmap, audit, and research notes as background unless this document or `docs/current-reference.md` explicitly adopts their recommendations.
- Treat `docs/uaix_expanded_roadmap.md` and `docs/UAIX_roadmap_and_interoperability_report.md` as background idea sources behind the standards-fit, token-efficiency, bridge-evidence, canonicalization, validator-normalization, conformance-fixture, and metrics items adopted here.

## No Longer Roadmap Items

These items are already part of the current public record or release workflow and should not be carried forward as open roadmap work:

- clean locale-prefixed public routes under `/en-us/...`
- the active `uaix-authority-theme` launch surface
- the published UAI-1 specification, schemas, registry, examples, validator, and implementation tracks
- six published 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`
- the field registry, transport bindings, trust channels, error registry, and conformance levels
- public pages for API Reference, Adoption Kit, and Conformance Pack
- the expanded public implementation-evidence checklist in the Adoption Kit, Conformance Pack, and discovery surface, including implementation identity, profile scope, validator evidence, machine-route/cache posture, trust and threat boundary, locale/accessibility reader QA, fixtures, release trail, and support boundary
- the public conformance fixture pack in the Adoption Kit, Conformance Pack, discovery surface, and production response-surface checks
- the public bridge evidence pack in the Adoption Kit, Conformance Pack, and discovery surface, with validator-backed A2A Agent Card, A2A task, MCP tool-call, MCP resource-result, OpenAPI operation, DID/VC, and Trace Context mapping examples
- public Roadmap page and machine-readable roadmap route
- public Contact and Review page for launch-stage contact, contributor packet, change-proposal, decision-trail, and review-intake guidance
- public Related Links page for footer-linked outgoing references to adjacent standards, protocol projects, security references, implementation ecosystems, and research resources, with explicit non-endorsement and non-normative boundaries
- public Standards Fit page for A2A, MCP, OpenAPI, JSON Schema, DID/VC, Trace Context, compact-transfer, normalization boundaries, the UAI-1 vs MCP chooser, the UAI-1 vs A2A chooser, and bridge-evidence reading guidance
- public Guides, `/en-us/guides/agentic-harnesses-uai/`, and Standards Fit agentic-system evidence path that explains the runtime/harness versus UAIX split: runtimes execute, MCP connects tools, A2A coordinates agents, observability traces behavior, and UAIX preserves the validator-ready record, conformance packet, AI Memory, and project-memory handoff
- public AI Memory page, `/AI_Memory` redirect alias, supported starter bundle taxonomy generated from canonical templates and visible samples, AI Memory Package Wizard for guided package model JSON, manifest overlay JSON, generated system profiles with source-authority, evidence-ledger, conflict-resolution, risk, and rollback protocols, generated receiver briefs, generated startup packets, copy-paste file decks, optional generated LLM Wiki memory-plan files with steward/source/evidence metadata and readiness checks, and canonical starter ZIP links, Project Handoff page, root `readme.human` briefing convention, Agent File Handoff page, AGENTS.md `.uai` Linking Specification page, Reports index, and Refining UAI Protocol for Agent Communication report as the current public project-context memory, handoff, and dropped-file intake path
- `.uai/test-plan.uai` as the current handoff file for targeted-check policy, package-build triggers, and full-suite release gates
- public Launch Readiness page for the go-live gate across response checks, package evidence, accessibility QA, locale QA, release-trail alignment, and support-claim boundaries
- machine-facing routes for catalog, discovery, schemas, registry, field registry, transport bindings, trust channels, error registry, conformance levels, examples, validation, adoption kit, mock exchange, OpenAPI, conformance pack, roadmap, and status
- machine-route search/cache posture: public UAI REST JSON responses are non-indexable execution surfaces, readable machine routes have explicit short public cache headers, and public POST routes use no-store responses with launch-stage body-size and request-throttle guardrails
- validator normalization for `keyed-json`, `minified-keyed-json`, and `keyless-json`, including field-registry expansion and canonical-hash metadata in the validation result
- reusable positive keyed/minified-keyed/keyless fixture cases, canonical-hash equivalence metadata, and negative missing-profile, missing-required-field, undeclared-field, invalid-traceparent, DID/VC trust-evidence, keyless-shape, keyless-overflow, and unsupported-alias boundary cases in the conformance fixture pack
- keyed `message` and registry-backed `keyless_message` payloads on published example records
- dedicated governance child pages for policy and security, privacy and data, accessibility, analytics, launch readiness, and changelog
- root `robots.txt`, `sitemap.xml`, `sitemap.html`, `/.well-known/uaix.json`, and `/.well-known/uai.json`
- enabled `en-US` and `zh-CN` public language coverage for the current launch surface, with other locale inventory entries disabled until their full content and audits are ready
- homepage standards keywords metadata through the SEO sweep metadata surface
- launch-stage response headers on public WordPress-rendered HTML, HTML sitemap, and REST responses: `X-Content-Type-Options`, `Referrer-Policy`, `Permissions-Policy`, `X-Frame-Options`, `Content-Security-Policy: frame-ancestors 'self'`, and `Strict-Transport-Security` on HTTPS requests
- scripted WordPress package publishing, ZIP validation, fallback production root-asset generation, launch-surface audit with machine-route and response-header checks, zh-CN translation audit, and Studio smoke testing
- the old route-fix work for `Get Started` and `UAI-1`; those routes are no longer treated as broken-news-archive issues

## Roadmap Principles

- Trust infrastructure comes before growth infrastructure.
- Current support claims must stay narrower than the long-term ambition.
- Public pages, machine-readable records, validator evidence, package outputs, and changelog entries should move together.
- Research and strategy reports are source leads until their conclusions are promoted into current docs, public pages, machine artifacts, tests, changelog entries, roadmap state, or handoff records. Keep claim-evidence splits explicit before treating a report as authority.
- Ordinary project work should run targeted checks tied to the changed files, routes, or records; full package/release sweeps belong to ZIP builds, release candidates, broad launch-surface changes, or explicit full-check requests.
- Full build/release work should clean and update internal `.md`, `.uai`, and `.human` source files before package output is treated as current, while keeping those source files out of upload ZIPs and public discovery unless intentionally converted into public copy.
- Chat-start local file intake can refresh `.uai/intake-index.uai` from files dropped directly into `agent-file-handoff/Content/` and `agent-file-handoff/Improvement/`, and any `needs-agent-review` file must be inspected, summarized, and dispositioned before unrelated broad work. Processed files move to `agent-file-handoff/Archive/`, which routine AI intake ignores unless a human explicitly names an archived file or moves it back into an active bucket. AIWikis or another LLM Wiki implementation may consolidate already-dispositioned archive files only by explicit request, with transfer evidence and history/log/index updates before source archive removal. Intake does not publish public content or support claims without review. Watchers, daemons, queue folders, routine pickup manifests, out-of-chat auto-pickup, and bucket-local README instructions are discouraged for the base pattern.
- UAIX.org remains the source of truth for UAI-1; external distribution surfaces such as Protocol5.com should link back instead of becoming competing authorities.
- A2A coordinates agents, MCP connects tools and resources, and UAI-1 records the portable exchange evidence.
- UAIX should stay focused on the portable evidence and handoff layer for agentic systems. Runtime harnesses own model execution, tool access, approvals, tracing, interruptions, orchestration, and managed memory; UAIX records the part that must travel, validate, and survive handoff.
- Bridge profiles should map adjacent-system records into UAI-1 evidence; they should not take over A2A tasks, MCP sessions, identity stacks, tracing stacks, or transport lifecycles.
- The field registry supports compact and keyless transport, while JCS over the fully reconstituted keyed JSON record should remain the integrity and signing baseline.
- Token-efficiency work must be measurable, reversible, validator-backed, and auditable rather than based on hidden or covert machine language.
- Future platform ideas such as gateways, dashboards, settlement, federation, and streaming should remain research tracks until they have public ownership and maintenance capacity.

## Today Focus Path

Use this path before the longer roadmap inventory when the goal is authority and usefulness right now.

1. New readers should start with `/en-us/specification/uai-1/` and `/en-us/specification/standards-fit/`, then use `/en-us/roadmap/` before repeating broad claims about runtime fit, bridge profiles, SDKs, CLIs, adapters, certification, endorsement, or sync.
2. Implementers should produce one useful proof run: choose one public profile, validate one packet, keep the result beside the Adoption Kit or Conformance Pack, and cite the changelog before treating the work as public support.
3. AI Memory work should stay focused on the current Package Wizard: generated local files, package model JSON, manifest overlay JSON, visitor-AI digest output, copy-paste decks, optional LLM Wiki plan output, and canonical starter ZIP links.
4. Agentic-system work should keep execution, tools, approvals, tracing, interruptions, orchestration, and managed memory with the chosen runtime while UAIX records portable UAI-1 evidence, Project Handoff memory, support boundaries, and release records that survive the run.
5. Future tooling language should remain planned or research-track unless the public page, matching machine artifact, reproducible evidence, implementation or package proof when needed, and dated release trail all agree.

## Roadmap Work Documentation Ledger

Use this ledger whenever roadmap work changes what readers or future agents should believe.

1. Document roadmap work where readers can verify it: keep `/en-us/roadmap/`, `/wp-json/uaix/v1/roadmap`, this file, focused tests, `AGENTS.md`, `readme.human`, and `.uai/progress.uai` aligned when roadmap truth changes.
2. Keep source leads bounded: active intake files, Reports, archived source material, and AIWikis cold memory can inform work, but they are not current UAIX truth until promoted into current docs, public pages, machine artifacts, tests, release notes, roadmap state, or handoff records.
3. Name missing proof before support language moves: if a claim lacks public page copy, machine artifact, reproducible fixture or check, implementation/package proof when needed, or a dated release trail, keep it next, planned, or research-track.
4. Make future-agent pickup deterministic: future agents should start with `AGENTS.md`, `readme.human`, loaded `.uai` files, refreshed active intake, this roadmap, and the roadmap REST payload before widening support claims.
5. Do not create competing instruction sources, recurring live-site dependencies, CI pickup, watchers, scheduled jobs, or background handoff automation for roadmap documentation.

## Current Roadmap Work Queue

Use this queue to keep the next work concrete without turning planned work into support claims.

1. Deploy current packages and root assets: apply the freshly generated 2026-05-02 publish artifacts, then verify production static-root headers, HSTS, discovery files, and well-known manifests against the launch host.
2. Prove AI Memory Package Wizard serializer parity: show that one set of selections produces equivalent generated files, copy-paste decks, overlay JSON, visitor-AI digest summaries, and canonical ZIP references.
3. Plan local validation and redaction lint: define review checks for AI Memory and Project Handoff files while keeping hosted import validation, repository writes, SDKs, CLIs, certification, and endorsement out of current support.
4. Design trace-to-handoff evidence fixtures: map selected runtime traces, tool calls, approvals, task status, and handoff summaries into UAI-1 records or Project Handoff files only after public examples, review gates, and redaction rules exist.
5. Evaluate reference adapters only after evidence exists: OpenAI, A2A, MCP, and runtime-harness adapter patterns should start as evidence exporters, not as UAIX-owned execution, orchestration, or official vendor-adapter support.

## Evidence Promotion Gates

A future idea becomes current UAIX support only after the proof path is public and reproducible.

1. The relevant public page carries the claim, the support boundary, and route links.
2. The matching machine artifact, schema, registry, roadmap, discovery record, package, or conformance packet exposes the same state.
3. Fixtures, validator expectations, package checks, or handoff lint make the behavior reproducible.
4. A named implementation track, package, conformance packet, or release artifact carries the proof when the claim depends on software behavior.
5. The changelog, news, roadmap state, or durable handoff record explains what changed and what remains unsupported.

## Support Claim Checklist

Use this checklist before repeating roadmap language as current support.

1. Current support: only use current-support wording when the public page, machine artifact, reproducible evidence, implementation or package proof when needed, and dated release trail agree. If any part is missing, keep the item planned or research-track.
2. AI Memory packages: current support is guided package planning, generated local artifacts, copy-paste decks, package JSON, manifest overlays, visitor-AI digest, generated system profiles, receiver briefs, startup packets, optional LLM Wiki plans, and starter ZIP links. Managed packages, hosted upload/import validation, automatic repository writes, automatic LLM Wiki sync, SDKs, CLIs, certification, and endorsement remain unsupported.
3. Adapters and runtimes: UAIX records portable UAI-1 evidence and Project Handoff memory around runtime systems. Official adapters, trace exporters, runtime ownership, SDKs, and CLIs remain future work until public fixtures, owners, and release evidence exist.
4. Conformance language: a passing validator result proves one reviewed packet. It is not certification, endorsement, compliance, or ecosystem-wide support without a separate published process and evidence model.

## Near-Term Priorities

### 1. Production Launch Hardening

- Validate production HTTPS, canonical host behavior, redirects, and forwarded-header handling.
- Verify production security-header parity across WordPress-rendered pages, REST routes, root discovery files, robots, sitemap, and favicon responses, including HSTS and host-level version-header suppression where appropriate.
- Confirm production root discovery assets serve raw, host-correct content.
- Use the processed SEO and technical-audit intake reports as launch-hardening input: validate raw `/.well-known/uaix.json`, `/.well-known/uai.json`, `/sitemap.xml`, and `/robots.txt` delivery; check that query-string aliases canonicalize or redirect to clean locale-prefixed routes; verify robots/canonical/hreflang/schema behavior; enforce machine-route noindex/cache posture; and review dense high-value pages for crawl and mobile usability.
- Use `/en-us/governance/launch-readiness/` as the public go-live gate for response checks, package evidence, accessibility QA, locale QA, release-trail alignment, and support-claim boundaries.
- Run the production response-surface check against the actual launch host after DNS, TLS, CDN, or edge changes.
- Submit and monitor the production sitemap after launch.
- Re-run the launch-surface audit, zh-CN translation audit, package validation, and package smoke test before each production release, not by default for every narrow content or handoff edit.

### 2. Accessibility And Content QA

- Run a manual keyboard and screen-reader pass across home, specification, tools, governance, launch readiness, news, search, and sitemap pages.
- Review editor-managed content for heading order, link clarity, and meaningful alt text.
- Re-check mobile readability for long JSON, route, and conformance examples.
- Keep accessibility, privacy, analytics, and security pages aligned with observable site behavior.

### 3. Public Operating Layer

- Keep `/en-us/about/contact-and-review/` aligned with References and Contributors, Governance, Changelog, and News as the current public contact and review path.
- Keep `/en-us/about/related-links/` useful as an external-context page while making clear that outgoing links are source leads, not UAIX endorsement, certification, implementation support, or canonical UAI-1 authority.
- Keep the contributor guidelines, change-proposal template, decision-rights notes, release-cadence notes, and review-intake checklist current as launch decisions change.
- Add a clear external issue, repository, mailbox, or review intake channel only when it is real, maintainable, and linked from the canonical site.
- Expand the visible maintainer or reviewer record only when roles are real and maintainable.
- Keep the public Roadmap page and `/wp-json/uaix/v1/roadmap` synchronized with this file and clearly label current, next, planned, experimental, and research-track work.

### 4. Standards-Fit And Token-Efficiency Explanation

- Keep `/en-us/specification/standards-fit/` aligned with UAI-1, Roadmap, Changelog, API Reference, and Conformance Pack as the current public standards-fit and compact-transfer boundary.
- Use the core comparison line consistently: A2A coordinates agents, MCP connects tools and resources, and UAI-1 records the portable exchange.
- Keep current bridge evidence examples current: A2A Agent Card and task evidence, MCP tool-call and resource evidence, OpenAPI operation references, DID/VC trust evidence, and Trace Context mapping. Treat formal bridge profiles as planned until they have broader fixtures, validator expectations, and release evidence.
- Keep the token-efficiency explainer current before implying binary or alias support: keyed JSON for public review, minified keyed JSON for simple transfer, keyless JSON through the public field registry and validator normalization, and later CBOR or MessagePack only when round-trip validation exists.
- Keep stating that keyless, alias, and future binary variants must normalize back to full keyed JSON before schema validation, hashing, signatures, or public conformance evidence; today only keyed, minified-keyed, and keyless JSON are validator-supported.
- Treat profile codebooks, alias maps, registry hashes, schema hashes, and reference-mode prompt prefixes as experimental until they are public, versioned, and validator-backed.
- Expand examples that compare keyed, minified, and keyless payloads without promoting unsupported symbolic alphabets or private dialects.

### 5. Conformance Program Maturity

- Keep validator output, examples, and release checks tied to the reusable positive and negative test pack.
- Keep expanding the reusable positive and negative test pack. The current conformance fixture pack covers keyed, minified-keyed, keyless, canonical-hash equivalence, missing-profile, missing required fields, undeclared fields, invalid `traceparent`, DID/VC credential evidence and DID principal boundaries, keyless-shape, keyless-overflow, and unsupported-alias boundary cases; alias behavior beyond the negative boundary and future binary-envelope forms still need public fixtures, route behavior, and validator expectations.
- Expose and regression-test the expanded keyed JSON, registry release, canonical hash, and keyless round-trip result from validator output.
- Add conformance fixtures for keyed-to-alias, raw duplicate-key detection before parser collapse, formal bridge-profile records beyond the current bridge evidence pack, and binary encode/decode parity once binary transport exists. Keep the current keyed-to-keyless, canonical-hash, bridge-evidence, missing-field, `traceparent`, and `did+vc` fixtures current as validator behavior changes.
- Add CI-oriented examples for storing `uai.conformance.result.v1` records with implementation releases.
- Keep the conformance pack downloadable and versioned with the public UAI-1 record.
- Keep the public implementation-evidence checklist current as launch review needs change. It currently covers implementation identity, supported profile scope, validator evidence, machine-route and cache posture, trust and threat boundaries, locale/accessibility reader QA, fixtures and round-trip proof, release trail, and explicit support boundaries.
- Keep the conformance fixture pack current as validator behavior changes, and make sure positive and negative cases travel with release evidence before support language widens.
- Avoid certification, badge, or compliance claims until the process, evidence, and maintenance model are public.

### 6. Developer Support

- Publish maintainable client helpers, a CLI, or SDKs only when ownership exists to keep them current.
- Keep AI Memory as the broad search-friendly entry point for durable AI project context, the AI Memory Package Wizard as the guided planning UI over supported starters, Project Handoff as the concrete transfer subtype, and LLM Wiki as the deeper knowledge-memory option for large internal documentation. Current starter ZIPs and wizard outputs are live page-sample/package-model/manifest-overlay/system-profile/receiver-brief/startup-packet/LLM-Wiki-plan downloads generated from canonical templates and wizard choices, not hosted upload/import validation, automatic repository writes, automatic wiki sync, SDK, CLI, certification, or endorsement.
- Use the 2026-05-02 strategy intake to keep developer support narrow and useful: prioritize canonical package serialization, local validation, redaction lint, trace-to-handoff exports, and reference adapters only as planned evidence work until fixtures, ownership, release notes, and maintenance capacity are public.
- Keep the public Guides, Standards Fit, Reports, Roadmap, and machine-readable roadmap synchronized around the agentic-system evidence story so readers can move from strategy report to current support boundary without guessing.
- Treat any managed AI Memory package platform as planned work: one canonical package registry and object model, serializer parity across copy-paste/ZIP/future managed records, review/provenance/stale-state governance, privacy/redaction gates, and source-boundary-preserving AIWikis archive sync must exist before public claims widen beyond current starter downloads and guided wizard outputs.
- Keep AGENTS.md-triggered Agent File Handoff intake dogfooded in UAIX and LlmWikis so dropped files are visible and immediately reviewed during handoff load, regardless of prompt wording. Keep the base pattern to a portable intake-folder scan and do not recommend watcher/daemon processes, queue folders, manifests, cron loops, or out-of-chat auto-pickup.
- Keep root `readme.human` dogfooded in UAIX and LlmWikis as the human-facing briefing from the AI perspective, and keep it subordinate to `AGENTS.md`, project constraints, system instructions, repo rules, and human requests.
- Keep the Project Handoff WordPress prototype package exporting root `readme.human` and intake scaffolding while clearly labeling it experimental/internal rather than official generator or validator support.
- Prioritize Python and TypeScript helpers if support capacity exists; evaluate Go and Rust only when there is clear maintainer ownership for high-throughput broker or gateway examples.
- Keep Protocol5.com-scoped .NET plugin and NuGet distribution tied to UAIX.org links for the canonical UAI-1 specification, schemas, registry, validator behavior, roadmap, and governance.
- Keep the API Reference, OpenAPI export, Roadmap, Adoption Kit, implementation-evidence checklist, bridge evidence pack, mock exchange, and Conformance Pack as the current machine-facing onboarding path until broader tooling is ready.
- Add implementation examples only when they can be validated against the current schemas and validator.
- Expand the Implementations page structure around current proof-backed tracks only: WordPress publication packages, the Protocol5-scoped .NET bridge/distribution boundary, Project Handoff or LLM Wiki evaluation consumers, and future source-control/CI integration as planned or research until public fixtures, validator behavior, release evidence, and ownership exist.

### 7. Runtime And Release Architecture

- Continue moving legacy UAIX plugins toward a shared preflight-first bootstrap model.
- Reduce global symbols through namespacing and clearer dependency metadata.
- Preserve installability and smoke testing as release gates for every packaged plugin and theme.
- Keep diagnostics strong enough that activation, routing, and manual-upload failures can be traced without guessing.

## Medium-Term Priorities

- Add broader implementation coverage beyond WordPress publication and `.NET` bridge only when proof, tests, and docs can ship together.
- Evaluate multi-user source-control, branch-protection, adversarial AI review, QA, and safety-analysis patterns as future implementation guidance, but keep them out of current support language until they have concrete public artifacts, review ownership, and release checks.
- Evaluate governed AI Memory package authoring as a future platform track only after registry/schema stability: package instances, review states, provenance records, stale-review warnings, contradiction flags, artifact versioning, restore drills, and reviewed AIWikis export sync should remain planned until they have implementation evidence and operations ownership.
- Evolve the current bridge evidence pack into formal bridge profiles only when the profile names, fixtures, validator expectations, release evidence, and ownership model are clear. Useful planned artifacts include `uaix-a2a-agent-card.v1`, `uaix-a2a-task.v1`, `uaix-mcp-tool-call.v1`, `uaix-mcp-resource.v1`, `uaix-openapi-operation.v1`, `uaix-did-vc-trust.v1`, and `uaix-trace-context.v1`.
- Add trace-context and trust-binding examples where they clarify existing UAI-1 fields, including `conversation.traceparent`, `provenance.trace_id`, public-web, private-api, mTLS, signed-envelope, and credentialed trust-channel examples.
- Evaluate an OWASP AI and LLM-threat-model crosswalk for UAI-1 message handling, including prompt-injection fixture boundaries, replay-window guidance, capability-scoped authorization, and signed-envelope examples. Keep this as planned security guidance until fixtures, route behavior, and policy copy are public.
- Add validator or example-surface metrics for byte count, character count, keyed/minified/keyless/alias/binary-envelope deltas, prompt-facing versus transport-facing savings, and round-trip stability before pursuing exact provider token counters.
- Add a neutral reference transcoder or CLI only after registry versioning, canonical hash fixtures, and validator normalization behavior are stable enough to maintain.
- Continue the processed UAIX content-strategy intake as source-backed search and adoption work. The initial "what is UAI-1", UAI-1 vs MCP, and UAI-1 vs A2A onboarding now lives on Get Started, UAI-1, and Standards Fit; vertical implementation examples should wait until the canonical discovery/canonicalization layer, public fixtures, and maintenance ownership are stable.
- Evaluate Python and TypeScript helper tracks, A2A/MCP wrapper examples, IDE linting, NIST/IETF crosswalks, and EU AI Act evidence-template ideas as planned developer-support work; do not describe them as current SDK, CLI, certification, validator, or compliance support until public artifacts and maintenance ownership exist.
- Evaluate agentic-harness evidence exports as planned work: runtime traces, tool calls, approvals, task status, handoff summaries, and release evidence can map into UAI-1 records or Project Handoff files only after public examples, review gates, redaction rules, and validator expectations exist.
- Publish implementation showcases or adopter signals only when there are real public adopters and permission to name them.
- Expand localization deliberately, with hreflang, sitemap, content, and translation QA revalidated for each added locale.
- Establish a more plural governance model through named reviewers, public review windows, and published disposition notes.

## Longer-Horizon Research Tracks

These ideas are useful background, but they are not current launch commitments:

- decentralized or DID-linked discovery
- webhook or streaming delivery surfaces
- richer trust and credential binding
- alias dictionaries and negotiated compact profile dictionaries
- static-prefix, prompt-cache, and reference-mode packaging for large stable UAIX context
- Protobuf, CBOR, BSON, or MessagePack media types and content negotiation, such as `application/vnd.uaix.uai+cbor` or `application/vnd.uaix.uai+msgpack`
- persistent context chaining, entry/exit context records, semantic capability discovery, QoS fields, availability-aware routing, and negotiation message types
- probabilistic payloads, confidence intervals, reward signals, and state-observation records for future research or reinforcement-learning environments
- AIWikis/LLMWikis deep-memory orchestration ideas such as MCP memory tools, active-memory controllers, rolling active-memory pumps, automated wiki or CLI writes, dynamic confidence and lifecycle scoring, supersession machines, semantic search tiers, and bidirectional sync; keep them as research or implementation-site work until public ownership, review gates, fixtures, and safety evidence exist
- agentic harness control-plane ideas such as runtime adapters, scheduler bridges, approval routers, trace exporters, redaction lint, and local/CI validation hooks; keep them as evidence and handoff experiments until public fixtures, ownership, and release evidence exist
- observability dashboards
- agentic settlement or escrow
- simulated conformance labs, certification marks, or formal accreditation
- liaison with external standards bodies
- consortium governance, immutable-ledger anchoring, and formal standards-body adoption campaigns

Move any of these into active roadmap work only after the owner, maintenance model, public artifact set, and release criteria are clear.

## Historical Inputs

The following documents informed this roadmap but are not the current roadmap:

- `docs/Launch Roadmap Addendum - 2026-04-22.md`
- `docs/UAIX Improvement Roadmap - 2026-04-22.md`
- `docs/UAIX Analysis and Improvement Plan - Gemini 2026-04-22.md`
- `docs/deep-research-UAIX-Executive-Summary-report-2024-22-04.md`
- `docs/UAIX Deep Research Report.md`
- `docs/Strategic Optimization of the Universal Artificial Intelligence Exchange.md`
- `docs/uaix_expanded_roadmap.md`
- `docs/UAIX_roadmap_and_interoperability_report.md`
- `agent-file-handoff/Archive/2026-04-27/Improvement/Roadmap for UAIX.org Content Strategy.md`
- `agent-file-handoff/Archive/2026-04-28/Improvement/UAix.org Concepts_ AI Integration Review.md`
- `agent-file-handoff/Archive/2026-04-28/Improvement/UAIX.org technical audit and improvement report.md`
- `agent-file-handoff/Archive/2026-04-28/Improvement/Improving UAix Concepts_ A Framework.md`
- `agent-file-handoff/Archive/2026-04-29/Improvement/Expanding UAIX Implementations Page Structure.md`
- `agent-file-handoff/Archive/2026-04-29/Improvement/AIWikis.org_ UAIX Memory Plan.md`
- `agent-file-handoff/Archive/2026-04-29/Improvement/UAI AI Memory Package Wizard and the UAIX AIWikis System Design.md`
- `agent-file-handoff/Archive/2026-05-02/Improvement/UAIX Homepage and AI Memory Wizard UX Research Report.md`
- `agent-file-handoff/Archive/2026-05-02/Improvement/UAIX Six-Month Strategy Report.md`
- `agent-file-handoff/Archive/2026-05-02/Improvement/UAIX Strategy and Market Report on Agentic Harnesses.md`
- `agent-file-handoff/Archive/2026-05-02/Improvement/Future Strategy and Product Pivot Opportunities for uaix.org.md` was reviewed and blocked as out of scope because it audited an unrelated AUiX/Air University property.
- `agent-file-handoff/Archive/2026-05-02/Improvement/round-2/UAIX Strategy and Market Report on Agentic Harnesses.md`
- `agent-file-handoff/Archive/2026-05-02/Improvement/round-2/Deep Research Blueprint for an Unspecified Topic.md`

## Roadmap Metrics

Track these as evidence of roadmap progress:

- validated fixture count by profile
- positive and negative conformance fixture count
- public conformance packet count
- validator normalization-mode coverage
- canonical hash and round-trip fixture count
- traceparent and DID/VC trust-boundary fixture count
- required-field, undeclared-field, and keyless-overflow regression count
- bridge evidence example count and future formal bridge-profile fixture count by adjacent system
- implementation-evidence checklist completion by release
- agentic-system evidence coverage for runtime-to-UAI record exports, trace-to-handoff experiments, redaction lint, and canonical package serialization once those artifacts exist
- implementation-track count and supported profile coverage
- validator clarity: actionable issue codes, severities, and fix guidance
- round-trip stability for keyed to keyless to keyed examples
- keyed, minified, keyless, alias, and binary-envelope byte-count deltas
- response-header parity across public HTML, REST, and static root discovery assets
- independently passing implementation count once public intake exists
- changelog completeness for compatibility-affecting changes
- contributor or review-intake throughput once an external public intake channel exists

Why This File Exists

This is a memory-system evidence file from aiwikis.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; Status; How To Use This Document; No Longer Roadmap Items; Roadmap Principles; Today Focus Path; Roadmap Work Documentation Ledger; Current Roadmap Work Queue. 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

Provenance And History

  • Current observation: 2026-05-03T02:48:13.1276041Z
  • Source origin: current-source-workspace
  • Retrieval method: local-source-workspace
  • Duplicate group: sfg-433 (primary)
  • Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "UAIX Roadmap",
    "source_site":  "aiwikis.org",
    "source_url":  "https://aiwikis.org/",
    "canonical_url":  "https://aiwikis.org/files/aiwikis/raw-system-archives-uaix-recent-work-sweep-2026-05-03-docs-roadmap-md-e656937b/",
    "source_reference":  "raw/system-archives/uaix/recent-work-sweep/2026-05-03/docs/roadmap.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:e656937b9413a1f35f07a926f3f3292accb3bfa935296e83ec11018cd072c010",
    "last_fetched":  "2026-05-03T02:48:13.1276041Z",
    "last_changed":  "2026-05-02T19:39:17.7057324Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-433",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-05-03T02:48:13.1276041Z"
}