UAI-1 es la norma pública actual de mensajes para comunicación estructurada de IA a IA.
UAIX marca de escudo Carta pública de interoperabilidad UAIX.org Intercambio Universal de Inteligencia Artificial Publicación pública de normas
Actual UAI-1
  • Versión actual UAI-1
  • Definición en lenguaje claro Formato de mensaje abierto para intercambio IA-a-IA auditable
  • Atribución actual Michael Joseph Kappel, MCP
  • Empiece aquí Inicio, Traspaso de proyecto, UAI-1, validador, hoja de ruta y registro de cambios

Gobernanza

Preparación para el lanzamiento

Lista de verificación de puesta en marcha para verificaciones de respuesta, evidencia de paquetes, control de calidad de accesibilidad, control de calidad local, alineación del rastro de lanzamiento y límites de reclamo de soporte en toda la superficie de lanzamiento UAIX.

  • Registro UAIX-GOVR-0083
  • Ruta /es-es/governance/launch-readiness/
  • Uso Registro público canónico

Estado del documento

Página de estándares públicos Publicado el UAIX como parte del registro de estándares públicos actuales
Código
UAIX-GOVR-0083
Superficie
Gobernanza
Acceso
Público y enlazable

Cómo usar esta página

Utilice esta página como puerta de entrada pública para verificaciones de respuestas, evidencia de paquetes, control de calidad de accesibilidad, control de calidad local, alineación de seguimiento de lanzamiento y límites de reclamo de soporte.

Para agentes: aplique la guía relevante al sitio o repositorio de destino del usuario. No copie esta página UAIX, no cree una página sobre la guía ni trate esta página como autoridad de tiempo de ejecución a menos que el usuario solicite explícitamente ese resultado.

Puerta de lanzamiento

Política y seguridadPaquete de conformidadValidadorAccesibilidad

Puerta de entrada en funcionamiento

El lanzamiento de Tie afirma tener evidencia observable antes del impulso público

Esta página recopila verificaciones de respuesta, evidencia de paquetes, control de calidad de accesibilidad, control de calidad local, notas de la versión y límites de soporte para que la preparación del lanzamiento siga siendo revisable en lugar de implícita.

Resolver

inventario primero

Verifique las rutas limpias, los archivos de descubrimiento, la salida del mapa del sitio, la referencia de API y el inventario de páginas públicas antes de considerar que el sitio está listo para su lanzamiento.

Probar

La evidencia viaja junta

Las pruebas de humo del paquete, los resultados del validador, los datos del paquete de conformidad y la evidencia de implementación deben adjuntarse al mismo registro de lanzamiento.

Localizar

El contenido de los idiomas activados se mantiene actualizado

Cualquier ruta de lanzamiento público o reclamo de soporte debe enviarse con contenido, orientación, metadatos y cobertura de auditoría de la página zh-CN.

Calidad del contenido

Los reclamos deben alinearse en todas partes

Antes de que una página agregue un reclamo de soporte, confirme que la copia canónica, los artefactos de la máquina, la auditoría de ruta, los metadatos, la cobertura local y el rastro de lanzamiento dicen lo mismo.

Puerta de lanzamiento

Política y seguridadEndurecimiento de la respuesta y límite de la política de confianza.Paquete de conformidadPaquete de evidencia reutilizable para revisión de lanzamiento.ValidadorGenere la ejecución de prueba que pertenece al paquete.AccesibilidadLegibilidad manual, teclado y postura de control de calidad móvil.Contacto y revisiónRevise los paquetes que nombran la ruta, la evidencia y el impacto local.Registro de cambiosRuta pública fechada para cambios que afectan el lanzamiento.
Comprobaciones de lanzamientoResolver la superficie de evidencia directamente.
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

Utilice estas rutas como punto de partida de la máquina para la revisión del lanzamiento público, luego adjunte el paquete y el resultado de la auditoría local de los scripts de lanzamiento.

Puerta de preparación de lanzamiento

Cómo deberían alinearse las pruebas de puesta en marcha antes de una publicación amplia

Utilice esta matriz para mantener la postura de respuesta, la prueba del paquete, el control de calidad, la paridad regional y las notas de la versión adjuntas al mismo registro de lanzamiento público.

PuertaPublicado ahoraVerificar aquíAún no público
Superficie de respuesta públicaLas páginas renderizadas WordPress y las respuestas REST publican una línea de base de encabezado de seguridad a nivel de aplicación estrecha, incluido HSTS en solicitudes HTTPS, mientras que la aplicación de redireccionamiento, la paridad de archivos estáticos y la limpieza del encabezado de versión siguen siendo comprobaciones del host de lanzamiento.No describa esto como un programa de seguridad de producción completo, un servicio de incidencias o un servicio de garantía de tiempo de ejecución.
Paquete y paquete de pruebas.La ruta de lanzamiento admitida incluye archivos ZIP distribuibles, instalación de pruebas de humo y adjunta un validador, un paquete de conformidad y evidencia de implementación antes de que se amplíen las reclamaciones de soporte.Un resultado aprobado del validador no es una insignia de certificación ni un reclamo general de soporte del ecosistema.
Accesibilidad y control de calidad del contenido.Las comprobaciones manuales de teclado, dispositivo móvil, desbordamiento, encabezado, bloque de código, búsqueda, validador y mapa del sitio deben acompañarse de cambios en la plantilla o en el contenido que afectan el lanzamiento.La página actual no es una certificación de accesibilidad de terceros ni una declaración de cumplimiento legal.
Paridad localEl contenido público en inglés, zh-CN, francés y español debe avanzar junto para nuevas rutas, paneles de soporte, guía de páginas, metadatos, notas de publicación y expectativas de auditoría.No deje una ruta de lanzamiento pública solo en inglés cuando los lectores localizados puedan resolver el mismo registro canónico.
Alineación del sendero de liberaciónLos cambios de ruta, política, paquete, validador, localización y descubrimiento que afectan el lanzamiento deben registrarse a través del registro de cambios y las noticias antes de que el nuevo estado se trate como una verdad pública actual.No pida a los lectores externos que confíen en notas privadas, capturas de pantalla o resultados de paquetes locales como registros públicos duraderos.

La preparación para el lanzamiento es una puerta de evidencia, no una marca de certificación. Una versión está lista para ser descrita públicamente sólo cuando el comportamiento observable, los artefactos, las auditorías, las traducciones y el rastro fechado coinciden.

Secuencia de puesta en marcha

Qué hacer antes de un lanzamiento público

Utilice esta secuencia cuando un lanzamiento cambie rutas públicas, reclamos de lanzamiento, paquetes, comportamiento de validación, postura política o contenido localizado.

  1. Paso 1

    Resolver rutas públicas y archivos de descubrimiento.

  2. Paso 2

    Ejecutar auditorías de paquetes, pruebas de humo, superficie de lanzamiento y ubicación.

  3. Paso 3

    Verifique los encabezados de respuesta y el seguimiento del lado de la implementación

  4. Paso 4

    Control de calidad manual completo sobre accesibilidad, dispositivos móviles y contenido

  5. Paso 5

    Publicar juntos el registro de cambios, las noticias, la hoja de ruta y las actualizaciones de idiomas activados

El último paso no es el papeleo: es cómo el sitio evita dividir la verdad pública en páginas, artefactos mecánicos, notas de la versión y traducciones.

Para qué es esta página

Utilice esta página como puerta de entrada pública para la superficie de lanzamiento UAIX. Recopila las comprobaciones que deberían acordarse antes de un impulso público amplio: inventario de rutas, archivos de descubrimiento, evidencia de paquetes, refuerzo de respuestas, control de calidad de accesibilidad, control de calidad regional, notas de versión y límites de reclamo de soporte.

Puerta de entrada en funcionamiento

  1. Confirme rutas públicas limpias y archivos de descubrimiento de raíz a través de/.well-known/uaix.json, /sitemap.xml, Referencia APIy el inventario de rutas en las auditorías de lanzamiento.
  2. Confirme que los paquetes distribuibles actuales, las pruebas de humo, el paquete de conformidad, el comportamiento del validador y la evidencia de implementación estén adjuntos antes de describir un lanzamiento como listo para revisión pública.
  3. ConfirmarPolítica y seguridad, Privacidad y datos, Accesibilidad, yAnalíticaaún coincide con el comportamiento observable del sitio.
  4. Confirme que las copias en inglés, zh-CN, francés y español se actualicen juntas para cualquier página pública, ruta, panel de soporte, nota de la versión o reclamo de lanzamiento que haya cambiado.
  5. Registre los cambios de lanzamiento de cara al público a través delRegistro de cambiosyNoticiasantes de pedir a los lectores externos que traten el nuevo estado como una verdad actual.

Superficie de respuesta de producción

Las comprobaciones del encabezado de respuesta a continuación son el registro de protección actual a nivel de aplicación para páginas renderizadas WordPress y respuestas REST. Utilícelos junto con las comprobaciones de implementación para la redirección HTTPS, HSTS, paridad directa de archivos estáticos y encabezados de versión agregados por el host.

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.

Política y seguridad Referencia API Validador Paquete de conformidad

Liberar paquete de evidencia

El siguiente mapa de preparación mantiene la evidencia del validador, la evidencia de implementación, la prueba del paquete y el lenguaje de soporte en una sola ruta de revisión. Un resultado aprobado del validador es una evidencia útil, pero la puerta de lanzamiento es el paquete completo más el rastro de lanzamiento público.

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

Envolvente central L1

Produzca o consuma sobres con clave UAI para perfiles con nombre sin cambiar los campos raíz canónicos.

  • Conserve uai_version, perfil, message_id, fuente, destino, conversación, entrega, confianza, cuerpo, procedencia, integridad y extensiones.
  • Nombra el perfil exacto y la liberación para cada reclamo de soporte.
  • No reclame la ejecución del tiempo de ejecución únicamente mediante soporte de sobre.

Public claim: Puede reclamar L1 solo para los perfiles con nombre exacto cuyo sobre canónico realiza viajes de ida y vuelta con éxito.

L2-profile-validation

Validación del perfil L2

Pase las comprobaciones del esquema publicado y del validador para los perfiles exactos reclamados.

  • Resuelva esquemas, entradas de registro, ejemplos y registros de campo de rutas públicas UAIX.
  • Aprobar los elementos positivos y no aprobar los elementos negativos requeridos para cada perfil reclamado.
  • Mantenga los controles omitidos y las advertencias del validador adjuntas a las pruebas.

Public claim: Puede reclamar L2 solo para perfiles con evidencia respaldada por un validador.

L3-trust-and-integrity

L3 Confianza e Integridad

Preserve los metadatos de confianza, las sugerencias de la ventana de reproducción, la procedencia, la integridad y la continuidad del seguimiento.

  • Declarar canal de confianza y principal.
  • Preservar la canonicalización de integridad y los metadatos de suma de comprobación.
  • Valide los metadatos firmados, acreditados, did+vc y de seguimiento cuando se reclamen.

Public claim: Puede reclamar L3 solo por los canales de confianza y el comportamiento de integridad demostrados por los accesorios.

L4-public-record-publisher

Editor de registros públicos L4

Publicar artefactos públicos detectables necesarios para la inspección y reproducción externas.

  • Publique descubrimiento, esquemas, registro, ejemplos, registro de campos, enlaces de transporte, canales de confianza, registro de errores, niveles de conformidad, orientación del validador, registro de cambios y evidencia de publicación.
  • Mantenga el mapa del sitio, llms.txt y la navegación pública alineados con las rutas actuales.
  • Evite registros privados o capturas de pantalla como única evidencia de respaldo.

Public claim: Puede reclamar L4 solo para la superficie de liberación pública que sea detectable y evidenciada.

L5-agent-communication-profiles

Perfiles de comunicación del agente L5

Admite los ocho perfiles uai.agent.*.v1 como registros de sobre canónicos UAI-1.

  • Valide los perfiles de mensaje, confirmación, estado de tarea, bloqueador, propuesta de memoria, transferencia, informe final y corrección del agente.
  • Rechace propuestas de memoria secretas, bloqueadores inseguros, promoción directa de memoria fría e informes finales incompletos.
  • Llevar el límite de soporte UAIX en los registros pertinentes.

Public claim: Puede reclamar L5 solo para perfiles de agentes específicos con casos de conformidad positivos y negativos.

L6-reliable-delegation-idempotency-correlation

L6 Delegación confiable con idempotencia y correlación

Utilice reglas de idempotencia, correlación, reintento, ciclo de vida, tiempo de espera, respaldo, reconocimiento y salida esperada para el trabajo delegado.

  • Requerir delivery.idempotency_key para cada operación destructiva o delegada distinta.
  • Conservar conversation.correlation_id en todos los mensajes relacionados.
  • Declare retry_count, secuencia, expires_at, ciclo de vida, timeout_ms, fallback_directive y expect_output_schema cuando se reclame la delegación.

Public claim: Puede reclamar L6 solo por un comportamiento de delegación confiable demostrado por dispositivos de conformidad y comportamiento del receptor.

L7-capability-negotiation

Negociación de capacidad L7

Publique y valide el descubrimiento de capacidades, afirmaciones, fallas de negociación y respuestas de capacidades no respaldadas.

  • Publique declaraciones de capacidad con perfiles exactos, enlaces, canales de confianza, niveles de conformidad y códigos de error.
  • Devuelve capacidad_not_supported para solicitudes de capacidad no admitidas.
  • No implica certificación, estado oficial del adaptador, mensajería alojada ni orquestación en tiempo de ejecución.

Public claim: Puede reclamar L7 solo para los flujos de negociación de capacidad exactos demostrados por los dispositivos públicos y el comportamiento del validador.

Claim rules

Public language should stay inside published evidence

  • Las declaraciones de soporte deben nombrar el nivel más alto alcanzado más los perfiles exactos, vinculaciones de transporte, canales de confianza y casos de conformidad implementados.
  • Un proyecto solo puede reclamar perfiles, vinculaciones, canales de confianza y niveles de conformidad que demuestren los dispositivos públicos y las pruebas de validación.
  • Un resultado aprobado del validador es evidencia, no certificación, respaldo, soporte oficial del adaptador, mensajería alojada, sincronización automática o ejecución en tiempo de ejecución.
  • Las reclamaciones de registros públicos requieren esquemas detectables, registros de registro, ejemplos, registros de campo, códigos de error, casos de paquetes de conformidad, registros de cambios y notas de la versión.
  • Revalide las reclamaciones de soporte cuando cambien los esquemas, los registros de registro, el orden de los campos, los ejemplos, el comportamiento del validador, la versión de implementación, la postura de confianza, el mapa del sitio o la navegación pública.
  • La evidencia de conformidad no demuestra por sí sola la seguridad, la privacidad, la disponibilidad, el rendimiento, el cumplimiento legal, la infraestructura de confianza alojada ni las operaciones de producción.
  • 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.

Paquete de conformidad Referencia API Política y seguridad Validador Open conformance JSON Referencias y colaboradores

Puerta de control de calidad manual

  • Ejecute navegación con teclado, visibilidad de enfoque, jerarquía de encabezados, legibilidad de bloques de código, comportamiento de búsqueda, flujo de trabajo del validador y comprobaciones de desbordamiento móvil en Inicio, Introducción, UAI-1, Herramientas, Validador, Gobernanza, Preparación para el lanzamiento, Noticias, Búsqueda y Mapa del sitio.
  • Verifique que los URLs largos, las tablas, los ejemplos de ruta, los botones de copia, los paneles de soporte y las secciones de paquetes descargables permanezcan legibles en pantallas estrechas.
  • Mantenga cualquier solución importante para la accesibilidad conectada aAccesibilidad, el paquete de pruebas de liberación y el rastro fechado.

Puerta de copia local

  • Cada ruta pública agregada para el lanzamiento debe representarse a través de cada ruta local habilitada con título traducido, contenido visible, guía de página, paneles de soporte y metadatos canónicos.
  • Si una página agrega nuevas notificaciones públicas, etiquetas de ruta de máquina, postura de política u orientación de lanzamiento, actualice la copia de la configuración regional habilitada antes de que la ruta se considere lista para el lanzamiento.
  • UsarContacto y revisiónpara paquetes de cambios que identifiquen explícitamente el impacto local y la evidencia de traducción.

lo que no se reclama

  • Esta página no es un programa de certificación, una certificación legal, una insignia de accesibilidad, un mostrador de operaciones de seguridad ni una garantía de tiempo de actividad.
  • No infiera seguridad de producción amplia, soporte de socios, cobertura SDK o compatibilidad permanente más allá de los registros publicados y las vías de implementación nombradas.
  • Las obligaciones del lado de la implementación, como DNS final, redireccionamiento HTTPS, HSTS, comportamiento de CDN, encabezados de archivos raíz estáticos directos, copias de seguridad, monitoreo y respuesta a incidentes, aún necesitan verificación del host de producción.

Siguiente paso

Utilice esta página conHoja de ruta, Referencias y colaboradores, Paquete de conformidad, yValidadorcuando una liberación necesita pasar de la preparación local a la evidencia de lanzamiento público.