UAI-1 is the current public message standard for structured AI-to-AI communication.
UAIX shield mark Public interoperability charter UAIXUniversal Artificial Intelligence ExchangePublic standards publication
CurrentUAI-1 v1.0
  • Current versionUAI-1 v1.0
  • Plain-English definitionOpen message format for auditable AI-to-AI exchange
  • Current attributionMichael Kappel and the UAIX contributors
  • Start hereGet 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-0077
  • 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-0077
Surface
Governance
Access
Public and linkable

How to use this page

Use this page as the canonical public reference for Launch Readiness and its standards-facing content.

For agents: apply the relevant guidance to the user's target site or repository. Do not copy this UAIX page, create a page about the guidance, or treat this page as runtime authority unless the user explicitly asks for that output.

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, zh-CN, French, and Spanish 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

Response-header baseline

The native runtime applies a defense-in-depth header set without relying on WordPress hooks or inline code.

Content-Security-Policy

default-src 'self'; object-src 'none'; frame-ancestors 'self'

Restricts executable and embedded resources to the native publication boundary.

Strict-Transport-Security

max-age=31536000; includeSubDomains

Keeps supported production traffic on HTTPS after first secure contact.

X-Content-Type-Options

nosniff

Prevents content-type guessing for JSON, scripts, styles, and downloads.

Referrer-Policy

strict-origin-when-cross-origin

Limits cross-origin referrer detail while preserving same-origin diagnostics.

Permissions-Policy

camera=(), geolocation=(), microphone=(), payment=(), usb=()

Disables browser capabilities the publication site does not need.

Cross-Origin-Opener-Policy

same-origin

Separates the browsing context from unrelated cross-origin windows.

Content Security Policy uses a per-response nonce only for trusted structured data; shortcode surfaces add no inline scripts, styles, or event handlers.

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.

Release readiness

From first packet to bounded support claim

Map each support claim to the exact published level and evidence that proves it.

L1-core-envelope

L1 Core Envelope

Produce or consume keyed UAI envelopes for named profiles without changing the canonical root fields.

Claim boundary: 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.

Claim boundary: 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.

Claim boundary: 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.

Claim boundary: 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.

Claim boundary: 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.

Claim boundary: 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.

Claim boundary: May claim L7 only for the exact capability negotiation flows proven by public fixtures and validator behavior.

Open conformance levelsOpen Conformance Pack JSONValidate a packet

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 copy gate

  • Every public route added for launch should render through each enabled 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 enabled-locale 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.