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

Conformance Pack

Reusable machine-readable packet for the current public UAI-1 record, validator evidence path, and launch-review inventory.

  • Record UAIX-TOOL-0062
  • Path /en-us/tools/conformance-pack/
  • Use Canonical public record

Document status

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

How to use this page

Use this page to assemble the current reusable conformance packet for launch review and release evidence.

Evidence sources

Conformance Pack JSONAdoption KitValidatorImplementations

Evidence Packet

What travels into launch review and support claims

The conformance pack keeps the current public record, implementation evidence checklist, and conformance fixture pack together for reuse. Treat it as the evidence bundle behind release review, not as a certification surface by itself.

What travels

Catalog, schemas, fixtures, checklist, regression cases, and trust records

The pack carries the public standards inventory, implementation evidence checklist, conformance fixture pack, and machine-readable supporting records another reviewer needs to reconstruct the same baseline.

When to attach it

Launch review, regression, and release notes

Use the pack when validation evidence, fixture expectations, and checklist answers need to travel into implementation review, packaging checks, or a dated public release record.

What not to claim

Evidence is not certification

A pack helps prove what was checked, but it does not create a badge, endorsement, or blanket support claim on its own.

Evidence sources

Conformance Pack JSONMachine-readable release packet.Adoption KitPublished first-proof bundle before the broader evidence packet.ValidatorGenerate the result that belongs in the packet.ImplementationsAttach the packet to the named release lane.Policy and SecurityTrust posture that frames the packet.
Pack endpointsFetch or download the current packet
curl -s http://uiax.org/wp-json/uaix/v1/conformance-pack
curl -OJ "http://uiax.org/wp-json/uaix/v1/conformance-pack?download=1"

Use the raw JSON route for automation and the download form when the exact packet needs to travel as an attachment.

What this pack is

The UAIX conformance pack is the reusable machine-readable release packet for the current public UAI-1 record. It keeps the catalog, discovery manifest, schemas, registry, field order, examples, guidance records, roadmap record, implementation-evidence checklist, conformance fixture pack, and pack-level launch pointers together so another reviewer can reconstruct the same public baseline without private notes.

What belongs in the pack

  • The current catalog and discovery surface.
  • The active schema, registry, field-registry, example, transport, trust, conformance, error, and roadmap records.
  • The public entry points for the validator, API reference, roadmap, and current launch-support pages.
  • An implementation-evidence checklist for implementation identity, supported profile scope, validator evidence, fixtures, release trail, and support boundary.
  • A conformance fixture pack with positive keyed, minified-keyed, and keyless checks, canonical-hash equivalence metadata, and negative current-boundary cases for schema, trace, trust, keyless-shape, keyless-overflow, and unsupported-alias behavior.
  • A quickstart sequence for turning one published profile into a reviewable release packet.

How teams should use it

  1. Start with one profile and one validator-backed proof run.
  2. Run the fixture pack and complete the implementation-evidence checklist before describing the result as a release-ready support claim.
  3. Attach the pack when that proof needs to travel into implementation review, launch QA, or release evidence.
  4. Keep the pack aligned with Implementations, the Changelog, News, and the Roadmap whenever public support posture changes.
  5. Do not describe the pack itself as a certification or badge program; it is the reusable evidence packet behind those future-facing ideas.

Live reusable release packet

Use the published pack below when you want the current JSON bundle, fixture expectations, and profile-by-profile inventory that go with it.

Conformance pack

Reusable release packet

This pack assembles the current public release artifacts into one machine-readable packet for onboarding, regression checks, implementation review, and pre-launch release evidence.

What ships together

Core public release artifacts

  • Catalog and discovery manifest
  • Registry, schemas, field registry, and published examples
  • Transport, trust, conformance, and error guidance
  • Validator and API-reference entry points for repeatable checks

Best use

Ship one reviewable packet

Carry one pack alongside validator output, implementation evidence, and the changelog or release note so another reviewer can reconstruct the same public record without private context.

Release sequence

How to use the pack before launch

  1. Resolve the catalog and discovery routes first so the release packet points at the current public record.
  2. Choose one published profile, then pair its schema, registry entry, example fixture, field-order guidance, and validator normalization mode before validation.
  3. Run the validator and keep the exported conformance result beside the exact artifact URLs used during the check.
  4. Complete the implementation evidence checklist with implementation identity, supported profiles, artifact references, validator output, release trail, and support boundary.
  5. Run the conformance fixture pack so positive keyed/minified/keyless cases, canonical-hash equivalence, and negative schema, trace, trust, keyless-shape, keyless-overflow, and unsupported-alias cases stay reproducible before release.
  6. Review the bridge evidence pack when A2A, MCP, OpenAPI, DID/VC, or Trace Context claims need concrete UAI-1 mapping examples without becoming replacement claims.
  7. Attach the validator result, implementation-track evidence, changelog link, and release-note link before making a public support claim.

UAI-REGI-0001

UAI Intent Request v1

Request an explicit outcome or async task against a declared subject using the full UAI-1 envelope, trust metadata, and reviewable delivery controls.

Profile
uai.intent.request.v1
Expected status
PASS
Required body fields
intent, subject, requested_profile, parameters, constraints, response_profile
Schema Example Registry

UAI-REGI-0002

UAI Intent Response v1

Return a direct result or accepted-task handoff for a declared request while preserving conversation continuity, trust metadata, and release-ready evidence.

Profile
uai.intent.response.v1
Expected status
PASS
Required body fields
status, subject, request_message_id, result, notices
Schema Example Registry

UAI-REGI-0003

UAI Capability Statement v1

Publish capability, endpoint, security, async workflow, and extension-support metadata so adjacent systems can resolve what an implementation actually supports.

Profile
uai.capability.statement.v1
Expected status
PASS
Required body fields
capability_id, version, operations, input_profiles, output_profiles, async_profiles, security_schemes, endpoints
Schema Example Registry

UAI-REGI-0004

UAI Error v1

Report validation, transport, authorization, or execution failures using a typed problem-details-style envelope with retry and path-level detail.

Profile
uai.error.v1
Expected status
PASS
Required body fields
type, title, detail, status, code, retryable, instance
Schema Example Registry

UAI-REGI-0005

UAI Conformance Result v1

Capture validator output, artifact references, and issue summaries in the same public message family so proof can travel with the release record.

Profile
uai.conformance.result.v1
Expected status
PASS
Required body fields
status, checked_profile, issues, summary, artifacts
Schema Example Registry

UAI-REGI-0006

UAI Task Status v1

Publish long-running task state, progress, blockers, and result references so async agent work stays auditable instead of disappearing into private workflow state.

Profile
uai.task.status.v1
Expected status
PASS
Required body fields
task_id, state, subject, progress, status_message
Schema Example Registry

Reusable packet

How the conformance pack fits into launch readiness

Use this map when the downloadable pack needs human-facing release context and honest support-claim language around it.

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.

Pack contents

What the reusable machine packet already carries

  • The current release packet already carries 6 profiles, 6 schemas, and 6 examples from the live public record.
  • Catalog, discovery, field-order, transport, trust, conformance, and error guidance in one JSON handoff.
  • Validator and API-reference entry points for repeatable launch review and automation.
  • A quickstart path for turning one published profile into a reviewable release packet.

Human release context

What the pack still needs from the public site

  • Implementation version, owner path, and the exact support boundary being claimed.
  • Changelog or news links that explain what changed in this release.
  • Policy and Security posture when the release changes trust-significant behavior.
  • Conformance-level language that keeps the outward-facing claim narrower than the packet itself.

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.

Conformance Pack API Reference Policy and Security Validator Open conformance JSON References and Contributors

Next step

Continue to Policy and Security for the current public trust posture, return to API Reference when you need the route-level machine contract behind the pack, or open the Roadmap when a support claim depends on future-work boundaries.