UAI-1

What UAI-1 is#

UAI-1 is Universal Artificial Intelligence Version 1, the current normative release in the UAI family published by UAIX. Treat it as the public envelope, trust declaration, and evidence layer for AI-to-AI exchange: a portable record that can sit above MCP, A2A, orchestration, and runtime-specific tooling without being trapped inside any one stack.

Quick answer for launch readers#

• Use it when: another team needs a citable, validator-backed message contract that can travel beyond one runtime boundary.
• Do not mistake it for: a replacement for every transport, authorization, tracing, orchestration, or local tool-session protocol around the exchange.
• Published now: the shared envelope, six profiles, the field registry, transport bindings, trust channels, the error registry, conformance levels, examples, validator guidance, API Reference, Adoption Kit, OpenAPI, Conformance Pack, implementation evidence checklist, conformance fixture pack with canonical-hash equivalence, bridge evidence pack, implementation tracks, and the release trail.
• Fastest proof path: read the boundary here, resolve one profile through schema and example, run validation, then carry the result into the current public implementation or release-evidence surface.

What the current release includes#

• Written contract: this page, Schemas, Registry, and Examples define the current public UAI-1 record together.
• Machine-readable operating layer: published transport bindings, trust channels, the error registry, and conformance levels keep delivery, trust posture, failure types, and support-claim language explicit.
• Field-order governance: the public field registry keeps readable keyed JSON and compact keyless transfer aligned to the same declared source order.
• Validation and release evidence: the Validator, Adoption Kit, Conformance Pack, implementation tracks, changelog, and references keep support claims attached to reviewable public artifacts instead of prose alone.

What every public packet keeps explicit#

• Identity and direction: uai_version, profile, message_id, source, and target.
• Workflow continuity: conversation and delivery keep sequencing, expiry, reply expectations, task references, and trace linkage explicit.
• Trust context: trust declares the surrounding channel, principal, auth scheme, credential references, signature references, and replay-window hints without forcing one credential stack.
• Business meaning: body carries the intent, result, capability, task-state, error, or conformance payload defined by the profile.
• Auditability: provenance, integrity, and extensions preserve traceability, checksums, lineage, and controlled extensibility.

When to choose UAI-1 first#

• When a message needs to cross teams, systems, or audit contexts as a portable public record instead of staying inside one local runtime.
• When identity, workflow state, trust posture, provenance, typed errors, and async-delivery rules need to remain visible on the record instead of being left to private convention.
• When a launch review needs validator evidence, profile identifiers, field-order governance, and example fixtures to stay attached to the same support claim.

What UAI-1 stays beside#

• Local tool calls, resource sessions, orchestrators, and task-delegation systems can keep handling runtime behavior beside UAI-1.
• Transport, security, signing, credential, and tracing systems should be treated as companion layers declared in the envelope rather than as one hard-coded universal stack.
• UAI-1 is strongest as the public exchange and release-record layer, not as a total replacement for the surrounding runtime ecosystem.

Current published profiles#

• uai.intent.request.v1 for explicit requests against a declared subject.
• uai.intent.response.v1 for results, acknowledgements, and accepted async handoffs.
• uai.capability.statement.v1 for publicly reviewable capability declarations.
• uai.error.v1 for typed, machine-readable failure records.
• uai.conformance.result.v1 for exported validator evidence.
• uai.task.status.v1 for visible async progress and completion state.

Current operating surfaces#

• Transport bindings: the published transport bindings describe the default keyed envelope binding, the declared-condition keyless binding, and the accepted async response pattern.
• Trust channels: the published trust channels define what public-web, private-api, mtls, signed-envelope, and credentialed mean on the public record.
• Error handling: the published error registry gives uai.error.v1 named machine-readable codes instead of relying on ad hoc text.
• Support claims: the published conformance levels explain what an implementation may honestly claim after passing validation and publishing release evidence.
• Compact transfer: the public field registry keeps keyed JSON and keyless transport order aligned.

Message lifecycle#

1. Discover: resolve the catalog, profile registry, schema, field registry, examples, transport bindings, trust channels, error registry, and conformance levels from public UAIX routes.
2. Compose: build the keyed source envelope first so identity, direction, workflow state, trust posture, body meaning, provenance, integrity, and extensions stay reviewable.
3. Validate: check the candidate message against schema and validator policy, including trace, delivery, trust, async, and conformance-summary expectations.
4. Package: carry the validator result, fixture, checked route URLs, implementation scope, release trail, support boundary, and non-claims together.
5. Publish or reject: make a public support claim only when the packet is attached to a named implementation and release record; otherwise keep the result as private QA evidence.
6. Recheck: rerun the proof when the public record, implementation version, route posture, or trust boundary changes.

Threat and misuse boundary#

• UAI-1 makes the exchange record explicit; it does not replace authentication, authorization, secrets handling, rate limiting, abuse detection, deployment review, or incident response.
• Trust fields declare the surrounding trust channel and references; they do not guarantee that a credential, signature, DID, VC, host, or principal is valid unless the receiving system verifies it.
• Conformance evidence proves alignment to the public record at a check time; it does not prove security, privacy, legal compliance, model quality, uptime, endorsement, or certification.
• Public automation should prefer clean UAIX routes, noindex machine records, explicit POST guardrails, and release-trail links over screenshots or private logs.

Implementation quality bar#

• Name the exact profiles, transport bindings, normalization modes, and trust channels supported.
• Keep the candidate message, validation result, canonical hash metadata, fixture references, and checked artifact URLs together.
• Publish known limitations and future-work boundaries beside the claim.
• Verify the human citation pages, machine JSON routes, supported locale coverage, accessibility posture, and changelog entry before broadening support language.

From written contract to the first proof packet#

1. Read the boundary sections here first so you know UAI-1 is defining the public record, not every runtime implementation around it.
2. Resolve one published profile through Schemas, Registry, the field registry, and Examples.
3. Run the same packet through the Validator so the result becomes machine-readable evidence instead of a prose impression.
4. Use API Reference, Adoption Kit, and Conformance Pack when the packet needs to move into automation, launch review, or a reusable handoff bundle.
5. Only call support public once the result is attached to a named Implementation track, the Changelog, or the References and Contributors record.

Current launch surfaces for this contract#

• API Reference turns the live REST surface into a route-level handbook with an OpenAPI export.
• Adoption Kit publishes the starter files and first-proof bundle for the current public contract.
• Conformance Pack assembles the broader machine-readable release packet for launch review and repeatable evidence work, including the bridge evidence pack.
• /wp-json/uaix/v1/catalog is the machine-facing entry point for the current public standards inventory.
• /wp-json/uaix/v1/validate is the JSON POST route for automation and release-pipeline validation.

How UAI-1 fits with adjacent standards#

• A2A can manage agent discovery, delegation, and task-stream mechanics; UAI-1 carries the portable public exchange and evidence record across those flows.
• MCP can manage host-client-server tool sessions and capability negotiation inside an application boundary; UAI-1 remains the portable, citable record when exchanges need to leave that boundary.
• W3C Trace Context can travel in conversation.traceparent when distributed tracing already exists.
• RFC 9457 Problem Details informs the typed public error shape used by uai.error.v1.
• W3C Verifiable Credentials and DID-based trust stacks can sit behind trust.principal, credential_ref, and signature_ref without becoming one mandatory universal stack.

Use Standards Fit when you need the fuller UAI-1 vs MCP, UAI-1 vs A2A, bridge-evidence, and compact-transfer decision guide.

The operating-surface records below are part of the current public release and are meant to be resolved mechanically alongside the specification text.

What the current contract requires#

• Every message must declare a published profile and remain compatible with the matching schema.
• Every public exchange must keep identity, workflow state, trust posture, and auditability on the record instead of leaving them to private convention.
• Compact keyless transport must remain aligned with the human-readable keyed record through the public field registry.
• Support claims should be backed by validator evidence, release notes, an implementation record, and the appropriate conformance level rather than by prose alone.

Support-claim boundary#

• UAI-1 does not turn one local test, one passing result, or one unpublished runtime experiment into general public support.
• Current public support should still be read through the named implementation tracks and release evidence published on the site, not as a blanket promise for the surrounding agent ecosystem.
• Current bridge evidence examples are mapping examples, not completed bridge profiles, SDK support, certification, or replacement claims.
• This page exists to make the contract explicit first, then keep support language scoped to what the public record can actually verify.

Example exchange#

{ "uai_version": "1.0", "profile": "uai.intent.request.v1", "message_id": "msg-2026-04-22-0001", "source": { "type": "agent", "id": "agent.alpha", "uri": "https://agents.alpha.example/runtime" }, "target": { "type": "service", "id": "uaix.gateway", "uri": "https://uaix.org/wp-json/uaix/v1/discovery" }, "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_field_registry": true }, "constraints": [ "public-record-only", "validator-ready" ], "response_profile": "uai.intent.response.v1" }, "provenance": { "trace_id": "trace-7f3a2d", "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 }, "integrity": { "version": 2, "algorithm": "sha256", "canonicalization": "jcs", "checksum": "sha256:dd8a9d16c9226cc9d1f4888a4d2bbcbf06b5b4b8" }, "extensions": [] }

How changes stay public and reviewable#

• Reflect profile, envelope, field-order, transport, trust, error, or support-claim changes through Schemas, the field registry, Registry, Examples, the Validator, and the operating-surface records.
• Carry release-facing evidence into Implementations so support claims stay attached to real software.
• Use References and Contributors and the Changelog when others need durable discovery, attribution, and migration context.

Next step#

Continue to Schemas to see the machine-validated contract, use Examples when you need the public fixtures, open the Validator when you need human-facing proof work, and move to API Reference or Conformance Pack when the contract needs to travel into automation or launch review.