Roadmap

curl -s https://uaix.org/wp-json/uaix/v1/roadmap

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.

Today focus path#

This is the practical reading order for today. The shortest path from question to evidence is to orient on the current authority surface, make one useful proof or package move, then leave future tooling language behind the evidence gates until it has public proof.

1. For a new reader: start with UAI-1 and Standards Fit, then use this roadmap before repeating claims about MCP, A2A, runtime harnesses, bridge profiles, SDKs, CLIs, adapters, certification, or sync.
2. For an implementer: build one reviewable packet with the Validator, keep the Adoption Kit or Conformance Pack beside the result, and cite the Changelog before treating the work as public support.
3. For AI Memory work: use the AI Memory Package Wizard to produce generated local files, package model JSON, manifest overlay JSON, a visitor-AI digest, and canonical starter ZIP links; keep managed package records, hosted imports, automatic writes, automatic sync, SDKs, CLIs, certification, and endorsement future-bound.
4. For agentic systems: keep runtime execution, tools, approvals, tracing, interruptions, orchestration, and managed memory with the chosen runtime; use UAIX for portable evidence, Project Handoff memory, and release records that survive the run.

Roadmap work documentation ledger#

Use this ledger to see where roadmap work is recorded, what counts as evidence, and how future agents should continue the work without widening current-support language.

1. What changed today: public roadmap work should be visible on this page, in /wp-json/uaix/v1/roadmap, in docs/roadmap.md, in focused regression tests, and in compact handoff state such as AGENTS.md, readme.human, and .uai/progress.uai.
2. Where proof lives: support-changing work needs a public page, a matching machine artifact, reproducible fixture, validator, package, or handoff check, and a dated trail through Changelog or release notes. Use Launch Readiness when the claim affects the launch surface.
3. What remains planned: missing proof should be named directly and left as next, planned, or research-track work. Adapters, trace exporters, hosted imports, automatic repository writes, automatic sync, SDKs, CLIs, certification, and endorsement stay future-bound until the evidence gates are public.
4. How future agents pick up: start from Project Handoff, refresh Agent File Handoff intake, load the local AGENTS.md, readme.human, and typed .uai files, then update the roadmap, REST payload, tests, and handoff record together when project truth changes.

Current roadmap work queue#

This queue turns the near-term strategy into visible work without widening support claims. Treat each item as current roadmap direction until the promotion gates below have public evidence.

1. Deploy current packages and root assets: apply the freshly generated publish artifacts, then verify production static-root headers, HSTS, discovery files, and well-known manifests against the launch host.
2. Prove wizard serializer parity: show that one set of AI Memory Package Wizard selections produces equivalent local 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 upload/import validation, automatic repository writes, SDKs, CLIs, certification, and endorsement out of current support.
4. Design trace-to-handoff fixtures: map selected runtime traces, tool calls, approvals, task status, and handoff summaries into UAI-1 records or Project Handoff files only after examples, review gates, and redaction rules exist.
5. Evaluate capability-package sidecars: study SKILL.md folders, plugin manifests, action groups, agent cards, MCP/OpenAPI capability surfaces, and subagent profiles as optional UAI evidence mappings, not authorization or current package-profile support.
6. Evaluate reference adapters: study OpenAI, A2A, MCP, and runtime-harness adapter patterns as evidence exporters, not as UAIX-owned execution, orchestration, or official vendor-adapter support.

Evidence promotion gates#

A future idea becomes current support only when it clears the same public proof path readers can inspect.

1. Update the public page that carries the claim and its support boundary.
2. Update the matching machine artifact, schema, registry, roadmap, discovery record, package, or conformance packet.
3. Add fixtures, validator expectations, package checks, or handoff lint that make the behavior reproducible.
4. Attach implementation-track, package, or conformance evidence when the claim depends on software behavior.
5. Record the change in the dated release trail and keep the non-claim boundary visible.

Support claim checklist#

Repeat only public-proofed claims: before repeating a roadmap phrase as current support, check the public page, matching machine artifact, reproducible evidence, implementation or package proof when the claim depends on software behavior, and dated release trail. If any part is missing, keep the claim planned or research-track.

• Current support: requires matching page copy, machine artifact, validator, fixture, package, implementation, or handoff evidence, plus a dated release trail.
• AI Memory package scope: current support is guided package planning, generated local artifacts, copy-paste decks, package JSON, manifest overlays, visitor-AI digest, system profiles, receiver briefs, startup packets, optional LLM Wiki plans, and starter ZIP links. Managed packages, hosted imports, automatic repository writes, automatic sync, SDKs, CLIs, certification, and endorsement remain unsupported.
• Adapters and runtimes: UAIX records portable evidence and project memory around runtime systems; official adapters, trace exporters, runtime ownership, SDKs, and CLIs remain future work until fixtures, ownership, and release evidence exist.
• Conformance language: a passing validator result proves the reviewed packet, not certification, endorsement, compliance, or ecosystem-wide support.

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.
• AI Memory, the AI Memory Package Wizard, Project Handoff, root readme.human guidance, the AGENTS.md .uai linking specification, Agent File Handoff, the Reports index, and the refining report are current public pages; hosted upload/import validation, automatic repository writes, managed package records, SDKs, CLI tools, certification, and endorsement 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, AI Memory, the AI Memory Package Wizard, Project Handoff, readme.human guidance, 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.

Governed AI Memory packages#

AI Memory, the AI Memory Package Wizard, Project Handoff, Agent File Handoff, and the report trail are current public onboarding surfaces. The wizard currently produces 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, readiness metadata, a visitor-AI digest from the same canonical payload, and canonical starter ZIP links from the supported bundle registry.

1. Current wizard layer: keep the six-step browser flow, local draft restore, generated file deck, review/export step, canonical ZIP links, and embedded AI digest aligned with the supported bundle registry.
2. Next serializer parity work: prove the same selections produce equivalent generated local files, copy-paste decks, overlay JSON, AI digest summaries, and ZIP references, then make stale-review or changed-selection warnings explicit before export.
3. Planned managed package records: define package-instance identifiers, review states, provenance records, privacy and redaction gates, artifact versioning, and owner responsibilities before managed AI Memory packages become current support.
4. Research-track adapter and sync ideas: evaluate OpenAI adapter, trace-to-handoff exporter, and reviewed AIWikis archive-memory sync patterns only as explicit reviewed exports, not automatic repository writes or bidirectional wiki sync.

Future managed AI Memory packages remain planned until package instances, review states, provenance records, privacy gates, stale-review checks, serializer parity, and reviewed AIWikis archive sync have public implementation evidence.

Agentic systems and harness boundary#

UAIX should stay focused on the evidence and handoff layer around agentic systems: the public exchange record, validator evidence, conformance packet, project-memory handoff, and release trail. Runtime harnesses still own model execution, tools, approvals, tracing, interruptions, and orchestration.

• Current support: UAI-1 records portable exchange evidence, while AI Memory and Project Handoff preserve repo-local project context that a runtime can load and update after review.
• Next work: keep reference adapters, trace-to-handoff exports, local validation, redaction lint, and canonical package serialization as roadmap items until public fixtures and ownership exist.
• Do not claim: UAIX is not an agent runtime, scheduler, tool bus, hosted memory platform, certification program, official vendor adapter set, SDK, or CLI today.

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, AI Memory Package Wizard serializer parity, 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, readme.human, and AGENTS.md-linked .uai files are draft repository-context guidance, not UAI-1 conformance evidence, certification, or endorsement by themselves.
• The AI Memory Package Wizard is a six-step guided package-planning UI over supported starter bundles with page-level validation, local draft restore, generated system profiles, generated receiver briefs, and generated startup packets; it is not hosted upload/import validation, automatic repository writing, automatic LLM Wiki sync, SDK, CLI, certification, endorsement, or WordPress admin package management.
• Capability-package sidecars and mapping annexes remain research-track evidence-mapping ideas, not a current package profile, registry, authorization layer, official adapter, SDK, CLI, certification, endorsement, or conformance claim.
• 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 work queue, evidence promotion gates, 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.