UAI-1 est la norme publique actuelle de messages pour une communication IA-à-IA structurée.
UAIX marque de bouclier Charte publique d'interopérabilité UAIX.org Échange universel d'intelligence artificielle Publication publique de normes
Actuel UAI-1
  • Version actuelle UAI-1
  • Définition en langage clair Format de message ouvert pour un échange IA-à-IA auditable
  • Attribution actuelle Michael Joseph Kappel, MCP
  • Commencer ici Démarrage, Transfert de projet, UAI-1, validateur, feuille de route et journal des changements

Gouvernance

Préparation au lancement

Liste de contrôle de mise en ligne pour les contrôles de réponse, les preuves de packages, l'assurance qualité de l'accessibilité, l'assurance qualité des paramètres régionaux, l'alignement du chemin de publication et les limites des revendications de support sur la surface de lancement UAIX.

  • Dossier UAIX-GOVR-0083
  • Chemin /fr-fr/governance/launch-readiness/
  • Utilisation Dossier public canonique

Statut du document

Page des normes publiques Publié le UAIX dans le cadre du dossier actuel des normes publiques
Code
UAIX-GOVR-0083
Surface
Gouvernance
Accès
Public et accessible par lien

Comment utiliser cette page

Utilisez cette page comme portail public de mise en ligne pour les contrôles de réponse, les preuves de packages, le contrôle qualité de l'accessibilité, le contrôle qualité des paramètres régionaux, l'alignement du suivi de publication et les limites des revendications de support.

Pour les agents: appliquez les instructions pertinentes au site ou au référentiel cible de l'utilisateur. Ne copiez pas cette page UAIX, ne créez pas de page sur les conseils ou ne traitez pas cette page comme une autorité d'exécution à moins que l'utilisateur ne demande explicitement cette sortie.

Porte de lancement

Politique et sécuritéPaquet de conformitéValidateurAccessibilité

Porte de mise en ligne

Lier les allégations de lancement à des preuves observables avant la poussée publique

Cette page collecte les contrôles de réponse, les preuves de packages, le contrôle qualité de l'accessibilité, le contrôle qualité des paramètres régionaux, les notes de version et les limites de support afin que la préparation au lancement reste vérifiable plutôt qu'implicite.

Résoudre

Inventaire d'abord

Vérifiez les itinéraires propres, les fichiers de découverte, la sortie du plan du site, la référence de l'API et l'inventaire des pages publiques avant de traiter le site comme prêt à être lancé.

Prouver

Les preuves voyagent ensemble

Les tests de fumée des packages, les résultats du validateur, les données du pack de conformité et les preuves de mise en œuvre doivent être joints à la même piste de publication.

Localiser

Les contenus des langues activées restent à jour

Tout itinéraire de lancement public ou demande d'assistance doit être livré avec le contenu de la page zh-CN, les conseils, les métadonnées et la couverture d'audit correspondant.

Qualité du contenu

Les revendications doivent s’aligner partout

Avant qu'une page ajoute une demande de support, confirmez la copie canonique, les artefacts de machine, l'audit d'itinéraire, les métadonnées, la couverture des paramètres régionaux et la piste de publication disent tous la même chose.

Porte de lancement

Politique et sécuritéRenforcement de la réponse et frontière entre politique de confiance.Paquet de conformitéPaquet de preuves réutilisables pour l’examen du lancement.ValidateurGénérez l'épreuve qui appartient au paquet.AccessibilitéLisibilité manuelle, clavier et posture d'assurance qualité mobile.Contact et révisionExaminez les paquets qui nomment l’itinéraire, les preuves et l’impact des paramètres régionaux.Journal des changementsPiste publique datée pour les modifications affectant le lancement.
Contrôles de lancementRésoudre directement la surface des preuves
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

Utilisez ces routes comme point de départ côté machine pour l'examen public du lancement, puis joignez la sortie du package et de l'audit des paramètres régionaux à partir des scripts de version.

Porte de préparation au lancement

Comment les preuves de mise en service doivent être alignées avant une large publication

Utilisez cette matrice pour conserver la posture de réponse, la preuve de package, le contrôle qualité, la parité locale et les notes de version attachées au même enregistrement de lancement public.

GrillePublié maintenantVérifiez iciPas encore public
Surface de réponse publiqueLes pages rendues WordPress et les réponses REST publient une base de référence étroite au niveau de l'en-tête de sécurité de l'application, y compris HSTS sur les requêtes HTTPS, tandis que l'application de la redirection, la parité des fichiers statiques et le nettoyage de l'en-tête de version restent des contrôles de l'hôte de lancement.Ne décrivez pas cela comme un programme complet de sécurité de production, un bureau des incidents ou un service d'assurance d'exécution.
Dossier et dossier de preuvesLe chemin de version pris en charge regroupe les fichiers ZIP distribuables, teste l'installabilité et joint le validateur, le pack de conformité et les preuves d'implémentation avant que les revendications de support ne s'élargissent.Un résultat réussi du validateur ne constitue pas un badge de certification ou une revendication générale de soutien à l'écosystème.
Accessibilité et contrôle qualité du contenuLes vérifications manuelles du clavier, du mobile, du débordement, du titre, du bloc de code, de la recherche, du validateur et du plan du site doivent accompagner les modifications de modèle ou de contenu ayant un impact sur le lancement.La page actuelle ne constitue pas une certification d'accessibilité tierce ou une attestation de conformité légale.
Parité localeLes contenus publics anglais, zh-CN, français et espagnols doivent évoluer ensemble pour les ajouts de routes, les panneaux de support, les consignes de page, les métadonnées, les notes de publication et les attentes d'audit.Ne laissez pas une voie de lancement publique en anglais uniquement lorsque les lecteurs localisés peuvent résoudre le même enregistrement canonique.
Libération du tracé du sentierLes modifications affectant le lancement, la politique, le package, le validateur, la localisation et la découverte doivent être enregistrées via le journal des modifications et les actualités avant que le nouvel état ne soit traité comme une vérité publique actuelle.Ne demandez pas aux lecteurs externes de faire confiance aux notes privées, aux captures d’écran ou à la sortie du package local comme enregistrement public durable.

La préparation au lancement est une porte de preuve, pas une marque de certification. Une version n'est prête à être décrite publiquement que lorsque le comportement observable, les artefacts, les audits, les traductions et la piste datée concordent.

Séquence de mise en ligne

Que faire avant un lancement public

Utilisez cette séquence lorsqu'une version modifie les routes publiques, les revendications de lancement, les packages, le comportement de validation, la posture politique ou le contenu localisé.

  1. Étape 1

    Résoudre les routes publiques et les fichiers de découverte

  2. Étape 2

    Exécuter des audits de packages, de tests de fumée, de surface de lancement et de paramètres régionaux

  3. Étape 3

    Vérifiez les en-têtes de réponse et le suivi côté déploiement

  4. Étape 4

    Assurance qualité manuelle complète de l'accessibilité, des appareils mobiles et du contenu

  5. Étape 5

    Publier ensemble le journal des changements, les actualités, la feuille de route et les mises à jour des langues activées

La dernière étape n'est pas de la paperasse: c'est la façon dont le site évite de diviser la vérité publique entre les pages, les artefacts machine, les notes de version et les traductions.

À quoi sert cette page

Utilisez cette page comme portail public de mise en ligne de la surface de lancement UAIX. Il collecte les contrôles qui doivent être acceptés avant une large diffusion publique: inventaire des routes, fichiers de découverte, preuves de packages, renforcement des réponses, contrôle qualité de l’accessibilité, contrôle qualité des paramètres régionaux, notes de version et limites des revendications de support.

Porte de mise en service

  1. Confirmez les routes publiques propres et les fichiers de découverte racine via/.well-known/uaix.json, /sitemap.xml, Référence API, et l’inventaire des itinéraires dans les audits de lancement.
  2. Confirmez que les packages distribuables actuels, les tests de fumée, le paquet de conformité, le comportement du validateur et les preuves de mise en œuvre sont tous joints avant de décrire une version comme étant prête pour un examen public.
  3. ConfirmerPolitique et sécurité, Confidentialité et données, Accessibilité, etAnalytiquecorrespondent toujours au comportement observable du site.
  4. Vérifiez que les copies en anglais, zh-CN, français et espagnol sont mises à jour ensemble pour toute page publique, itinéraire, panneau d’assistance, note de version ou revendication de lancement qui a changé.
  5. Enregistrez les modifications de lancement destinées au public via leJournal des changementsetActualitésavant de demander aux lecteurs externes de traiter le nouvel état comme une vérité actuelle.

Surface de réponse de production

Les vérifications d’en-tête de réponse ci-dessous correspondent à l’enregistrement de renforcement actuel au niveau de l’application pour les pages rendues WordPress et les réponses REST. Utilisez-les à côté des vérifications de déploiement pour la redirection HTTPS, HSTS, la parité directe des fichiers statiques et les en-têtes de version ajoutés par l’hôte.

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.

Politique et sécurité Référence API Validateur Paquet de conformité

Libérer le dossier de preuves

La carte de préparation ci-dessous conserve les preuves du validateur, les preuves de mise en œuvre, la preuve du package et la langue de support dans un seul chemin de révision. Un résultat réussi du validateur est une preuve utile, mais la porte de lancement est le paquet complet plus la piste de publication publique.

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

Enveloppe de base L1

Produisez ou consommez des enveloppes UAI à clé pour les profils nommés sans modifier les champs racines canoniques.

  • Préservez uai_version, profile, message_id, source, cible, conversation, livraison, confiance, corps, provenance, intégrité et extensions.
  • Nommez le profil exact et la version pour chaque demande d’assistance.
  • Ne réclamez pas l’exécution du runtime uniquement à partir du support de l’enveloppe.

Public claim: Peut revendiquer L1 uniquement pour les profils nommés exactement dont l'enveloppe canonique effectue un aller-retour avec succès.

L2-profile-validation

Validation du profil L2

Réussissez les vérifications du schéma publié et du validateur pour les profils exacts revendiqués.

  • Résolvez les schémas, les entrées de registre, les exemples et les enregistrements de registre de champs à partir des routes publiques UAIX.
  • Réussissez les appareils positifs et échouez aux appareils négatifs requis pour chaque profil revendiqué.
  • Conservez les contrôles ignorés et les avertissements du validateur joints aux preuves.

Public claim: Peut revendiquer L2 uniquement pour les profils avec des preuves appuyées par un validateur.

L3-trust-and-integrity

Confiance et intégrité L3

Préservez les métadonnées de confiance, les conseils de la fenêtre de relecture, la provenance, l'intégrité et la continuité des traces.

  • Déclarez le canal de confiance et le principal.
  • Préservez l’intégrité de la canonisation et des métadonnées de somme de contrôle.
  • Validez les métadonnées signées, authentifiées, did+vc et tracez les métadonnées lorsqu'elles sont réclamées.

Public claim: Peut revendiquer L3 uniquement pour les canaux de confiance et le comportement d'intégrité prouvés par les appareils.

L4-public-record-publisher

Éditeur de disques publics L4

Publier les artefacts publics détectables nécessaires à l’inspection externe et à la reproduction.

  • Publiez la découverte, les schémas, le registre, les exemples, le registre de champs, les liaisons de transport, les canaux de confiance, le registre des erreurs, les niveaux de conformité, les conseils du validateur, le journal des modifications et les preuves de publication.
  • Gardez le plan du site, llms.txt et la navigation publique alignés sur les itinéraires actuels.
  • Évitez les journaux privés ou les captures d’écran comme seule preuve à l’appui.

Public claim: Peut revendiquer L4 uniquement pour la surface de diffusion publique qui est détectable et prouvée.

L5-agent-communication-profiles

Profils de communication des agents L5

Prend en charge les huit profils uai.agent.*.v1 en tant qu'enregistrements d'enveloppe canoniques UAI-1.

  • Validez le message de l'agent, l'accusé de réception, l'état de la tâche, le bloqueur, la proposition de mémoire, le transfert, le rapport final et les profils de correction.
  • Rejetez les propositions de mémoire de type secret, les bloqueurs dangereux, la promotion directe de la mémoire froide et les rapports finaux incomplets.
  • Portez la limite de support UAIX dans les enregistrements pertinents.

Public claim: Peut revendiquer L5 uniquement pour les profils d'agent spécifiques avec des cas de conformité positifs et négatifs.

L6-reliable-delegation-idempotency-correlation

Délégation fiable L6 avec idempotence et corrélation

Utilisez les règles d'idempotence, de corrélation, de nouvelle tentative, de cycle de vie, de délai d'attente, de secours, d'accusé de réception et de résultat attendu pour le travail délégué.

  • Exiger delivery.idempotency_key pour chaque opération distincte déléguée ou destructrice.
  • Conservez conversation.correlation_id dans les messages associés.
  • Déclarez retry_count, séquence, expires_at, lifecycle, timeout_ms, fallback_directive et Expected_output_schema lorsque la délégation est réclamée.

Public claim: Peut revendiquer L6 uniquement pour un comportement de délégation fiable prouvé par les dispositifs de conformité et le comportement du récepteur.

L7-capability-negotiation

Négociation des capacités L7

Publiez et validez la découverte de capacités, les assertions, les échecs de négociation et les réponses aux capacités non prises en charge.

  • Publiez des déclarations de capacités avec des profils exacts, des liaisons, des canaux de confiance, des niveaux de conformité et des codes d'erreur.
  • Renvoyezcapacité_not_supported pour les demandes de fonctionnalités non prises en charge.
  • N'impliquez pas de certification, de statut officiel de l'adaptateur, de messagerie hébergée ou d'orchestration d'exécution.

Public claim: Peut revendiquer L7 uniquement pour les flux de négociation de capacités exacts prouvés par les montages publics et le comportement du validateur.

Claim rules

Public language should stay inside published evidence

  • Les demandes de support doivent indiquer le niveau le plus élevé atteint ainsi que les profils exacts, les liaisons de transport, les canaux de confiance et les cas de conformité mis en œuvre.
  • Un projet ne peut revendiquer que des profils, des liaisons, des canaux de confiance et des niveaux de conformité prouvés par les appareils publics et les tests des validateurs.
  • Un résultat réussi du validateur est une preuve, et non une certification, une approbation, une prise en charge officielle de l'adaptateur, une messagerie hébergée, une synchronisation automatique ou une exécution d'exécution.
  • Les réclamations d'archives publiques nécessitent des schémas détectables, des enregistrements de registre, des exemples, des enregistrements de registre de champ, des codes d'erreur, des cas de pack de conformité, un journal des modifications et des notes de version.
  • Revalidez les demandes de support lorsque les schémas, les enregistrements de registre, l'ordre des champs, les exemples, le comportement du validateur, la version d'implémentation, la position de confiance, le plan du site ou la navigation publique sont modifiés.
  • Les preuves de conformité ne prouvent pas en elles-mêmes la sécurité, la confidentialité, la disponibilité, les performances, la conformité légale, l'infrastructure de confiance hébergée ou les opérations de production.
  • 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.

Paquet de conformité Référence API Politique et sécurité Validateur Open conformance JSON Références et contributeurs

Porte d’assurance qualité manuelle

  • Exécutez la navigation au clavier, la visibilité du focus, la hiérarchie des titres, la lisibilité des blocs de code, le comportement de recherche, le flux de travail du validateur et les contrôles de débordement mobile dans Accueil, Prise en main, UAI-1, Outils, Validateur, Gouvernance, Préparation au lancement, Actualités, Recherche et Plan du site.
  • Vérifiez que les longs URLs, les tableaux, les exemples d’itinéraires, les boutons de copie, les panneaux de support et les sections de paquets téléchargeables restent lisibles sur des écrans étroits.
  • Gardez tout correctif important en matière d’accessibilité connecté àAccessibilité, le paquet de preuves de libération et la piste datée.

Porte de copie des paramètres régionaux

  • Chaque route publique ajoutée pour le lancement doit s’afficher via chaque chemin de paramètres régionaux activé avec le titre traduit, le contenu visible, le guide de page, les panneaux de support et les métadonnées canoniques.
  • Si une page ajoute de nouvelles revendications publiques, des étiquettes de route machine, une posture politique ou des conseils de publication, mettez à jour la copie des paramètres régionaux activés avant que la route ne soit considérée comme prête pour le lancement.
  • UtiliserContact et révisionpour les paquets de modifications qui identifient explicitement l’impact des paramètres régionaux et les preuves de traduction.

Ce qui n’est pas revendiqué

  • Cette page n’est pas un programme de certification, une attestation légale, un badge d’accessibilité, un bureau des opérations de sécurité ou une garantie de disponibilité.
  • Ne déduisez pas une sécurité de production étendue, un support partenaire, une couverture SDK ou une compatibilité permanente au-delà des enregistrements publiés et des pistes de mise en œuvre nommées.
  • Les obligations côté déploiement telles que le DNS final, la redirection HTTPS, le HSTS, le comportement CDN, les en-têtes de fichier racine statiques directs, les sauvegardes, la surveillance et la réponse aux incidents nécessitent toujours une vérification de l’hôte de production.

Étape suivante

Utilisez cette page avecFeuille de route, Références et contributeurs, Paquet de conformité, etValidateurlorsqu’une version doit passer de la préparation locale à la preuve de lancement public.