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

Governance

Launch Readiness

Go-live checklist for response checks, package evidence, accessibility QA, locale QA, release-trail alignment, and support-claim boundaries across the UAIX launch surface.

  • Record UAIX-GOVR-0075
  • Path /en-us/governance/launch-readiness/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-GOVR-0075
Surface
Governance
Access
Public and linkable

How to use this page

Use this page as the public go-live gate for response checks, package evidence, accessibility QA, locale QA, release-trail alignment, and support-claim boundaries.

Launch gate

Policy and SecurityConformance PackValidatorAccessibility

Go-Live Gate

Tie launch claims to observable evidence before the public push

This page collects response checks, package evidence, accessibility QA, locale QA, release notes, and support boundaries so launch readiness stays reviewable instead of implicit.

Resolve

Inventory first

Check clean routes, discovery files, sitemap output, API reference, and public page inventory before treating the site as launch-ready.

Prove

Evidence travels together

Package smoke tests, validator output, conformance pack data, and implementation evidence should be attached to the same release trail.

Localize

Chinese copy stays current

Any public launch route or support claim should ship with matching zh-CN page content, guidance, metadata, and audit coverage.

Launch gate

Policy and SecurityResponse hardening and trust-policy boundary.Conformance PackReusable evidence packet for launch review.ValidatorGenerate the proof run that belongs in the packet.AccessibilityManual readability, keyboard, and mobile QA posture.Contact and ReviewReview packets that name route, evidence, and locale impact.ChangelogDated public trail for launch-affecting changes.
Launch checksResolve the evidence surface directly
curl -s https://uiax.org/.well-known/uaix.json
curl -s https://uiax.org/sitemap.xml
curl -s http://uiax.org/wp-json/uaix/v1/catalog
curl -s http://uiax.org/wp-json/uaix/v1/conformance-pack
curl -s http://uiax.org/wp-json/uaix/v1/roadmap

Use these routes as the machine-facing starting point for public launch review, then attach package and locale-audit output from the release scripts.

Launch readiness gate

How go-live evidence should line up before broad publication

Use this matrix to keep response posture, package proof, QA, locale parity, and release notes attached to the same public launch record.

GatePublished nowVerify hereNot yet public
Public response surfaceWordPress-rendered pages and REST responses publish a narrow app-level security-header baseline, and deployment-side HTTPS, HSTS, static-file parity, and version-header cleanup remain separate launch-host checks.Do not describe this as a full production security program, incident desk, or runtime assurance service.
Package and evidence packetThe supported release path packages distributable ZIP files, smoke-tests installability, and attaches validator, conformance pack, and implementation evidence before support claims widen.One passing validator result is not a certification badge or blanket ecosystem support claim.
Accessibility and content QAManual keyboard, mobile, overflow, heading, code-block, search, validator, and sitemap checks should travel with launch-impacting template or content changes.The current page is not a third-party accessibility certification or legal compliance attestation.
Locale parityEnglish and zh-CN public copy should move together for route additions, support panels, page guidance, metadata, release notes, and audit expectations.Do not leave a public launch route English-only when localized readers can resolve the same canonical record.
Release trail alignmentLaunch-affecting route, policy, package, validator, localization, and discovery changes should be recorded through changelog and news before the new state is treated as current public truth.Do not ask external readers to trust private notes, screenshots, or local package output as the durable public record.

Launch readiness is an evidence gate, not a certification mark. A release is ready to describe publicly only when observable behavior, artifacts, audits, translations, and the dated trail agree.

Go-live sequence

What to do before a public launch push

Use this sequence when a release changes public routes, launch claims, packages, validation behavior, policy posture, or localized content.

  1. Step 1

    Resolve public routes and discovery files

  2. Step 2

    Run package, smoke-test, launch-surface, and locale audits

  3. Step 3

    Check response headers and deployment-side follow-through

  4. Step 4

    Complete manual accessibility, mobile, and content QA

  5. Step 5

    Publish changelog, news, roadmap, and zh-CN updates together

The last step is not paperwork: it is how the site avoids splitting public truth across pages, machine artifacts, release notes, and translations.

What this page is for

Use this page as the public go-live gate for the UAIX launch surface. It collects the checks that should agree before a broad public push: route inventory, discovery files, package evidence, response hardening, accessibility QA, locale QA, release notes, and support-claim boundaries.

Go-live gate

  1. Confirm clean public routes and root discovery files through /.well-known/uaix.json, /sitemap.xml, API Reference, and the route inventory in launch audits.
  2. Confirm the current distributable packages, smoke tests, conformance packet, validator behavior, and implementation evidence are all attached before describing a release as ready for public review.
  3. Confirm Policy and Security, Privacy and Data, Accessibility, and Analytics still match observable site behavior.
  4. Confirm English and zh-CN copy are updated together for any public page, route, support panel, release note, or launch claim that changed.
  5. Record public-facing launch changes through the Changelog and News before asking external readers to treat the new state as current truth.

Production response surface

The response-header checks below are the current app-level hardening record for WordPress-rendered pages and REST responses. Use them beside deployment checks for HTTPS redirect, HSTS, direct static-file parity, and host-added version headers.

Security posture

Public response hardening that now backs the launch trust surface

Use this section when a launch reviewer needs the exact response-header layer that now ships with the public WordPress surface, plus the boundary between app-level hardening and edge-level deployment work.

X-Content-Type-Options

nosniff

Prevents content-type sniffing on public standards pages and machine-readable routes.

Applied to: Public HTML, JSON, XML, and similar WordPress-rendered responses.

Referrer-Policy

strict-origin-when-cross-origin

Keeps cross-origin referrer leakage narrower while preserving same-origin debugging context.

Applied to: Public document and API responses that can generate outbound requests.

Permissions-Policy

accelerometer=(), browsing-topics=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()

Declares that the launch surface does not rely on privileged browser capabilities or Topics-based advertising features.

Applied to: Public WordPress-rendered pages and machine-facing routes.

X-Frame-Options

SAMEORIGIN

Blocks third-party framing while preserving same-origin editorial and preview flows.

Applied to: Public WordPress-rendered pages and JSON responses.

Content-Security-Policy

frame-ancestors 'self'

Makes the framing boundary explicit in modern browsers without claiming a broader full-site CSP yet.

Applied to: Public WordPress-rendered pages and machine-facing routes.

Live now

Observable on WordPress responses now

  • 已从公开响应中移除回链响应头。
  • Host- or proxy-level version headers still need server-side suppression if the launch environment adds them after WordPress runs.
  • These headers now travel with public WordPress-rendered HTML and REST responses instead of remaining only in roadmap prose.

Deployment gap

Still belongs to the host or edge layer

  • HTTPS redirect and HSTS still belong at the launch host or CDN edge because the local Studio environment runs over plain HTTP.
  • Any directly served static root files should be checked at the server or edge layer so their headers stay aligned with the WordPress-rendered trust posture.
  • Host-level version disclosure such as proxy or PHP signature headers should be suppressed where the deployment stack adds them outside WordPress.
  • Broader CSP directives should be added only after production asset and embedding behavior are validated against the launch host.

Scope boundary: 当前响应头层应用于公开的 WordPress 前端渲染响应和 REST 响应，包括验证器与面向机器的评审路由。

Policy and Security API Reference Validator Conformance Pack

Release evidence packet

The readiness map below keeps validator evidence, implementation evidence, package proof, and support language in one review path. A passing validator result is useful evidence, but the launch gate is the full packet plus public release trail.

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

Manual QA gate

  • Run keyboard navigation, focus visibility, heading hierarchy, code-block readability, search behavior, validator workflow, and mobile overflow checks across Home, Get Started, UAI-1, Tools, Validator, Governance, Launch Readiness, News, Search, and Sitemap.
  • Check that long URLs, tables, route examples, copy buttons, support panels, and downloadable-packet sections remain readable on narrow screens.
  • Keep any accessibility-significant fix connected to Accessibility, the release evidence packet, and the dated trail.

Locale and Chinese copy gate

  • Every public route added for launch should render through the zh-CN locale path with translated title, visible content, page guidance, support panels, and canonical metadata.
  • If a page adds new public claims, machine-route labels, policy posture, or release guidance, update the Chinese copy before the route is treated as launch-ready.
  • Use Contact and Review for change packets that explicitly identify locale impact and translation evidence.

What is not claimed

  • This page is not a certification program, legal attestation, accessibility badge, security operations desk, or uptime guarantee.
  • Do not infer broad production security, partner support, SDK coverage, or permanent compatibility beyond the published records and named implementation tracks.
  • Deployment-side obligations such as final DNS, HTTPS redirect, HSTS, CDN behavior, direct static root-file headers, backups, monitoring, and incident response still need production-host verification.

Next step

Use this page with Roadmap, References and Contributors, Conformance Pack, and Validator when a release needs to move from local readiness into public launch evidence.