We build compact AI messaging tools.
JustAnIota official shield mark JustAnIota UAI tooling ɩ.com Compact AI messaging tools Language-neutral AI messaging: registries, schemas, validation.
Draft IOTA-1 tools
  • Current surface JustAnIota tooling draft
  • Plain-English definition Compact, structured AI messaging tools
  • Current attribution Michael Joseph Kappel, MCP
  • Short-domain status ɩ.com redirects to JustAnIota.com

Roadmap

Roadmap

Current and planned work for JustAnIota tools, registry depth, validator evidence, implementation docs, and launch readiness.

  • Record JAI-DOC-0034
  • Path /en-us/roadmap/
  • Use Canonical public record

Document status

Public standards page Published on JustAnIota.com as part of the current public standards record
Code
JAI-DOC-0034
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-1ValidatorRoute InventoryEvidence Pack Notes

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, managed AI Memory packages, and developer tooling need fixtures and validator-backed evidence before support claims widen.

Proof path

UAI-1Current normative contract.ValidatorEvidence before public support claims.Route InventoryRoute handbook and OpenAPI export.Evidence Pack NotesReusable launch-review packet.ChangelogDated migration and support posture.

Proof path

Validator-backed proof path

Keep the public reading order tied to one evidence trail: profile, schema, example, validator result, and release record.

  1. 1Pick a message profile.Start with a published UAI-1 profile and the record family that matches the exchange you need to prove.
  2. 2Compare it with schemas and examples.Resolve the schema, registry entry, and one fixture before writing or mapping your candidate packet.
  3. 3Run validator evidence.Validate keyed, minified-keyed, or keyless JSON against the current public UAI-1 records.
  4. 4Attach the result to implementation or handoff records.Carry the exported result into implementation notes, changelog entries, or Project Handoff evidence.
Roadmap JSONMachine-readable future-work boundary
curl -s https://justaniota.com/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 handoffAI Memory, the AI Memory Package Wizard, Project Handoff, dynamic starter ZIPs generated from canonical templates and visible samples, readme.human, Agent File Handoff, AGENTS.md .uai linking guidance, Route Inventory, Starter Evidence Notes, OpenAPI, implementation evidence checklist, bridge evidence pack, and Evidence Pack Notes are the current developer handoff bundle.Managed package records, reusable .uai generators, hosted upload or import validation, automatic repository writes, SDKs, CLI tools, public repositories, certification, endorsement, and broader runtime catalogs need fixtures, ownership, and maintenance before launch copy can claim them.
Governed AI Memory packagesThe AI Memory Package Wizard currently provides a six-step package-planning flow with page-level validation, local browser draft restore, package model JSON, manifest overlay JSON, generated system profiles with source-authority, evidence-ledger, conflict, risk, and rollback protocols, generated receiver briefs, generated startup packets, copy-paste file decks, optional LLM Wiki memory-plan files, readiness metadata, and canonical starter ZIP links from the supported bundle registry.Future managed authoring needs one package object model, serializer parity, review states, provenance records, privacy gates, stale-review checks, and reviewed AIWikis archive sync before it becomes current support.

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.

Plain English

The roadmap keeps IOTA-1 authority records ahead of implementation experiments.

Technical summary

Near-term work is authority-page alignment, phrase-aware tool evidence, registry examples, validator behavior, implementation docs, and launch QA.

Deep spec

Planned work becomes current support only when pages, code, fixture evidence, validation behavior, and release notes agree.

Build order

  • Homepage and About authority positioning.
  • IOTA-1 (ɩ≃1) profile and UAI-1 boundary records.
  • Tools: JustAnIota Converter, Concept Bridge, HTML Keyless Extractor, Validator, and segment evidence surfaces.
  • Implementation and developer docs that route Protocol5 evidence back to JustAnIota authority pages.
  • Governance, trust, launch readiness, and press.

Strategic roadmap

  • Short term: make the positioning page, About, IOTA-1 profile, tools, implementation docs, discovery metadata, and press language agree.
  • Near term: publish OpenAPI-style route notes, fixture examples, validator issue examples, and protocol-boundary guidance before claiming broad developer integration.
  • Mid term: add reviewed package import/export, richer registry snapshots, and Protocol5 evidence summaries as documentation or read-only displays.
  • Future: consider SDKs, CLIs, hosted APIs, open-core services, partnerships, and formal governance only after public code, ownership, support, and release evidence exist.