Get Started | UAIX | Universal Artificial Intelligence Exchange

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

Implementers: start with UAI-1, then move through Schemas, Registry, Examples, the Validator, and Implementations.
Tool builders: start with Schemas, Registry, Examples, the Validator, and the published discovery surface so automation can resolve the current routes cleanly.
Researchers and standards readers: start with UAI-1, then use the Changelog, News, and References and Contributors when you need the public revision trail and citation context.
Editors, reviewers, and contributors: start with References and Contributors, the Changelog, News, and the Validator so proposals stay attached to the public record rather than private side notes.
Public readers and press: start with News for the public release trail, then use Press and References and Contributors for outward-facing language and durable links.

AI 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 Project Handoff. That page is the public quick-start for building a root AGENTS.md file plus a local .uai/ bundle that another assistant can load before it changes code or copy.

Fastest orientation: read Project Handoff first, then the AGENTS.md .uai Linking Specification when you need the explicit link syntax and typed-file pattern.
Deeper background: use Reports and Refining UAI Protocol for Agent Communication when you need the longer validation, interoperability, and security reasoning behind the handoff layer.
When the handoff becomes public evidence: return to UAI-1, Schemas, Registry, Examples, the Validator, and Implementations.

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.

Use UAI-1, Schemas, Registry, Examples, Validator, and Implementations as the practical program map for technical adoption.
Use Changelog, News, References and Contributors, and Press as the release, citation, and public-facing support layer around that map.

Quick evaluation checklist

Confirm the current public record exists on stable canonical routes: UAI-1, Schemas, Registry, Examples, the Validator, Implementations, the Changelog, and References and Contributors.
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.
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.
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.
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

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

Five-minute developer path

Open UAI-1 and read the first boundary sections so you know what the current public contract covers.
Pick one published Example and resolve its matching Schema and Registry entry.
Run the same packet through the Validator so you have reviewable evidence instead of only a prose impression.
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

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

What records you need next

The normative record on UAI-1.
Machine-validation targets on Schemas.
Stable profile and identifier references on Registry.
Working fixtures on Examples.
Validation evidence from the Validator.
Deployment direction from Implementations.

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.

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

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

Start where the work already happens

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

Shape one portable UAI-1 record

Keep identity, target, workflow state, trust posture, and provenance explicit in the public envelope.
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

Run the validator and assemble evidence

Export the conformance result and keep it with the exact artifacts and packet that were reviewed.
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

curl -s http://uiax.org/wp-json/uaix/v1/catalog
curl -s http://uiax.org/wp-json/uaix/v1/schemas/uai.intent.request.v1
curl -s http://uiax.org/wp-json/uaix/v1/adoption-kit
curl -s -X POST http://uiax.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.

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

{
    "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

{
    "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

{
    "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 optional mock-exchange request 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

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

Adoption kit Fetch the published onboarding bundle uai-adoption-kit.json

curl -sS "http://uiax.org/wp-json/uaix/v1/adoption-kit" -o uai-adoption-kit.json

Catalog Resolve the live route catalog

curl -sS "http://uiax.org/wp-json/uaix/v1/catalog"

Example Fetch one published starter packet example-record.json

curl -sS "http://uiax.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

curl -sS -X POST "http://uiax.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

curl -sS -X POST "http://uiax.org/wp-json/uaix/v1/mock-exchange" \
  -H "Content-Type: application/json" \
  -d @mock-exchange-request.json

Adoption kit Fetch the published onboarding bundle uai-adoption-kit.json

Invoke-RestMethod -Uri "http://uiax.org/wp-json/uaix/v1/adoption-kit" | ConvertTo-Json -Depth 20 | Set-Content .\uai-adoption-kit.json

Catalog Resolve the live route catalog

Invoke-RestMethod -Uri "http://uiax.org/wp-json/uaix/v1/catalog"

Example Fetch one published starter packet example-record.json

Invoke-RestMethod -Uri "http://uiax.org/wp-json/uaix/v1/examples/uai.intent.request.v1" | ConvertTo-Json -Depth 20 | Set-Content .\example-record.json

Validate Submit the packet for a result record validate-request.json

$message = (Get-Content -Raw .\example-record.json | ConvertFrom-Json).message
$body = @{ message = $message; format = "result" } | ConvertTo-Json -Depth 20
Invoke-RestMethod -Method Post -Uri "http://uiax.org/wp-json/uaix/v1/validate" -ContentType "application/json" -Body $body

Mock exchange Request one live conforming response mock-exchange-request.json

$message = (Get-Content -Raw .\example-record.json | ConvertFrom-Json).message
$body = @{ scenario = "accepted-task"; format = "exchange"; message = $message } | ConvertTo-Json -Depth 20
Invoke-RestMethod -Method Post -Uri "http://uiax.org/wp-json/uaix/v1/mock-exchange" -ContentType "application/json" -Body $body

Adoption kit Fetch the published onboarding bundle uai-adoption-kit.json

import json, urllib.request
kit = json.load(urllib.request.urlopen("http://uiax.org/wp-json/uaix/v1/adoption-kit"))

Catalog Resolve the live route catalog

import json, urllib.request
catalog = json.load(urllib.request.urlopen("http://uiax.org/wp-json/uaix/v1/catalog"))

Example Fetch one published starter packet example-record.json

example_record = json.load(urllib.request.urlopen("http://uiax.org/wp-json/uaix/v1/examples/uai.intent.request.v1"))
message = example_record.get("message", example_record)

Validate Submit the packet for a result record validate-request.json

payload = json.dumps({"message": message, "format": "result"}).encode("utf-8")
request = urllib.request.Request("http://uiax.org/wp-json/uaix/v1/validate", data=payload, headers={"Content-Type": "application/json"}, method="POST")
result = json.load(urllib.request.urlopen(request))

Mock exchange Request one live conforming response mock-exchange-request.json

payload = json.dumps({"scenario": "accepted-task", "format": "exchange", "message": message}).encode("utf-8")
request = urllib.request.Request("http://uiax.org/wp-json/uaix/v1/mock-exchange", data=payload, headers={"Content-Type": "application/json"}, method="POST")
exchange = json.load(urllib.request.urlopen(request))

Adoption kit Fetch the published onboarding bundle uai-adoption-kit.json

const kit = await fetch("http://uiax.org/wp-json/uaix/v1/adoption-kit").then((response) => response.json());

Catalog Resolve the live route catalog

const catalog = await fetch("http://uiax.org/wp-json/uaix/v1/catalog").then((response) => response.json());

Example Fetch one published starter packet example-record.json

const exampleRecord = await fetch("http://uiax.org/wp-json/uaix/v1/examples/uai.intent.request.v1").then((response) => response.json());
const message = exampleRecord.message ?? exampleRecord;

Validate Submit the packet for a result record validate-request.json

const result = await fetch("http://uiax.org/wp-json/uaix/v1/validate", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ message, format: "result" }),
}).then((response) => response.json());

Mock exchange Request one live conforming response mock-exchange-request.json

const exchange = await fetch("http://uiax.org/wp-json/uaix/v1/mock-exchange", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ scenario: "accepted-task", format: "exchange", message }),
}).then((response) => response.json());

Read UAI-1 Examples Open adoption kit page Open validator page Open conformance pack page

Minimal first success

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

First public proof run

Start with one published profile and either a matching example fixture or a candidate message that stays inside the same public record family.
Resolve the matching Schema, Registry, and canonical page paths before validation so another reviewer can reproduce the same packet.
Run the Validator, export the result, and keep the exact example or candidate message used during the check.
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.
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.

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

核心信封

为已命名配置文件生成或消费有键 UAI 信封，并通过模式验证。

在每条消息中声明已发布配置文件。
保留 message_id、source、target、provenance 和 integrity 字段。
在提出支持声明前通过匹配的已发布模式。

Public claim: 只能针对准确命名的配置文件声明 UAI-1 核心信封支持。

L2-exchange-participant

交换参与方

实现请求、响应和类型化错误流程，并具备可发现的配置文件解析和验证器证据。

在已命名工作流中支持 `uai.intent.request.v1`、`uai.intent.response.v1` 和 `uai.error.v1`。
从已发布记录解析模式、注册表条目、示例和错误代码。
将验证器证据与面向发布的实现声明放在一起。

Public claim: 可以针对已实现的命名传输绑定和配置文件声明请求-响应互操作性。

L3-async-workflow

异步工作流

支持已接收任务交接、后续任务状态可见性，以及长时间运行工作的追踪连续性。

发布带任务引用的已接收响应。
使用 `uai.task.status.v1` 表示进度、阻塞项和完成状态。
让交付过期时间和追踪连续性在更新之间保持可审查。

Public claim: 可以针对已实现的命名配置文件和传输绑定声明异步工作流互操作性。

L4-public-record-publisher

公开记录发布者

发布外部团队检查和复现支持声明所需的机器可读记录族和发布证据。

在稳定公开路由上发布发现、模式、注册表、示例、字段注册表和验证器指南。
将传输绑定、信任通道、错误注册表和一致性级别与发布记录一起发布。
将变更日志和实现证据附到公开支持声明上。

Public claim: 可以针对可发现且有证据支撑的准确发布表面声明完整公开 UAI-1 发布支持。

Claim rules

Public language should stay inside published evidence

支持声明必须说明已达到的最高级别，以及实际实现的准确配置文件和传输绑定。
单次验证器通过结果并不表示认证、整体生态支持或自动级别提升。
Level 4 claims require discoverable public artifacts and release evidence, not just local runtime behavior.
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.

Zero context to first valid UAI-1 packet

One profile, one contract

Validator-backed first evidence

Choose the release lane

Who this is for#

Reader paths by role#

AI handoff path#

What problem UAI-1 solves#

How the public work is organized today#

Quick evaluation checklist#

What to read first#

Five-minute developer path#

Adoption checklist#

What records you need next#

Current public implementation scope#

Current public developer kit#

How UAI-1 fits with MCP and A2A#

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

How the launch surface fits together from runtime to release#

MCP, A2A, orchestrators, SDKs#

UAI-1 envelope, trust, provenance, delivery#

Schemas, registry, examples, validator#

Conformance pack, implementation tracks, release trail#

Start where the work already happens#

Shape one portable UAI-1 record#

Resolve the matching public artifacts#

Run the validator and assemble evidence#

Publish only the named support lane#

Launch-ready machine entry points#

First machine calls#

Published first-proof run#

Get to one valid UAI-1 message in five minutes#

Resolve the live catalog#

Fetch one starter example#

Wrap the message for validation#

Run one validator check#

Test the live reference response#

Carry only the named next step#

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

Plain shell#

Windows-native call path#

Python standard library#

Typed fetch workflow#

Minimal first success#

First public proof run#

What you can claim at each readiness step#

From first proof packet to an honest public support claim#

Validated packet#

Release-ready packet#

Public support claim#

Minimum first proof packet#

Add these before calling the work publicly supported#

核心信封#

交换参与方#

异步工作流#

公开记录发布者#

Public language should stay inside published evidence#

What to keep with your first public release#

Next step#

Who this is for

Reader paths by role

AI handoff path

What problem UAI-1 solves

How the public work is organized today

Quick evaluation checklist

What to read first

Five-minute developer path

Adoption checklist

What records you need next

Current public implementation scope

Current public developer kit

How UAI-1 fits with MCP and A2A

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

How the launch surface fits together from runtime to release

MCP, A2A, orchestrators, SDKs

UAI-1 envelope, trust, provenance, delivery

Schemas, registry, examples, validator

Conformance pack, implementation tracks, release trail

Start where the work already happens

Shape one portable UAI-1 record

Resolve the matching public artifacts

Run the validator and assemble evidence

Publish only the named support lane

Launch-ready machine entry points

First machine calls

Published first-proof run

Get to one valid UAI-1 message in five minutes

Resolve the live catalog

Fetch one starter example

Wrap the message for validation

Run one validator check

Test the live reference response

Carry only the named next step

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

Plain shell

Windows-native call path

Python standard library

Typed fetch workflow

Minimal first success

First public proof run

What you can claim at each readiness step

From first proof packet to an honest public support claim

Validated packet

Release-ready packet

Public support claim

Minimum first proof packet

Add these before calling the work publicly supported

核心信封

交换参与方

异步工作流

公开记录发布者

Public language should stay inside published evidence

What to keep with your first public release

Next step