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-0083
  • Path /fr-fr/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-0083
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.

Content quality

Claims must line up everywhere

Before a page adds a support claim, confirm the canonical copy, machine artifacts, route audit, metadata, locale coverage, and release trail all say the same thing.

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://uaix.org/.well-known/uaix.json
curl -s https://uaix.org/sitemap.xml
curl -s https://uaix.org/wp-json/uaix/v1/catalog
curl -s https://uaix.org/wp-json/uaix/v1/conformance-pack
curl -s https://uaix.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, including HSTS on HTTPS requests, while redirect enforcement, static-file parity, and version-header cleanup remain 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.

Strict-Transport-Security

max-age=31536000; includeSubDomains

Pins future browser access to HTTPS on the canonical launch host without relying only on policy prose.

Applied to: Public WordPress-rendered HTML and REST responses when the request is served over HTTPS.

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

  • HTTP-to-HTTPS redirects and HSTS coverage for directly served static files 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: The current header layer is applied to public WordPress-rendered front-end and REST responses, including the validator and machine-facing review routes; HSTS is emitted only on HTTPS requests.

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 56 profiles, 56 schemas, and 56 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

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.

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.