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

Tools

Validator

Validate UAI-1 messages against published profiles, field-order rules, and policy checks, then export reviewable results before release.

  • Record UAIX-TOOL-0061
  • Path /es-us/tools/validator/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-TOOL-0061
Surface
Tools
Access
Public and linkable

How to use this page

Use this page to test candidate messages against the published UAI-1 record and save the results before release.

Validation inputs

ExamplesRegistryAPI ReferenceAdoption Kit

Validation Path

Human review and machine validation stay separate here

Use the page workbench when a person needs fixture loading and export, and use the REST route when CI, automation, or client code needs a JSON POST target.

Human surface

Fixture loading and export

This page is for side-by-side review, validator output inspection, and downloadable conformance records.

Machine surface

JSON POST route

Automation should resolve the validate route through discovery or the catalog and submit a JSON payload instead of depending on browser-only behavior.

Request posture

Public guardrails, not private quota

The public POST route rejects oversized JSON with 413 and returns 429 plus Retry-After when launch-stage throttles trip; it remains an unauthenticated public review surface, not a private bulk-validation service.

Release evidence

Keep the packet with the release

A passing validator result is part of a release packet, not a standalone certification claim or universal support badge.

Validation inputs

ExamplesPublished fixtures for baseline checks.RegistryResolve the intended public profile.API ReferenceLive route inventory and starter requests.Adoption KitPublished first-proof bundle and starter payloads.Conformance PackReusable 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.
Machine POSTValidate one candidate payload
curl -s https://uaix.org/wp-json/uaix/v1/catalog
curl -s https://uaix.org/wp-json/uaix/v1/examples/uai.intent.request.v1
curl -s -X POST https://uaix.org/wp-json/uaix/v1/validate -H "Content-Type: application/json" -d @uai-message.json

Pair the validate route with the supporting catalog, registry, and example records when the result will travel into release evidence.

What the validator checks

The validator workbench inspects candidate UAI messages against the published profile schemas, the field-order governance records, and the current operating-surface expectations for UAI-1.

  • Schema alignment for the six published message families.
  • Registry-backed profile and identifier resolution.
  • Field-order and keyless-transport expectations through the public field registry.
  • Trace-context, delivery, trust-channel, async task-state, and conformance-summary policy checks that go beyond pure JSON structure.
  • Typed failure validation against the published error registry and capability-statement checks against published transport bindings and conformance levels.
  • Predictable issue reporting when conformance fails or drift begins.

What a conformance result means

A conformance result is the machine-readable evidence that a candidate message was checked against the current public record. It is appropriate for review, release gates, regression checks, and audit evidence. It is not a substitute for a release packet or an implementation support claim by itself.

What a passing result does and does not let you claim

  • Supports: a claim that the reviewed message aligned with the published public record at the time of validation.
  • Does not support: a claim of certification, partner approval, permanent compatibility, or general runtime support beyond the attached implementation record.
  • Needs more before public support: a release packet, implementation-track record, release-trail entry, and the appropriate published conformance level for the claim you want to make.

How teams should use the validator before deployment

  1. Load a published Example or paste a candidate message.
  2. Confirm the message resolves to the intended Registry profile, the relevant field order, and the matching schema.
  3. When transport, trust, or error behavior matters, carry the published transport bindings, trust channels, error registry, and conformance levels with the same review packet.
  4. Review the generated result record, then keep that conformance record with the implementation release evidence.
  5. Use the result to decide whether the next step belongs in Implementations.

Concrete live validator surfaces

How conformance evidence becomes a public release record

  • Attach exported conformance results to the relevant implementation or package release rather than leaving them as private local checks.
  • Use the Changelog when schema, profile, field-order, transport, trust, or validator behavior changes affect migration expectations.
  • Use News when a passing or failing release needs a public-facing summary.
  • Use References and Contributors when the release needs stable discovery and citation links around its conformance evidence.

Validation result interpretation

  • Pass: the submitted message matched the public profile, schema, registry, and current validator policy at the recorded check time.
  • Warning: the message may be structurally usable but carries drift, missing evidence, weak trust posture, or review context that should be resolved before support language expands.
  • Fail: the message should not be used as release evidence until the listed profile, schema, field-order, trust, trace, delivery, or body issues are corrected and rerun.
  • Rerun trigger: rerun when the public record, validator behavior, implementation version, route posture, or support claim changes.

Published operating-surface references

The validator below now reads against a broader published operating layer, not just the schemas and fixtures.

Operating surface

Transport, trust, errors, and conformance

These records make the UAI-1 operating layer explicit instead of leaving transport binding, trust posture, typed failure semantics, or support claims to private convention.

Transport

Published bindings

Default
https-json-envelope.v1
Bindings
2
  • https-json-envelope.v1: application/vnd.uaix.uai+json
  • https-json-keyless.v1: application/vnd.uaix.uai-keyless+json
Open transport JSON

Trust

Published trust channels

  • public-web: Publicly readable records over HTTPS with no prior bilateral trust setup.
  • private-api: Service-to-service exchange on a scoped network or tenant boundary.
  • mtls: Transport-authenticated exchange where peer identity is anchored at the connection layer.
  • signed-envelope: Message-level signature or detached signature reference accompanies the record.
  • credentialed: The sender or execution context is backed by a machine-verifiable credential or comparable signed identity assertion.
Open trust JSON

Conformance

Published level ladder

  • L1-core-envelope: L1 Core Envelope
  • L2-profile-validation: L2 Profile Validation
  • L3-trust-and-integrity: L3 Trust and Integrity
  • L4-public-record-publisher: L4 Public Record Publisher
  • L5-agent-communication-profiles: L5 Agent Communication Profiles
  • L6-reliable-delegation-idempotency-correlation: L6 Reliable Delegation with Idempotency and Correlation
  • L7-capability-negotiation: L7 Capability Negotiation
Open conformance JSON

Errors

Published message error codes

  • invalid_message: Invalid message
  • unknown_profile: Unknown profile
  • capability_not_supported: Capability not supported
  • auth_required: Authentication required
  • insufficient_trust: Insufficient trust
  • task_not_found: Task not found
Open error registry JSON

Proof packet runbook

Use the published runbook below when a candidate message needs to become reusable release evidence instead of remaining a local one-off validator check.

Proof path

How the first proof packet should move through validation

Use this flow when a candidate message needs to become exportable evidence instead of staying a local test.

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

Post-validation path

What should happen after a passing validator result

Use this map when the validator passed and the next job is turning that result into reusable release evidence instead of stopping at a local check.

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.

Keep from each run

Artifacts that should stay attached to every validator result

  • The checked packet exactly as it was submitted for review.
  • The exported conformance result, including warnings as well as failures.
  • The schema, registry, field-order, and example routes used during the check.
  • Transport, trust, conformance, and error guidance when the message depends on those operating surfaces.

Before release-ready

What still needs to be attached after the pass

  • The implementation-track version or package that will carry the result outwardly.
  • Discovery and citation links so another reviewer can resolve the same public state.
  • Changelog or release-summary links when the result affects public compatibility posture.
  • Conformance-level language that stays inside the support boundary actually published.

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.

Validator Conformance JSON Conformance Pack Implementations References and Contributors

Validator workbench

Use the public workbench below to load a published fixture or validate a candidate UAI message against the current release, then download the resulting conformance record when you need a durable machine-readable report.

Validator

UAI-1 validator workbench

Paste a candidate message, load a published fixture, choose keyed or keyless normalization, and validate it against the current public UAI-1 profile schemas. The validator now checks the richer envelope, async task-state records, typed error details, field-registry alignment, trace context, delivery expiry, capability-declared transport bindings, conformance levels, and trust-policy hints before deployment.

Conformance input

Validate a UAI message

Use the published fixtures below as known-good starting points or paste a candidate payload from your own integration. Each validation run can also be exported as a `uai.conformance.result.v1` record for CI logs, release evidence, or audit trails.

Use this page as the human-facing validation workflow. The REST validate route is a machine-facing POST endpoint for JSON payloads, not a browsable report page.

Validate first, then run the same packet against the live mock exchange to inspect one conforming response shape before you widen support claims.

Open Field registry /wp-json/uaix/v1/field-registry Open Transport bindings /wp-json/uaix/v1/transport-bindings Open Error registry /wp-json/uaix/v1/error-registry Open Discovery manifest /.well-known/uaix.json Open REST catalog /wp-json/uaix/v1/catalog

Conformance result

Ready to validate

Load a fixture or paste a candidate message, then run the validator.

Status Awaiting input
Profile Not checked yet
Errors 0
Warnings 0
Normalization Keyed JSON
Checked at Not run yet

What will appear here

Run the validator to group issues by severity, resolve the exact public artifacts used during the check, and export a reusable conformance record.

Live response proof

Ready when the packet is validated

Run a passing packet through the live mock exchange to inspect one deterministic response shape before a runtime-specific track exists.

Scenario Accepted async task
HTTP Not run yet
Response profile No response yet
Response check Awaiting proof run

Use the mock exchange after a passing validation

The live reference route returns deterministic accepted, completed, and typed-error envelopes so you can inspect one conforming response shape before a runtime track publishes its own server behavior.

Next step

Continue to Implementations once the candidate message passes. Use the WordPress Publication Track for publication and packaging, or the .NET Bridge Track for deeper runtime integration, then record release-facing changes through the Changelog and News.

Capability-adaptive web interaction records

The 3.56.0 release adds the L0-L6 client capability ladder, nine capability profile IDs, validator rules for fallback/consent/idempotency/correlation/evidence/boundary failures, and adoption-kit starter files.

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.