Résumé

  • La révision 04 du projet Internet individuel AER-1 exige des feuilles calculées à partir du receipt_id de chaque étape ; la page publique observée utilise à la place seq:receipt_hash.
  • Les cinq reçus d’étape ont répondu HTTP 200, se sont déclarés vérifiés et ont renvoyé les empreintes attendues. L’algorithme de la page retrouve exactement sa racine publiée, tandis que l’algorithme du projet en produit une autre.
  • Les aides Python, Rust et TypeScript du dépôt suivent le projet. En revanche, le corpus annoncé à 43/43 porte encore la mention -03 et ne contient aucun vecteur de flux de travail.

Le voyant vert a perdu son complément d’objet

Sur la page publique du flux 42a3c2cf-2cdd-5b8a-aced-016e5a2fb634, tout paraît ordonné. Cinq étapes sont listées. Le navigateur récupère chaque reçu, exige une réponse positive, compare l’empreinte retournée avec le manifeste et reconstruit une racine de Merkle. Le calcul aboutit à a4b2fcb4684cec481e4ece889ed15c7d9e47e58d9ba4fb02ea354c0cb2ca44c4, exactement la valeur publiée.

Une reproduction indépendante confirme l’ensemble du parcours. Les cinq points de vérification ont répondu avec succès. Les cinq reçus ont indiqué verified: true. Les cinq empreintes de sortie correspondaient à celles inscrites sur la page. Aucune étape ne manque et rien n’indique un reçu corrompu.

Pourtant, la révision 04 de AER-1: A Portable Execution Receipt for AI Agent Tool Calls, déposée le 29 septembre 2026, conduit à 7c4817ca249edfeae259b98abf63ed38a31d9dbeebf5ee23139410a7a7f63b37 sur les mêmes cinq étapes.

Ce texte est un Internet-Draft individuel à visée Informational. Ce n’est ni un RFC, ni un document adopté par un groupe de travail de l’IETF. Mais son statut provisoire ne change pas la nature de l’écart : deux procédures publiques et reproductibles désignent deux arbres différents.

Le voyant vert n’est donc pas mensonger. Il est grammaticalement incomplet. Il faudrait lire : « vérifié selon quelle construction ? »

Le choix décisif se fait avant le premier nœud

Les deux méthodes utilisent SHA-256. Elles associent les condensats enfants sous forme de 32 octets bruts. Elles dupliquent le dernier élément lorsqu’un niveau est impair. Elles encodent la racine finale en hexadécimal minuscule. La divergence intervient plus tôt : au moment de décider quelles données méritent de devenir une feuille.

La page publique construit chaque entrée avec le numéro de séquence, deux-points, puis l’empreinte de sortie en minuscules. Elle hache donc les octets UTF-8 de seq:receipt_hash.

La révision 04 demande de hacher uniquement les octets UTF-8 de l’identifiant de reçu, receipt_id. Elle explique que la permission antérieure d’utiliser d’autres constructions a été retirée précisément parce que plusieurs racines pour le même flux empêchent la vérification entre implémentations. Après avoir qualifié la construction de recommandée, le texte impose son usage avec un MUST.

On peut défendre intellectuellement les deux modèles. L’un lie directement position et empreinte de sortie. L’autre fait de l’identité stable du reçu l’unité du flux et oblige le vérificateur à résoudre chaque reçu séparément. Mais une qualité de conception ne rend pas les deux modèles interchangeables.

Une racine ne transporte pas la définition de sa feuille. Des mois plus tard, la chaîne hexadécimale ne dira pas si elle s’appuie sur un identifiant, une empreinte, un numéro de séquence ou une sérialisation particulière. Le contrat doit voyager avec elle.

Le dépôt montre une migration inachevée

Le dépôt public, figé au commit f3aacbb5cf7d00977fd107afc34fc24b08c4f569, éclaire la situation. Dans Python, la fonction de Merkle reçoit des receipt_ids et hache chaque identifiant encodé. Rust applique SHA-256 aux octets de l’identifiant. TypeScript fait de même avec l’encodage UTF-8. Ces trois aides suivent la révision 04.

Le JavaScript embarqué dans la page publique suit encore seq:hash. Il ne s’agit pas d’une simple différence de présentation : c’est le matériau même de la feuille.

La primauté du code en fonctionnement ne consiste pas à donner automatiquement raison au site contre le texte. Elle consiste à observer le véritable ensemble de compatibilité. Aujourd’hui, les aides inspectées et le projet occupent un ensemble ; la page publique en occupe un autre. Le document ne migre pas magiquement le passé, et le déploiement ne devient pas magiquement une norme portable.

La discipline proposée par Lu Heng impose ici une règle simple : une spécification commune minimale doit être mince, mais complète sur les invariants. Le choix des octets de feuille est un invariant d’interopérabilité. S’il faut demander après coup à l’opérateur du service « ce que la racine voulait dire », le hachage n’a pas supprimé l’autorité ; il l’a cachée dans une convention locale.

Un score parfait peut rester muet

Le dépôt affiche 43/43 pour sept exécuteurs : Rust, Go, TypeScript, Python, Java, C# et Swift. Ce résultat est réel sur son périmètre. Le fichier d’accompagnement énumère les règles testées : forme du reçu, UUID, dates, base64 strict, UTF-8, engagement de sortie, provenance, profil du producteur, ancrage optionnel et aller-retour des émetteurs.

Les flux de travail ne figurent pas dans cette liste. L’index des vecteurs indique encore la révision -03. Aucun identifiant de vecteur ni aucun groupe ne porte sur un flux, une racine de Merkle, un ordre d’étapes, une duplication impaire ou une définition de feuille.

Les sept exécuteurs peuvent donc obtenir un résultat parfait sans jamais rencontrer la nouveauté introduite en révision 04. Le badge n’est pas faux ; c’est l’extension implicite de sa portée qui serait abusive.

Un vecteur pertinent devrait figer les cinq identifiants, les cinq entrées de feuille, leurs condensats, chaque niveau intermédiaire et la racine finale. La page déployée, l’API et chaque bibliothèque devraient consommer le même dossier. Ainsi, une divergence désignerait immédiatement la règle fautive au lieu de laisser deux valeurs finales s’affronter sans explication.

Six réalités derrière un seul mot

« Vérifié » peut au moins recouvrir six faits différents.

Le premier est l’intégrité de chaque étape : les octets conservés correspondent à leur engagement. Le deuxième est la correspondance avec le manifeste : l’empreinte récupérée est bien celle affichée par le flux. Le troisième est la sémantique de feuille : le vérificateur a choisi les données prescrites par une construction nommée. Le quatrième est la compatibilité de racine : un autre vérificateur appliquant le même profil retrouve la même valeur. Le cinquième est le témoignage externe : un tiers a enregistré une racine donnée à un instant donné. Le sixième est l’effet réel de l’outil.

Le flux étudié donne de solides éléments pour les deux premiers faits et pour sa propre construction des troisième et quatrième. Il publie également un ancrage Nostr au statut partiel. Mais un ancrage témoigne de la valeur qu’on lui remet. Il ne tranche pas la question préalable de savoir quelle valeur aurait dû être calculée.

Et aucune agrégation ne rehausse la provenance. Un appel rapporté par un agent reste un rapport. Une observation de passerelle reste une observation de passerelle. La racine ne transforme pas une interrogation de prix en transaction, un lancement en livraison, ni une trace en autorisation.

L’interface honnête doit donc montrer l’objet vérifié. Une lumière verte sans objet grammatical est un transfert de risque vers le prochain décideur.

Le passeport de la racine

Une racine destinée à circuler entre plateforme, auditeur et système de décision doit être accompagnée d’un profil : versions des schémas, identifiant de construction, encodage exact, fonction de hachage, règle parentale, traitement des niveaux impairs, format de sortie, liste ordonnée des reçus, engagements de chaque étape, provenance, définition des octets de sortie finale, portée de l’ancrage et version du corpus de conformité.

Il faut également enregistrer la version de la politique d’acceptation et la personne ou le service qui a pris la décision. C’est la seule manière de répondre plus tard à la question : qui a accepté quel objet, selon quelle règle ?

Une migration ne doit pas réécrire les reçus historiques. La page publique promet des URL stables. Il faut préserver l’ancienne racine, publier un engagement successeur clairement versionné et, pendant la transition, calculer les deux valeurs avec leurs étiquettes. L’adoption devient alors un fait observable, pas une fiction rétroactive.

Sources et limites

Les observations ont été figées le 30 septembre 2026, heure de Shanghai. Elles établissent un écart reproductible entre la révision 04, un commit public déterminé et la page publique alors active. Elles ne démontrent ni malveillance, ni collision SHA-256, ni compromission, ni échec d’un effet externe, ni adoption large, ni approbation de l’IETF. Seules les aides de flux Python, Rust et TypeScript ont été inspectées. Le projet et le service peuvent évoluer.