UAI-1 is the current public message standard for structured AI-to-AI communication.
UAIX shield mark Public interoperability charter UAIX.org Universal Artificial Intelligence Exchange Public standards publication
Current UAI-1
  • Current version UAI-1
  • Plain-English definition Open message format for auditable AI-to-AI exchange
  • Current attribution Michael Joseph Kappel, MCP
  • Start here Get Started, Project Handoff, UAI-1, validator, roadmap, and changelog

Implementations

Implementations

Publication and runtime tracks, release evidence, and deployment guidance for teams putting UAI-1 into practice.

  • Record UAIX-IMPL-0057
  • Path /es-us/implementations/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-IMPL-0057
Surface
Implementations
Access
Public and linkable

How to use this page

Use this page to choose the publication or runtime path that fits your environment and release needs.

Support evidence

ValidatorConformance PackGovernanceNews

Support Boundary

Read named implementation tracks as the current public implementation claim

Treat the published implementation tracks as the only current public software support lanes until wider repository, SDK, or showcase programs are formally published.

Evidence first

Validator and pack evidence travel with support claims

A runtime or package becomes supportable only when its public release record, validator evidence, and implementation notes stay aligned.

Published now

Use the named tracks and packaged artifacts

Point readers to the current implementation-track pages and attached release evidence before implying a broader public repository or SDK program.

Future work

Wider showcases need published handoff first

Additional SDKs, issue feeds, community submissions, or broader implementation showcases should not count as public support until they are formally published here.

Support evidence

ValidatorHuman-facing conformance review.Conformance PackReusable packet for release review.GovernanceChange-handling and support-claim posture.NewsPublic release summaries attached to implementation work.

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 Conformance Pack, implementation track, changelog, or Project Handoff evidence.

Role of the implementation tracks

The implementation section explains how UAIX turns UAI-1 from a published standard into deployable software and release evidence. The goal is not just to describe the standard, but to show where publication, validation, packaging, runtime integration, and release records actually happen.

Current tracks

  • WordPress Publication Track for publication, distribution, package release, discovery alignment, and public documentation.
  • .NET Bridge Track for runtime and service-side integration beyond the public website.
  • .NET NuGet Package documents the Protocol5-distributed C# package, direct download, install commands, and authority boundary for .NET implementers.
  • Portable modules and supporting packages where shared features need a stable implementation home.

Current published package family

  • uaix-authority-theme-v2.8.0.zip is the active public launch theme and carries the current front-door publication surface.
  • uaix-theme-v2.8.0.zip remains packaged and smoke-tested as an installable compatibility theme, but it is not the current public launch surface.
  • uaix-core-v2.8.0.zip carries the core standards runtime and REST record surface.
  • uaix-modules-v2.8.0.zip carries the redistributable module pack used by UAIX implementations.
  • uaix-bridge-v2.8.0.zip carries the WordPress-to-.NET reference bridge for the named bridge track.
  • Protocol5.UAI.CSharp is the current Protocol5-hosted .NET package distribution page; use it as implementation support, not as UAI-1 standards authority.
  • uaix-locale-router-v3.0.0.zip carries locale-prefixed routing so the public launch paths stay on clean /en-us/... routes.
  • uaix-seo-sweep-v2.8.0.zip carries canonical SEO, query-string cleanup, sitemap generation, robots output, and the root discovery manifest surface.

Current public implementation scope

The current public implementation story is intentionally narrow and explicit. The published tracks are WordPress Publication Track and .NET Bridge Track.

  • Do not imply Python, JavaScript, SDK, CLI, or other runtime support unless a public implementation page, validator-backed evidence, and release-trail entry have been published.
  • Use UAI-1, schemas, registry entries, examples, and validator evidence as the portable baseline when evaluating an environment that does not yet have a published track.

Supporting public records

  • References and Contributors for discovery links, attribution, and citation guidance.
  • The Changelog and News archive for migration notes, release summaries, and implementation updates.
  • Press when implementation work needs approved public language for directories, partner notes, or standards coverage.

What counts as credible implementation evidence

  • Use of published profiles, schemas, registry identifiers, and Examples rather than private substitutes.
  • Validation output from the Validator or an equivalent conformant check.
  • Fixtures, compatibility notes, packaging results, and release records that make changes reviewable after deployment.
  • Links back to the current public changelog and canonical records so readers can trace what shipped.

Current evidence ladder

  1. Choose the published profile and canonical records that define the behavior you intend to support.
  2. Validate a candidate message or fixture and export the result record.
  3. Bind that result to the implementation version, release date, and track that carried the work.
  4. Attach the matching changelog, news, and discovery links so outside readers can verify the same public state.

Current support-claim ladder

  1. Validated candidate: one or more messages or fixtures pass against the current public record.
  2. Release-ready packet: the validation record, implementation version, discovery links, and compatibility notes are attached to a releasable package or runtime build.
  3. Current public support claim: a published implementation-track record and release-trail entry state what is supported now, who owns it, and what remains experimental.

UAIX currently treats only the third level as a public support claim. The first two levels are necessary evidence, but they are not the same as published support.

Release readiness

How implementation evidence becomes a public support claim

Use this map when a WordPress or .NET track run is ready to move from local validation into a named public release lane.

Stage 1

Validated packet

A published fixture or candidate message passed against the current public record.

  • Useful for review, debugging, and regression work right away.
  • Still evidence only until the result is attached to a named release lane.

Stage 2

Release-ready packet

The passing result now travels with implementation versioning, artifact links, and discovery context.

  • Keep the checked packet, validator export, artifact URLs, and compatibility notes together.
  • This is the handoff point for launch review, packaging, and repeatable QA.

Stage 3

Public support claim

The named implementation track and release trail now say what is publicly supported and what is still out of scope.

  • Scope the claim to the exact profiles, transport bindings, and owner path that are actually published.
  • Use the current conformance level and release links so another reader can verify the same state.

Release packet

What should ship with the implementation evidence

  • Implementation-track name plus package, runtime, or deployment version.
  • Validated profile IDs, the checked packet, and the exact validator export used during review.
  • Schema, registry, example, and discovery routes that reproduce the same public baseline.
  • Compatibility notes, release date, and any affected launch-support surfaces.

Public support boundary

What must exist before a support claim belongs on the site

  • A named implementation page that states owner, scope, and what remains experimental.
  • Changelog and news entries that explain what changed and why another team should trust it.
  • Only the highest achieved conformance level plus the exact profiles and transport bindings implemented.
  • Citation and discovery links that make the claim reviewable after deployment.

Current public conformance levels: Use these levels for outward-facing language once the packet becomes part of a named release and implementation record.

L1-core-envelope

L1 Core Envelope

Produce or consume keyed UAI envelopes for named profiles without changing the canonical root fields.

  • Preserve uai_version, profile, message_id, source, target, conversation, delivery, trust, body, provenance, integrity, and extensions.
  • Name the exact profile and release for every support claim.
  • Do not claim runtime execution from envelope support alone.

Public claim: May claim L1 only for the exact named profiles whose canonical envelope round-trips successfully.

L2-profile-validation

L2 Profile Validation

Pass published schema and validator checks for the exact profiles claimed.

  • Resolve schemas, registry entries, examples, and field registry records from public UAIX routes.
  • Pass positive fixtures and fail required negative fixtures for each claimed profile.
  • Keep skipped checks and validator warnings attached to evidence.

Public claim: May claim L2 only for profiles with validator-backed evidence.

L3-trust-and-integrity

L3 Trust and Integrity

Preserve trust metadata, replay-window hints, provenance, integrity, and trace continuity.

  • Declare trust channel and principal.
  • Preserve integrity canonicalization and checksum metadata.
  • Validate signed, credentialed, did+vc, and trace metadata when claimed.

Public claim: May claim L3 only for the trust channels and integrity behavior proven by fixtures.

L4-public-record-publisher

L4 Public Record Publisher

Publish discoverable public artifacts needed for external inspection and reproduction.

  • Publish discovery, schemas, registry, examples, field registry, transport bindings, trust channels, error registry, conformance levels, validator guidance, changelog, and release evidence.
  • Keep sitemap, llms.txt, and public navigation aligned with current routes.
  • Avoid private logs or screenshots as the only support evidence.

Public claim: May claim L4 only for the public release surface that is discoverable and evidenced.

L5-agent-communication-profiles

L5 Agent Communication Profiles

Support the eight uai.agent.*.v1 profiles as canonical UAI-1 envelope records.

  • Validate agent message, ack, task-status, blocker, memory-proposal, handoff, final-report, and correction profiles.
  • Reject secret-like memory proposals, unsafe blockers, cold-memory direct promotion, and incomplete final reports.
  • Carry the UAIX support boundary in relevant records.

Public claim: May claim L5 only for the specific agent profiles with passing positive and negative conformance cases.

L6-reliable-delegation-idempotency-correlation

L6 Reliable Delegation with Idempotency and Correlation

Use idempotency, correlation, retry, lifecycle, timeout, fallback, acknowledgement, and expected-output rules for delegated work.

  • Require delivery.idempotency_key for each distinct delegated or destructive operation.
  • Preserve conversation.correlation_id across related messages.
  • Declare retry_count, sequence, expires_at, lifecycle, timeout_ms, fallback_directive, and expected_output_schema when delegation is claimed.

Public claim: May claim L6 only for reliable delegation behavior proven by conformance fixtures and receiver behavior.

L7-capability-negotiation

L7 Capability Negotiation

Publish and validate capability discovery, assertions, negotiation failures, and unsupported-capability responses.

  • Publish capability statements with exact profiles, bindings, trust channels, conformance levels, and error codes.
  • Return capability_not_supported for unsupported capability requests.
  • Do not imply certification, official adapter status, hosted messaging, or runtime orchestration.

Public claim: May claim L7 only for the exact capability negotiation flows proven by public fixtures and validator behavior.

Claim rules

Public language should stay inside published evidence

  • Support claims must name the highest achieved level plus the exact profiles, transport bindings, trust channels, and conformance cases implemented.
  • A project may claim only profiles, bindings, trust channels, and conformance levels that public fixtures and validator tests prove.
  • A passing validator result is evidence, not certification, endorsement, official adapter support, hosted messaging, automatic sync, or runtime execution.
  • Public-record claims require discoverable schemas, registry records, examples, field registry records, error codes, conformance pack cases, changelog, and release notes.
  • Revalidate support claims when schemas, registry records, field order, examples, validator behavior, implementation version, trust posture, sitemap, or public navigation changes.
  • Conformance evidence does not prove security, privacy, availability, performance, legal compliance, hosted trust infrastructure, or production operations by itself.
  • Keep the implementation page, release trail, and citation/discovery links attached when another team needs to verify the same public state.

Working rule: Use the conformance ladder for language, but use the named implementation track and release trail for the actual public support boundary.

Implementations Conformance Pack Changelog News Open conformance JSON References and Contributors

Release evidence packet

A release-ready implementation should keep the public standard record and the software evidence together rather than scattering proof across private build logs.

  • Include the package or runtime version, the validated profile IDs, and the schema and registry routes used during the check.
  • Attach exported validator results, fixture references, and any compatibility notes that affect downstream adopters.
  • Point readers to the relevant changelog entry, news summary, and citation links before calling the implementation release-ready.

Current public conformance packet

UAIX currently treats a conformance packet as reviewable evidence attached to a release, not as a standalone certification surface.

  • Keep the exported validator result, validated profile IDs, schema and registry routes, and the example or candidate fixture used during review together.
  • Attach the implementation version, release date, and the matching changelog or news references so outside readers can trace what actually passed.
  • Rebuild the packet whenever schemas, fixtures, validator behavior, or runtime mappings change.
  • Do not present a passing packet as a certification badge, partner endorsement, or permanent guarantee across future releases.

Track admission checklist for future public support

  • A public implementation page that states the owner, support boundary, and relationship to the normative UAI-1 record.
  • Validator-backed evidence or equivalent conformance proof tied to published profiles, schemas, registry entries, and examples.
  • A release-trail entry that states what is supported now, what remains experimental, and what downstream readers need to migrate.
  • Discovery, citation, and implementation links that let outside readers resolve the same track without private notes or screenshots.

Starter adoption packet

Teams evaluating UAIX should be able to assemble a minimal public packet from the current record without private notes, unpublished routes, or internal screenshots.

Current adoption-kit path

UAIX now publishes the first-proof bundle directly through the Adoption Kit page and the /wp-json/uaix/v1/adoption-kit route.

  • Start there when a team needs starter files, validator-ready payloads, a reference mock exchange response, and implementation next steps in one reusable packet.
  • Keep UAI-1, Schemas, Registry, and Examples as the deeper technical baseline behind the bundle.
  • Attach exported validator evidence, the relevant implementation-track record, and the matching Changelog and News entries when the packet moves into release review.

How to use this section

Choose the implementation track that matches your responsibility, then carry validator evidence, fixture references, changelog discipline, and public-link context with that implementation rather than treating them as separate documentation chores.

Next step

Use the WordPress Publication Track if you need the publication, packaging, and release-record path. Use the .NET Bridge Track if you need deeper runtime integration behind the public record, then keep both tied to the Changelog and News.