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

Get Started

Get Started

First-step onboarding for implementers evaluating UAIX, UAI, and UAI-1 as an open interoperability program.

  • Record UAIX-GUID-0044
  • Path /es-us/get-started/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-GUID-0044
Surface
Get Started
Access
Public and linkable

How to use this page

Use this page to move from orientation into the current UAI-1 reading, validation, and implementation path.

Launch kit

UAI-1API ReferenceAdoption KitValidator

Fastest Public Path

Zero context to first valid UAI-1 packet

Use the public launch kit in one pass: resolve the adoption kit, pick one profile, validate one packet, test the same packet against the live mock exchange, then carry the result into a named implementation track.

Read boundary

One profile, one contract

Start with UAI-1, then keep the matching schema and registry entry in view so the public contract stays concrete.

Run proof

Validator-backed first evidence

Use one example or candidate message, run the validator, and keep the exported result with the exact records you resolved.

Carry forward

Choose the release lane

Move into Implementations, then attach the release trail through the changelog, news, and contributor handoff pages.

Launch kit

UAI-1Current normative contract.API ReferenceRoute handbook and OpenAPI export.Adoption KitPublished first-proof bundle and starter files.ValidatorHuman-facing proof run and result export.Mock ExchangeLive reference response surface for one real reply shape.Conformance PackReusable release packet for launch review.

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.
Starter callsFirst machine checks
curl -s https://uaix.org/wp-json/uaix/v1/catalog
curl -s https://uaix.org/wp-json/uaix/v1/schemas/uai.intent.request.v1
curl -s https://uaix.org/wp-json/uaix/v1/adoption-kit
curl -s -X POST https://uaix.org/wp-json/uaix/v1/validate -H "Content-Type: application/json" -d @validate-request.json
curl -s -X POST https://uaix.org/wp-json/uaix/v1/mock-exchange -H "Content-Type: application/json" -d @mock-exchange-request.json

Resolve the catalog first, then one schema, then the adoption kit, then one validator run, then one live mock exchange. That is the shortest machine-facing path into the public record and back out through a real response envelope.

Who this is for

Use UAIX if you are implementing, evaluating, governing, or citing AI-system exchanges that need declared, reviewable structure. UAIX is the public standards and publication site, UAI is the standards family, and UAI-1 is the current normative release.

Reader paths by role

AI memory and handoff path

If you are onboarding a new AI, a new contractor, or a second team from repository files instead of from private chat history, start with AI Memory for the public framing and live starter bundle, then use Project Handoff when you need the engineering pattern for a root AGENTS.md file, a .uai/readme.human briefing, and local .uai/ bundle.

First 15 minutes

Use this quick path when you are trying to understand where UAIX fits in an agentic architecture: the harness runs the work, MCP and A2A can support runtime coordination, and UAIX preserves the reviewed evidence and project memory that should survive the run.

  1. Orient: start with UAI-1, Standards Fit, and Roadmap to separate the current public contract from planned bridge work.
  2. Build memory: use AI Memory, the AI Memory Package Wizard, and Project Handoff when the next human or agent needs durable startup context.
  3. Prove one exchange: choose one Example, run the Validator, and keep the result beside the Adoption Kit or Conformance Pack when the packet moves toward review.
  4. Plan agentic fit: use Agentic Harness Strategies And UAI to keep orchestration, tools, approvals, tracing, and live memory in the runtime while UAIX records the portable proof.
  5. Check the claim: one proof run is packet evidence, not certification, endorsement, official adapter support, SDK, CLI, automatic sync, or broad conformance.

What problem UAI-1 solves

UAI-1 gives implementers a stable public envelope for identity, profile declaration, intent, context, provenance, payload transfer, outputs, and errors. The goal is to make interoperable machine communication easier to validate, audit, and evolve than private runtime-by-runtime dialects.

How the public work is organized today

UAIX currently organizes its public work through record families and implementation tracks rather than through a separate events calendar, membership program, or broad community portal.

Quick evaluation checklist

  1. Confirm the current public record exists on stable canonical routes: UAI-1, Schemas, Registry, Examples, the Validator, Implementations, the Changelog, and References and Contributors.
  2. Decide whether you need a current published implementation track or only the portable baseline. Today the public tracks are the WordPress Publication Track and the .NET Bridge Track described under Implementations.
  3. Check whether the release trail is visible and current: use the Changelog and News to see how changes are dated, explained, and linked back to the affected records.
  4. Check whether contributor and citation handoff is sufficient for your use case: References and Contributors should let another reviewer resolve the same public records without private notes.
  5. Treat broader public contact channels, named multi-stakeholder governance roles, and additional runtime tracks as future work unless they are explicitly published on the site. Use Governance, Policy and Security, Privacy and Data, Accessibility, Analytics, and References and Contributors for the current published trust posture on the launch surface.

What to read first

  1. Start with UAI-1 to understand the current normative message model.
  2. Read Schemas and Registry together so field rules, profile identifiers, and compatibility handles stay aligned.
  3. Review Examples and run the Validator before treating an implementation as conformant.
  4. Use Implementations to choose the publication or runtime track that fits your environment.

Five-minute developer path

  1. Open UAI-1 and read the first boundary sections so you know what the current public contract covers.
  2. Pick one published Example and resolve its matching Schema and Registry entry.
  3. Run the same packet through the Validator so you have reviewable evidence instead of only a prose impression.
  4. Use Implementations only to decide what support is actually published today; do not infer a broader SDK or runtime catalog from the standard itself.

Adoption checklist

  1. Pick one UAI-1 profile and confirm why that profile matches the exchange you want to support.
  2. Build or map one candidate message with explicit version, profile, source, target, body, provenance, and integrity fields.
  3. Validate the message and save the result before wiring it into a release path.
  4. Decide which public track carries the work next: WordPress publication, .NET bridge integration, or another implementation path tied back to the public record.
  5. Record any compatibility assumptions in the changelog or release notes before downstream users depend on the behavior.

Capability-adaptive reading path

If the next reader might be a crawler, low-token fetcher, browser-assisted agent, tool-calling agent, workflow agent, multi-agent runtime, or audited system, read Capability-Adaptive Web Interaction before widening support claims.

What records you need next

Current public implementation scope

The public site currently documents two implementation lanes through Implementations: a WordPress publication path and a .NET bridge path.

  • Do not assume Python, JavaScript, SDK, CLI, or other runtime support unless a public implementation record has been published.
  • If you are evaluating another environment, treat UAI-1, schemas, registry entries, examples, and validator evidence as the portable baseline until a public track exists.

Current public developer kit

  • Published now: UAI-1, Schemas, Registry, Examples, Tools, Validator, discovery routes, validation routes, the WordPress Publication Track, and the .NET Bridge Track.
  • Not yet published: a public SDK, CLI, standalone source-repository link, general-purpose reference server, or broader runtime-support catalog.
  • Best reading today: treat the developer kit as the canonical pages, machine-readable routes, example fixtures, and validator exports until those additional surfaces are formally published.

How UAI-1 fits with MCP and A2A

  • UAI-1: the public envelope, trust, provenance, async-delivery, and release-evidence layer for an exchange.
  • MCP: local host-client-server tool sessions and capability negotiation inside an application boundary.
  • A2A: agent discovery, delegation, and task-flow coordination across cooperating systems.
  • Best fit: use UAI-1 above or beside MCP and A2A when another team needs a portable, citable record rather than only a runtime-local interaction. Use Standards Fit for the full UAI-1, MCP, and A2A chooser.

Protocol fit

When to use UAI-1 vs MCP, A2A, and OpenAPI

Use this decision table when you need to explain quickly why UAIX publishes UAI-1 beside MCP, A2A, and the live OpenAPI route surface.

Comparison point UAI-1 MCP A2A OpenAPI
Primary role Portable public exchange, trust declaration, async-delivery, and release-evidence record. Host-client-server tool sessions and capability negotiation inside an application boundary. Agent discovery, delegation, and task-flow coordination across cooperating systems. Route-level HTTP API description for onboarding, documentation, and client generation.
Best when Another team needs a citable message contract and validator-backed evidence. One host application needs local tool, resource, or model integration. Multiple agents need explicit handoff, delegation, and task-state coordination. You need a documented HTTP surface, including the UAIX machine-facing REST routes.
Carries on the record Identity, workflow continuity, trust posture, provenance, typed errors, and conformance evidence. Tools, resources, prompts, and runtime session capabilities within the host boundary. Agent capabilities, task lifecycles, delegation state, and inter-agent coordination. Endpoints, methods, parameters, request bodies, responses, and auth schemes for an API.
Does not try to replace Transport choice, local orchestration, a single credential stack, or the runtime tool bus itself. Portable public release records or validator-backed support claims outside the local session boundary. A general-purpose public message envelope or long-term release-evidence record. Message-level provenance, portable trust posture, or validator-driven interoperability evidence.

Typical combination: use MCP or A2A for runtime coordination, UAI-1 for the portable public record, and OpenAPI for the route-level HTTP description when an API is involved.

Read UAI-1 Open API reference page Open validator page

Architecture map

How the launch surface fits together from runtime to release

Use this visual path when onboarding new readers: start from the runtime layer, shape one UAI-1 packet, validate it against the published artifacts, then carry only the named release evidence forward.

Runtime layer

MCP, A2A, orchestrators, SDKs

These layers can handle local tool use, delegation, and execution flow without being treated as the public release record.

Portable public layer

UAI-1 envelope, trust, provenance, delivery

UAI-1 keeps the exchange citable, reviewable, and validator-ready when it has to travel beyond one runtime boundary.

Machine-readable artifacts

Schemas, registry, examples, validator

These records turn the written contract into machine checks, fixtures, route lookups, and exportable conformance evidence.

Release surface

Conformance pack, implementation tracks, release trail

Carry the validated packet into the named implementation lane and the public release trail instead of leaving support claims as local notes.

Companion records: transport bindings, trust channels, the error registry, and conformance levels stay beside the message contract so delivery, identity posture, typed failures, and support claims remain explicit.

  1. 1

    Start where the work already happens

    An agent runtime, tool session, or delegated task flow begins the exchange in its native environment.

  2. 2

    Shape one portable UAI-1 record

    Keep identity, target, workflow state, trust posture, and provenance explicit in the public envelope.

  3. 3

    Resolve the matching public artifacts

    Use the schema, registry entry, field order, examples, and operating-surface records that match the packet you want to publish.

  4. 4

    Run the validator and assemble evidence

    Export the conformance result and keep it with the exact artifacts and packet that were reviewed.

  5. 5

    Publish only the named support lane

    Use the implementation track, conformance pack, changelog, and release trail to describe current support without overclaiming the rest of the stack.

Read UAI-1 Open schemas page Open validator page Open conformance pack page Open implementations page

Launch-ready machine entry points

  • API Reference translates the live REST surface into a route-by-route handbook with OpenAPI export and starter requests.
  • Adoption Kit publishes the first-proof bundle with starter files, validator-ready payloads, and a reference mock-exchange packet.
  • Conformance Pack assembles the broader release artifacts into one reusable JSON packet for launch review and regression work.
  • /wp-json/uaix/v1/adoption-kit publishes the machine-readable onboarding bundle and supports a direct download form with ?download=1.
  • /wp-json/uaix/v1/openapi.json publishes the current OpenAPI 3.1 description of the machine-facing UAIX routes.
  • /wp-json/uaix/v1/conformance-pack publishes the current machine-readable conformance packet and supports a direct download form with ?download=1.

First machine calls

Code example
curl -s http://uaix.org/wp-json/uaix/v1/catalog
curl -s http://uaix.org/wp-json/uaix/v1/schemas/uai.intent.request.v1
curl -s http://uaix.org/wp-json/uaix/v1/adoption-kit
curl -s -X POST http://uaix.org/wp-json/uaix/v1/validate -H "Content-Type: application/json" -d @validate-request.json

Use the catalog first, then resolve one schema or example, pull the published onboarding bundle, and submit one validator run. That is the shortest machine-facing path from reading the standard to proving one packet against the public record.

Published first-proof run

Use the public runbook and starter calls below when the next goal is one validator-backed packet built entirely from the currently published surface.

First proof run

Get to one valid UAI-1 message in five minutes

Use this runbook when the next goal is one validator-backed packet built only from the currently published public surface.

Step 1

Resolve the live catalog

Pull the current route inventory first so the rest of the proof run stays anchored to the published machine surface.

Step 2

Fetch one starter example

Use one published request example as the first packet so your review starts from current public structure instead of local guesswork.

Step 3

Wrap the message for validation

Build one validator request body with the example packet nested under `message` and request the result record format.

Step 4

Run one validator check

Submit the validation request to the live POST route and keep the returned result record with the exact packet that was checked.

Step 5

Test the live reference response

Post the same validated packet to the mock exchange route when you want one real conforming response shape before a runtime track exists.

Step 6

Carry only the named next step

Move from proof into the named implementation lane, conformance pack, and release trail instead of claiming broader support than the site publishes.

Catalog /wp-json/uaix/v1/catalog Schema /wp-json/uaix/v1/schemas/uai.intent.request.v1 Example /wp-json/uaix/v1/examples/uai.intent.request.v1 Validate /wp-json/uaix/v1/validate Adoption kit /wp-json/uaix/v1/adoption-kit Mock exchange /wp-json/uaix/v1/mock-exchange
起步消息 Example packet JSON starter-message.json
Code example
{
    "uai_version": "1.0",
    "profile": "uai.intent.request.v1",
    "message_id": "msg-2026-04-22-0001",
    "source": {
        "type": "agent",
        "id": "agent.alpha",
        "label": "Agent Alpha",
        "uri": "https://agents.alpha.example/runtime",
        "did": "did:web:agents.alpha.example",
        "role": "requesting-agent",
        "implementation": "alpha-runtime-2.4.1"
    },
    "target": {
        "type": "service",
        "id": "uaix.gateway",
        "label": "UAIX Gateway",
        "uri": "https://uaix.org/wp-json/uaix/v1/discovery",
        "did": "did:web:uaix.org",
        "role": "public-record-gateway",
        "implementation": "uaix-core-0.4.0"
    },
    "conversation": {
        "conversation_id": "conv-2026-04-22-uaix-001",
        "turn_id": "turn-001",
        "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
        "sequence": 1
    },
    "delivery": {
        "mode": "async",
        "priority": "interactive",
        "expires_at": "2026-04-22T16:05:00Z",
        "reply_requested": true,
        "ack_required": true
    },
    "trust": {
        "channel": "credentialed",
        "auth_scheme": "did+vc",
        "principal": "did:web:agents.alpha.example",
        "credential_ref": "https://agents.alpha.example/credentials/uai-interop.json",
        "signature_ref": "https://agents.alpha.example/signatures/msg-2026-04-22-0001.jws",
        "replay_window_id": "rw-2026-04-22-0001"
    },
    "body": {
        "intent": "resolve-profile",
        "subject": "uai.task.status.v1",
        "requested_profile": "uai.task.status.v1",
        "parameters": {
            "include_schema": true,
            "include_example": true,
            "include_field_registry": true
        },
        "constraints": [
            "public-record-only",
            "trace-linked",
            "validator-ready"
        ],
        "response_profile": "uai.intent.response.v1"
    },
    "provenance": {
        "trace_id": "trace-7f3a2d",
        "parent_trace_id": "trace-root-uaix-2026",
        "issued_at": "2026-04-22T16:00:00Z",
        "log_ref": "urn:uaix:log:2026:0001",
        "agent_id": "agent.alpha",
        "model_id": "model.alpha.reasoner-2",
        "confidence": 0.98,
        "lineage": [
            {
                "stage": "request-composition",
                "actor_id": "agent.alpha",
                "model_id": "model.alpha.reasoner-2",
                "note": "Requested the async task-status profile and matching field registry."
            }
        ]
    },
    "integrity": {
        "version": 2,
        "algorithm": "sha256",
        "canonicalization": "jcs",
        "checksum": "sha256:dd8a9d16c9226cc9d1f4888a4d2bbcbf06b5b4b8"
    },
    "extensions": [
        {
            "namespace": "urn:uaix:ext:delivery",
            "purpose": "Explicit async request handling and expiry semantics.",
            "critical": false
        }
    ]
}
验证请求 Wrap the packet for validator POST validate-request.json
Code example
{
    "message": {
        "uai_version": "1.0",
        "profile": "uai.intent.request.v1",
        "message_id": "msg-2026-04-22-0001",
        "source": {
            "type": "agent",
            "id": "agent.alpha",
            "label": "Agent Alpha",
            "uri": "https://agents.alpha.example/runtime",
            "did": "did:web:agents.alpha.example",
            "role": "requesting-agent",
            "implementation": "alpha-runtime-2.4.1"
        },
        "target": {
            "type": "service",
            "id": "uaix.gateway",
            "label": "UAIX Gateway",
            "uri": "https://uaix.org/wp-json/uaix/v1/discovery",
            "did": "did:web:uaix.org",
            "role": "public-record-gateway",
            "implementation": "uaix-core-0.4.0"
        },
        "conversation": {
            "conversation_id": "conv-2026-04-22-uaix-001",
            "turn_id": "turn-001",
            "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
            "sequence": 1
        },
        "delivery": {
            "mode": "async",
            "priority": "interactive",
            "expires_at": "2026-04-22T16:05:00Z",
            "reply_requested": true,
            "ack_required": true
        },
        "trust": {
            "channel": "credentialed",
            "auth_scheme": "did+vc",
            "principal": "did:web:agents.alpha.example",
            "credential_ref": "https://agents.alpha.example/credentials/uai-interop.json",
            "signature_ref": "https://agents.alpha.example/signatures/msg-2026-04-22-0001.jws",
            "replay_window_id": "rw-2026-04-22-0001"
        },
        "body": {
            "intent": "resolve-profile",
            "subject": "uai.task.status.v1",
            "requested_profile": "uai.task.status.v1",
            "parameters": {
                "include_schema": true,
                "include_example": true,
                "include_field_registry": true
            },
            "constraints": [
                "public-record-only",
                "trace-linked",
                "validator-ready"
            ],
            "response_profile": "uai.intent.response.v1"
        },
        "provenance": {
            "trace_id": "trace-7f3a2d",
            "parent_trace_id": "trace-root-uaix-2026",
            "issued_at": "2026-04-22T16:00:00Z",
            "log_ref": "urn:uaix:log:2026:0001",
            "agent_id": "agent.alpha",
            "model_id": "model.alpha.reasoner-2",
            "confidence": 0.98,
            "lineage": [
                {
                    "stage": "request-composition",
                    "actor_id": "agent.alpha",
                    "model_id": "model.alpha.reasoner-2",
                    "note": "Requested the async task-status profile and matching field registry."
                }
            ]
        },
        "integrity": {
            "version": 2,
            "algorithm": "sha256",
            "canonicalization": "jcs",
            "checksum": "sha256:dd8a9d16c9226cc9d1f4888a4d2bbcbf06b5b4b8"
        },
        "extensions": [
            {
                "namespace": "urn:uaix:ext:delivery",
                "purpose": "Explicit async request handling and expiry semantics.",
                "critical": false
            }
        ]
    },
    "format": "result"
}
Reference exchange Ask the live mock surface for one conforming response mock-exchange-request.json
Code example
{
    "scenario": "accepted-task",
    "format": "exchange",
    "message": {
        "uai_version": "1.0",
        "profile": "uai.intent.request.v1",
        "message_id": "msg-2026-04-22-0001",
        "source": {
            "type": "agent",
            "id": "agent.alpha",
            "label": "Agent Alpha",
            "uri": "https://agents.alpha.example/runtime",
            "did": "did:web:agents.alpha.example",
            "role": "requesting-agent",
            "implementation": "alpha-runtime-2.4.1"
        },
        "target": {
            "type": "service",
            "id": "uaix.gateway",
            "label": "UAIX Gateway",
            "uri": "https://uaix.org/wp-json/uaix/v1/discovery",
            "did": "did:web:uaix.org",
            "role": "public-record-gateway",
            "implementation": "uaix-core-0.4.0"
        },
        "conversation": {
            "conversation_id": "conv-2026-04-22-uaix-001",
            "turn_id": "turn-001",
            "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
            "sequence": 1
        },
        "delivery": {
            "mode": "async",
            "priority": "interactive",
            "expires_at": "2026-04-22T16:05:00Z",
            "reply_requested": true,
            "ack_required": true
        },
        "trust": {
            "channel": "credentialed",
            "auth_scheme": "did+vc",
            "principal": "did:web:agents.alpha.example",
            "credential_ref": "https://agents.alpha.example/credentials/uai-interop.json",
            "signature_ref": "https://agents.alpha.example/signatures/msg-2026-04-22-0001.jws",
            "replay_window_id": "rw-2026-04-22-0001"
        },
        "body": {
            "intent": "resolve-profile",
            "subject": "uai.task.status.v1",
            "requested_profile": "uai.task.status.v1",
            "parameters": {
                "include_schema": true,
                "include_example": true,
                "include_field_registry": true
            },
            "constraints": [
                "public-record-only",
                "trace-linked",
                "validator-ready"
            ],
            "response_profile": "uai.intent.response.v1"
        },
        "provenance": {
            "trace_id": "trace-7f3a2d",
            "parent_trace_id": "trace-root-uaix-2026",
            "issued_at": "2026-04-22T16:00:00Z",
            "log_ref": "urn:uaix:log:2026:0001",
            "agent_id": "agent.alpha",
            "model_id": "model.alpha.reasoner-2",
            "confidence": 0.98,
            "lineage": [
                {
                    "stage": "request-composition",
                    "actor_id": "agent.alpha",
                    "model_id": "model.alpha.reasoner-2",
                    "note": "Requested the async task-status profile and matching field registry."
                }
            ]
        },
        "integrity": {
            "version": 2,
            "algorithm": "sha256",
            "canonicalization": "jcs",
            "checksum": "sha256:dd8a9d16c9226cc9d1f4888a4d2bbcbf06b5b4b8"
        },
        "extensions": [
            {
                "namespace": "urn:uaix:ext:delivery",
                "purpose": "Explicit async request handling and expiry semantics.",
                "critical": false
            }
        ]
    }
}

Keep the starter packet, validator request, and mock-exchange request required for mock-exchange configuration together with the returned result. That bundle is the smallest repeatable proof-and-response packet on the current public surface.

Read UAI-1 Open API reference page Open adoption kit page Open validator page Open conformance pack page

Client examples

Copyable starter requests in curl, PowerShell, Python, and TypeScript

Use these plain HTTP snippets to reach the live public surface quickly, including the reference-response route, while official runtime tracks remain intentionally narrow.

Starter snippets use the live public routes, not a private SDK or unpublished helper layer.

curl

Plain shell

Fastest raw HTTP path for docs, smoke checks, CI probes, and quick manual review.

Adoption kit Fetch the published onboarding bundle uai-adoption-kit.json
Code example
curl -sS "https://uaix.org/wp-json/uaix/v1/adoption-kit" -o uai-adoption-kit.json
Catalog Resolve the live route catalog
Code example
curl -sS "https://uaix.org/wp-json/uaix/v1/catalog"
Example Fetch one published starter packet example-record.json
Code example
curl -sS "https://uaix.org/wp-json/uaix/v1/examples/uai.intent.request.v1" -o example-record.json
Validate Submit the packet for a result record validate-request.json
Code example
curl -sS -X POST "https://uaix.org/wp-json/uaix/v1/validate" \
  -H "Content-Type: application/json" \
  -d @validate-request.json
Mock exchange Request one live conforming response mock-exchange-request.json
Code example
curl -sS -X POST "https://uaix.org/wp-json/uaix/v1/mock-exchange" \
  -H "Content-Type: application/json" \
  -d @mock-exchange-request.json
Read UAI-1 Examples Open adoption kit page Open validator page Open conformance pack page

Minimal first success

  1. Choose one published profile and build a message that matches its declared purpose.
  2. Validate that message against the published schema and registry record.
  3. Compare the message to a published example fixture.
  4. Save the resulting validation record as part of your release evidence.

First public proof run

  1. Start with one published profile and either a matching example fixture or a candidate message that stays inside the same public record family.
  2. Resolve the matching Schema, Registry, and canonical page paths before validation so another reviewer can reproduce the same packet.
  3. Run the Validator, export the result, and keep the exact example or candidate message used during the check.
  4. Attach the relevant Implementation track, References and Contributors, the Changelog, and News once the work moves from local testing into a public review or release context.
  5. Treat the resulting packet as current public evidence of alignment, not as a permanent certification across future revisions.

What you can claim at each readiness step

  • After one passing validator run: you have current public evidence that one message or fixture aligned with the published record at review time.
  • After assembling a release packet: you can describe the work as release-ready for public review within the chosen implementation track.
  • After a public implementation-track record exists: you can describe only that named track and release as publicly supported, and only within the owner and scope stated on the site.
  • Do not turn local testing, one passing result, or unpublished runtime work into claims of certification, blanket ecosystem support, or permanent compatibility.

Readiness map

From first proof packet to an honest public support claim

Use this map when the next step is moving from one passing validator result into a release packet without overstating current support.

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.

Packet essentials

Minimum first proof packet

  • One published profile plus its matching schema and registry routes.
  • One readable keyed JSON example or candidate message that was actually reviewed.
  • One exported validator result tied to the exact packet that was checked.
  • Discovery and citation links that let another reviewer resolve the same release state.

Next attachments

Add these before calling the work publicly supported

  • The named implementation track and release or package version.
  • Compatibility notes plus transport, trust, and error guidance when the workflow depends on them.
  • Changelog and release-summary links whenever the result changes the public release posture.
  • Only the exact scope that the site currently publishes, not a wider runtime or ecosystem promise.

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.

Get Started Validator Conformance Pack Implementations Open conformance JSON

What to keep with your first public release

  • The validation record exported from the Validator.
  • The chosen Implementation track and any packaging or runtime notes tied to it.
  • References and Contributors for stable discovery and citation links.
  • The Changelog when downstream implementers need migration posture.
  • News when the work needs a public-facing release summary.
  • Press when the release also needs approved outward-facing language.

Next step

Continue to UAI-1, then move through Schemas, Registry, Examples, the Validator, and Implementations in that order. Use References and Contributors, the Changelog, and News to keep the first public release traceable.

Agent Communication Operating Model

Agent runtimes execute. UAIX records the reviewed communication, memory, trust, evidence, and handoff boundary.

Use Agent Communication Operating Model when a human operator, coding agent, AI agent, or runtime implementer needs portable identity, intent, context, acknowledgement, status, blocker, memory proposal, validation evidence, correction, final report, or handoff records. The matching machine-readable assets are published through Schemas, Registry, Examples, and the Validator.

  • UAIX does not provide automatic sync, hosted messaging, runtime orchestration, official adapters, repository write execution, certification authority, or hosted import mechanisms.
  • Carcinus.org is a separate runtime/orchestrator example that may consume UAIX records. UAIX.org does not implement Carcinus runtime behavior and does not execute Carcinus workflows.
  • LocalEndPoint and other runtimes may consume the published UAIX records as external consumers; UAIX.org does not implement their project-specific runtime features.
  • Durable memory proposals stay separate from task execution records. Do not promote temporary endpoint statuses, session tokens, write tokens, beta platform instructions, local error traces, private keys, or API credentials.