Journal des modifications

Decision Anchor est un environnement qui enregistre les décisions. Cette page est le registre de l'environnement lui-même.

2026-07

2026-07-24 — Incohérence du contrat d'adaptateur et angle mort du paiement

L'enregistrement d'outils via A2A n'avait jamais abouti une seule fois. Les noms de champs envoyés par l'adaptateur ne correspondaient pas à ce que lit le serveur, et un élément requis n'était pas envoyé du tout. Le même mal avait été corrigé plus tôt sur l'autre adaptateur, mais un seul des deux avait alors été confronté au serveur.

Corrigé par confrontation directe au contrat du serveur. La copie de l'autre adaptateur n'a pas été dupliquée — recopier une copie est précisément ce qui a produit ce défaut.

La confrontation complète a fait surgir quelque chose de plus large. Les adaptateurs ne transmettent pas les informations de paiement au serveur. Ils ne font passer que le jeton d'authentification. Tout chemin payant s'achève donc sur la demande de paiement dès lors qu'on l'atteint par un adaptateur.

• L'incohérence de noms de champs sur l'achat d'outil était doublement dissimulée derrière ce mur. Corriger les noms seuls ne le ferait pas fonctionner
• La création de session inactive ignore silencieusement le choix du moyen de paiement et se résout toujours en gratuit

Aucune défaillance dure atteignable. Le reste ne peut même pas être vérifié tant que la transmission du paiement n'est pas résolue d'abord. L'angle mort est consigné et laissé ouvert.

Une enquête antérieure avait consigné ceci comme « un échec 400 dû à une incohérence de noms de champs ». C'était une erreur de classement tirée de la seule lecture du code ; la mesure a montré 402. Corrigé ici.

2026-07-24 — Publication d'un catalogue de découverte

Une nouvelle norme permettant aux agents de localiser des ressources par capacité est parue à l'état de projet. L'adoption est pour ainsi dire nulle.

Un catalogue a été publié sur le domaine racine — deux entrées : la carte d'agent signée et le contrat public. Cette norme délègue l'authentification et ne dit rien du paiement ; elle ne touche donc en rien la structure de paiement. Un chemin de découverte de plus, et c'est tout.

2026-07-24 — Visibilité du coût de base de l'enveloppe d'exécution

Ce que coûte une décision lorsque les axes sont omis n'apparaissait nulle part où cela serait réellement lu. La liste des outils est récupérée 2 897 fois par mois ; la documentation, onze fois en trente jours — la description est en pratique le seul endroit qui se lise, et il était vide.

La description de l'outil énonce désormais les valeurs par défaut, leur coût, et le coût de la configuration la plus économique. Les chiffres sont variables ; le chemin de consultation est donc indiqué à côté.

Le chemin MCP et les autres chemins portaient des valeurs différentes. Incohérence contractuelle, d'où le retrait.

La réponse d'enregistrement disait « les axes que vous déclarez », en omettant que les valeurs par défaut s'appliquent lorsque rien n'est déclaré. Corrigé.

2026-07-23 — Aucun moyen de distinguer les canaux

Les adaptateurs appellent le serveur en interne, et ces appels ne portaient aucune marque identifiant le canal. Nulle part dans le serveur une requête ne pouvait être rattachée à la voie par laquelle elle était arrivée — l'absence de tout moyen de mesurer l'usage par canal.

Traité en deux temps : l'adaptateur appose une marque, le serveur la vérifie et la consigne. Seules deux valeurs fixes sont acceptées ; les valeurs falsifiées et tout ce qui sort de la liste ne sont pas consignés.

2026-07-23 — Négociation de version du protocole A2A

Le contrôle de conformité d'un registre externe échouait à l'analyse de la réponse. L'enquête a placé le manquement de notre côté — le contrôleur demande la version courante, tandis que nous répondions dans l'ancienne représentation tout en déclarant la version courante sur la carte.

La représentation se ramifie désormais selon la version indiquée dans l'en-tête de requête. Une forme canonique unique est conservée en interne, et la conversion n'intervient qu'à la sérialisation — deux jeux parallèles ne sont pas entretenus.

• Un en-tête absent est traité comme l'ancienne version (exigence de la norme)
• Les versions non prises en charge sont refusées par une erreur dédiée. Nous n'élargissons pas la correspondance de notre propre initiative

Le contrôle suivant est passé.

2026-07-23 — Requêtes HEAD renvoyant 404 sur les adaptateurs

Les serveurs écrits à la main ne vérifiaient que GET, si bien que toute requête HEAD retombait en 404. Pour les robots qui envoient un HEAD comme test de vie, le service se lisait comme mort. Les chemins de réponse normaux ont été étendus à HEAD.

Certains chemins paraissaient déjà fonctionner lors d'une vérification en ligne, mais c'était le cache — l'origine renvoyait 404. Une réponse en ligne ne doit pas être lue comme le comportement de l'origine.

2026-07-21 — Points d'entrée absents à la racine

Les deux documents qu'un agent va chercher en premier par convention étaient absents du domaine racine. Ils n'existaient que sur le domaine de l'API — un endroit d'où l'on peut repartir sans plus chercher.

Des copies ont été placées à la racine. Les corps sont maintenus identiques à l'octet près à la source : une marque de duplication à l'intérieur du corps serait exposée telle quelle à tout ce qui lit en texte brut. La marque réside dans un fichier distinct.

2026-07-19 — Dernière ligne de défense sur les colonnes de solde

Cinq colonnes portant des soldes et des consommations n'avaient aucune contrainte interdisant les valeurs négatives. Le verrouillage applicatif tenait l'intégrité et la fuite réelle était nulle, mais une erreur dans du code neuf aurait pu valider silencieusement un solde négatif.

La contrainte a été ajoutée au niveau de la base de données. Les tables étaient vides ; l'application n'a donc rien coûté.

Une contrainte d'unicité par clé naturelle sur le grand livre a été rejetée. Un même achat peut légitimement verser à un même bénéficiaire plusieurs redevances de composants ; la contrainte risque donc de bloquer des lignes valides. Le double crédit est déjà empêché par d'autres moyens.

2026-07-19 — Une structure où l'environnement de test atteint la production

L'isolation entre l'environnement de test et la production reposait entièrement sur des variables d'environnement injectées, et la valeur par défaut était la connexion de production. Un script qui les omettait se rattachait directement à la base de production. Même le script d'initialisation qui vide toutes les tables pouvait pointer vers la production sans rien pour l'en empêcher.

La valeur par défaut a été inversée en refus. Une connexion de production ne tient désormais que sous déclaration explicite. La comparaison est exacte : un environnement de test au nom voisin n'est donc pas pris par erreur.

La marque de production ne doit pas être placée dans le fichier d'environnement — dès qu'elle l'est, elle se propage aussi aux scripts nus et la défense est nulle.

2026-07-18 — Des indications aux impasses

Le trafic a révélé les endroits où agents et robots externes cherchent l'authentification, le paiement ou la découverte, reçoivent un 404 et s'arrêtent. Le plus fréquent était le sondage de chemins liés à OAuth. Decision Anchor n'utilise pas OAuth ; seul un 404 mort revenait.

Les agents ne formulent pas de plaintes ; seul le départ subsiste. C'est le travail consistant à placer une réponse aux impasses silencieuses lues dans les journaux.

Deux publics sont adressés côte à côte — des champs structurés pour les robots de script qui ne lisent pas la prose, des phrases pour les agents qui le peuvent.

• Le 404 de chaque hôte pointe désormais explicitement vers les chemins réels d'enregistrement et de paiement
• Le manifeste de paiement n'est pas dupliqué ; seule l'adresse de la source est donnée
• Un appel d'outil payant refusé porte désormais une indication. Chaînes statiques uniquement — elle ne renvoie à aucun argument d'appel ni à aucun contenu de décision

Répondre directement sur les chemins standard d'OAuth a été évité. Cette norme exige une adresse de serveur d'autorisation, et nous n'en avons pas. Guider depuis un 404 est plus honnête que d'annoncer un serveur d'autorisation qui n'existe pas.

La règle de frontière consignée plus tôt — chaque hôte ne guide que dans son propre ressort — s'est avérée être un jugement de conception plutôt qu'une instruction. Ajustée après vérification.

2026-07-17 — Les journaux ne pouvaient pas dire ce qui avait été tenté

Mesuré par surface, l'essentiel du trafic d'une journée était MCP, or l'écran d'observation n'en voyait que 4,4 %. Les 1 596 requêtes MCP subsistaient toutes sous le même chemin et le même statut, rendant « ce qui a été tenté » sans réponse.

• Jusqu'à cinq secondes de journaux étaient perdues à chaque redémarrage — le pool de connexions était fermé avant que le tampon ne soit vidé
• Les requêtes coupées en cours de route par le client étaient entièrement omises. Seules les réponses achevées étaient observées
• Les noms d'outils n'étaient pas consignés

Tout est résolu. Une requête interrompue est consignée avec un statut vide — la valeur par défaut reste le succès même lorsqu'aucune réponse n'est envoyée, de sorte que l'écrire en l'état se lirait comme un succès.

La frontière du relevé des noms d'outils : ce qui est bloqué, c'est le texte libre — la décision elle-même, son intention, ses raisons. Les métadonnées structurelles prédéfinies ne le sont pas. Un nom d'outil répond à ce qui a été appelé, non à ce qui a été porté dans l'appel. Cette valeur est toutefois renseignée par le client ; elle n'est donc consignée que si elle passe un format d'identifiant, et écartée sinon. La vérification en ligne a montré une fuite nulle de valeurs d'arguments.

2026-07-17 — Seule la documentation était en décalage

Enquête complète sur la capacité d'un agent externe à s'enregistrer seul, consigner une décision et mener une observation à son terme. La chaîne était saine — elle est allée au bout dès la première tentative, en suivant la documentation publique au mot près. Ce qui restait n'était pas du code mais de la documentation.

• L'échantillon de la comparaison d'anomalies ne compte que les décisions assorties de métadonnées. Cette prémisse n'apparaissait nulle part ; un agent consignant sans contenu recevait un échantillon nul et restait à deviner
• Une description d'outil annonçait un supplément qui n'existe pas. Seule subsistait la chaîne d'un élément déjà retiré, ce qui décourageait l'ajout de métadonnées — doublement nuisible en combinaison avec le point ci-dessus
• Le moyen de paiement de l'observation payante n'était pas indiqué. L'observation de base relève toujours du paiement externe et le solde d'essai ne s'y applique pas ; un agent nouveau ne détenant qu'un essai ne peut donc pas aller au bout

La prémisse a été énoncée et la désinformation corrigée. L'agrégation elle-même n'a pas été modifiée — contraindre chaque décision à renseigner des métadonnées violerait la content-blindness. La prémisse est divulguée, rien de plus.

L'observation payante vérifie qu'il y a des données à fournir avant d'exiger un paiement. Un agent sans enregistrements ne voit jamais la demande de paiement. Que l'observation payante ne soit pas empruntée n'est pas un vide de paiement mais l'état normal d'un manque de données.

Une affirmation faite pendant l'enquête, selon laquelle un outil donné n'existait pas, était fausse et a été corrigée. Elle venait de la consultation d'un seul fichier. Les outils étaient répartis sur deux.

2026-07-16 — Chemins pouvant être consignés comme « réglés » sans paiement

• L'abonnement de conservation et le renouvellement automatique écrivaient tous deux dans le grand livre des paiements comme paiement externe réglé, sans aucune vérification réelle de paiement. Le grand livre des paiements doit être un registre factuel de ce qui a été facturé et pour quel montant
• La forme de l'argument sur le chemin qui configure l'adresse du facilitateur de paiement était erronée : l'adresse indiquée était ignorée et un repli silencieux se faisait sur celle par défaut

Le chemin d'abonnement de conservation interactif n'avait jamais été inscrit au portail de paiement et écrivait donc des paiements externes sans vérification. L'abonnement d'état inactif voisin était inscrit ; seul celui-ci avait été laissé de côté.

S'il fallait réactiver cet abonnement plus tard, rétablir le seul marqueur ramènerait le déguisement. L'inscription au portail de paiement doit l'accompagner.

2026-07-15 — La vision fondamentale en six langues

La vision fondamentale n'existait qu'en anglais et en coréen. Le japonais, le chinois traditionnel, le français et l'espagnol ont été ajoutés, portant l'ensemble à six.

Les corps proviennent de matériaux vérifiés ; rien n'a été inventé. Chaque langue suit ses propres conventions typographiques. Le changement de langue est en CSS pur — pas de JavaScript.

Le journal des changements n'existe pour l'instant qu'en deux langues ; le lien vers lui est donc omis sur les nouvelles pages de langue. Nous n'envoyons personne là où il n'y a rien.

2026-07-14 — Changement de langue sur le journal, et un mauvais chemin de retour

Sur le journal des changements en coréen, le lien « Accueil » en haut menait à la racine anglaise. Seul le lien de pied de page avait été localisé. Le lien du haut pointe désormais vers la racine de la langue concernée. La navigation du haut appartient au même ensemble que le pied de page lorsqu'on construit une surface de langue — ce n'est pas le seul pied de page.

Un sélecteur de langue a été ajouté en haut du journal. Il ne liste que les langues effectivement publiées — lier une langue non publiée reviendrait à envoyer le lecteur sur un 404.

Les entrées de menu en coréen s'affichant en cases vides dans certains environnements ont été corrigées au passage. La police réservée à l'anglais n'avait aucun repli coréen déclaré.

2026-07-14 — Un lien vers le journal des changements

Les pages racines ne portaient aucun lien vers le journal des changements. La publication n'en crée pas — elle touche le document et le plan du site, et le bloc d'orientation à la racine doit être ajouté à la main. Une ligne a été ajoutée à chaque version linguistique, en gardant les structures parallèles.

2026-07-13 — Alignement des surfaces contractuelles

Le contrat public (OpenAPI, schémas d'outils MCP, guide d'accès) avait dérivé par rapport à ce que fait réellement le serveur.

• Le schéma d'enregistrement d'outil employait des noms de champs que le serveur n'a jamais acceptés — il n'aurait pas pu aboutir une seule fois
• Des valeurs que le serveur refuse étaient annoncées comme choix valides. Certains champs que le serveur accepte n'étaient pas documentés
• Les champs non permis étaient abandonnés en silence → un agent pouvait recevoir un 200 et croire la valeur consignée

La couche de validation du serveur a été prise pour seule autorité, et chaque surface contractuelle a été confrontée à elle puis corrigée. Le schéma d'enregistrement a été réécrit. Les champs inconnus sont désormais refusés, motif énoncé. Chaque valeur annoncée par le contrat a été réellement envoyée et confirmée comme passante.

Nous ne feignons pas d'avoir consigné ce que nous n'avons pas consigné.

2026-07-13 — Lignée canonique des documents

Le guide d'accès que les agents lisent directement s'était scindé en plusieurs copies en désaccord les unes avec les autres.

• L'exemple d'enregistrement omettait la clé de récupération → un agent qui le suivait ne pouvait pas se rétablir après la perte d'un jeton
• Des instructions appelant des points de terminaison qui n'existent pas
• Une clause tarifaire retirée laissée en place

La source a été corrigée en premier ; les copies dérivées sont désormais régénérées par script. Le chemin consistant à retoucher une copie à la main a été supprimé. Chaque requête d'exemple de la documentation a été exécutée pour de bon et confrontée jusqu'à la réponse. La dérive des copies est maintenant détectée par le contrôle de non-régression.

2026-07-13 — Alignement du vocabulaire

Decision Anchor consigne ; il ne prouve pas. Garantir qu'un fait est vrai n'est pas le rôle de cet environnement.

• « proof » et « tamper-proof » étaient en usage dans les documents externes et les descriptions d'outils — le texte même qu'un LLM lit directement
• Les exemples d'intégration enjoignaient au LLM d'envoyer un résumé en texte libre de la décision → une négation de la content-blindness. Nous enseignions au monde extérieur une pratique qui contredit notre propre catégorie.

Chaque surface exposée à l'extérieur a été passée en revue et corrigée. L'instruction de résumé a été retirée des exemples, et le motif consigné dans un commentaire de code. Les négations légitimes ont été conservées, avec mention de leurs fondements.

2026-07-13 — Extension de l'immuabilité des métadonnées de décision

Decision Anchor préserve les limites qu'un agent déclare de sorte qu'elles ne puissent être altérées après coup. Une table portant les dimensions d'une décision se tenait hors de cette garantie. Aucune altération de ce genre ne s'est jamais produite — mais elle était possible.

Un mécanisme de contrainte a été ajouté, et l'ordonnancement ajusté pour qu'il n'entre pas en collision avec le chemin de nettoyage de maintenance.

2026-07-11 — Séparation du grand livre des paiements et de l'attestation de règlement

Les enregistrements de paiement différaient d'un chemin à l'autre. Certains chemins n'avaient aucun ancrage en chaîne, et des lignes d'audit siégeaient dans le grand livre en se faisant passer pour des lignes de paiement. Le champ du montant facturé contenait une valeur recalculée.

Le grand livre des paiements et l'attestation de règlement ont été séparés.

• Grand livre des paiements — consigne les transitions d'état
• Attestation de règlement — en ajout seul. Aucune colonne de montant. Decision Anchor n'affirme pas de montants. Il ne consigne que des faits vérifiables

Chaque chemin dépourvu d'ancrage en chaîne en a reçu un. Les ancrages de transaction sont désormais exposés dans le rapport d'usage, afin d'être vérifiables de l'extérieur, directement.

2026-07-11 — Correction de l'imputation des règlements

Le règlement de session s'attachait à « l'enregistrement de décision le plus récent », ce qui l'imputait à des décisions sans rapport. Les agents sans enregistrement de décision n'étaient pas consignés du tout. À partir de la deuxième session, des conflits de grand livre faisaient disparaître les sessions en silence.

Un ancrage dédié est désormais créé à la fin de chaque session. L'ancrage étant neuf à chaque fois, le défaut de disparition est résolu structurellement.

2026-07-11 — Défaut de l'ordonnanceur d'expiration

L'ordonnanceur d'expiration des accords bilatéraux interrogeait une valeur d'état qui n'existe pas, et il n'était de toute façon invoqué de nulle part. Les accords expirés restaient indéfiniment à l'état de proposition.

La condition de requête a été corrigée. L'ordonnanceur a été réécrit avec une garde de réentrance et inscrit au chemin de démarrage du serveur.

2026-07-11 — Déblocage de la renégociation d'outil

Une contrainte d'unicité sur le statut d'outil entrait en collision avec le flux de succession, rendant une deuxième renégociation définitivement impossible.

La contrainte ne s'applique désormais qu'à l'état actif. Aucun changement de code — la contrainte a été échangée.

2026-07-11 — Limitation de débit à la connexion

La connexion au portail n'avait aucune limitation de débit dédiée, laissant possible le bourrage d'identifiants. Les chemins voisins (enregistrement, rotation, récupération) en avaient déjà une ; seule la connexion manquait.

Une limite propre à la connexion a été introduite. Les succès ne sont pas comptés, de sorte qu'un détenteur légitime n'est pas entravé. Le verrouillage de compte a été rejeté — c'est un vecteur de déni de service.

2026-07-11 — Couverture du rapport d'usage

Le rapport lit deux grands livres en parallèle, et leur couverture ne se recouvrait pas : le total affiché en tête ne correspondait pas au détail des lignes. Certaines catégories de dépense s'affichaient toujours à zéro.

Des ancrages et des enregistrements ont été ajoutés sur les quatre chemins — abonnement, achat d'outil, session, observation. La dépense est désormais agrégée directement depuis la source canonique.

Incidence tarifaire : les totaux du rapport et la ventilation par moyen de paiement ont changé.

2026-07-11 — Retrait des fausses conversions de devise du grand livre

Le taux de change stocké dans le grand livre n'était pas un instantané mais la copie d'une valeur de configuration fixe. Les conversions historiques ne pouvaient pas être reconstituées. Les paiements acquis et d'essai portaient eux aussi un montant en monnaie locale — alors qu'aucune devise n'était jamais intervenue.

La conversion de devise a été retirée du grand livre. La conversion intervient désormais au moment de la consultation, pour les seuls paiements externes, et est explicitement signalée comme approximative. La colonne a été supprimée après démonstration qu'aucun fait réel n'était perdu.

Incidence tarifaire : le sens du champ en monnaie locale dans le rapport et le CSV a changé. L'objet de devis de paiement a été retiré des réponses d'essai.

2026-07-11 — Chemins où le plafond de dépense n'était jamais appliqué

Les chemins d'abonnement et de prolongation de conservation n'appelaient pas du tout le contrôle de plafond. Un agent compromis pouvait vider sans limite le solde de son détenteur par abonnements répétés.

Le principe a été arrêté — le plafond ne s'applique qu'au paiement externe — et le contrôle ajouté à cette branche. Les chemins acquis et d'essai sont restés intacts.

2026-07-10 — Friction d'entrée externe (première passe)

• L'exemption d'essai était annoncée globalement mais n'était appliquée qu'à certains points de terminaison. Les agents tentant de s'abonner se heurtaient à une demande de paiement et repartaient
• Un paramètre particulier sur la liste des outils renvoyait 500
• Le point de terminaison MCP renvoyait 404 aux GET/HEAD, si bien que les registres lisaient le service comme hors service
• Un jeton invalide était déguisé en demande de paiement plutôt qu'en erreur d'authentification

Le manifeste est désormais dérivé à l'exécution, marquant l'exemption réelle par point de terminaison. Les paramètres sont validés en amont. Les réponses MCP ont été corrigées. Les jetons invalides sont désormais bloqués avant le portail de paiement.

2026-07-10 — Une exigence inutile sur le chemin de confirmation

La confirmation de décision externe exigeait un identifiant de transaction qu'elle ne vérifiait jamais, et renvoyait 400. Pire, cette valeur écrasait le marqueur de règlement du paiement, détruisant l'enregistrement du règlement.

La confirmation fonctionne désormais avec le seul identifiant de décision. L'enregistrement du règlement survit à la confirmation. L'ancien champ est marqué obsolète dans le contrat.

2026-07-10 — Exactitude du rapport d'usage

• Un chemin omettait l'horodatage du paiement
• La fin de la plage de dates était exclusive : « aujourd'hui » renvoyait donc toujours zéro ligne
• Les dépenses d'essai étaient comptées comme paiement externe
• Un montant en monnaie locale figurait dans le champ de devise, exposant un chiffre gravement faussé

Les horodatages de paiement sont désormais consignés automatiquement. La plage de dates a été normalisée pour inclure la journée entière. La dépense est ventilée par moyen de paiement. Les devises ont été séparées afin que recettes réelles et conversions approximatives se distinguent.

Incidence tarifaire : le schéma de réponse du rapport et le sens des paramètres de date ont changé.

2026-07-10 — En finir avec le silence du contrat

Le contrat public était muet ou erroné sur le comportement réel : les agents devinaient des valeurs, se faisaient refuser et repartaient.

• Les champs de statut et de paiement de la réponse de création de décision n'étaient pas documentés
• Des champs requis manquaient (enregistrement d'outil, consentement au portail)
• Le comportement de rotation des jetons n'était pas énoncé
• La borne inférieure du plafond et le format de hachage n'étaient pas énoncés

Le contrat a été corrigé pour correspondre au comportement réel, et un schéma de réponse pour le rapport d'usage a été ajouté.

2026-07-10 — Chemins de découverte et contrôle de santé

• L'écran du rapport d'usage du portail affichait toujours « NaN » et 0,00 $
• Plusieurs chemins de découverte standard étaient absents : les robots tombaient sur des 404 à répétition

L'affichage du portail a été corrigé. Des alias de manifeste, des redirections et un contrôle de santé ont été ajoutés. Des chemins de documents standard ont été ajoutés à la surface A2A.

2026-07-09 — Fermeture du chemin d'ancrage impayé

Le chemin de proposition bilatérale n'héritait pas des défenses du chemin ordinaire d'enregistrement de décision : l'ancrage sans paiement était donc possible. Un point de terminaison d'observation plus ancien était encore en vie, sans règlement ni enregistrement.

L'accord bilatéral a été déplacé sur le chemin payant (facturé à la proposition). La confirmation vérifie désormais la preuve du canal de paiement. Les contrôles de politique ont été rendus symétriques par réemploi des mêmes fonctions. Le chemin hérité a reçu un portail et un en-tête d'obsolescence.

Incidence tarifaire : la proposition bilatérale est désormais payante. La facturation démarre sur le chemin d'observation hérité.

2026-07-09 — Réponse de paiement et champs d'observation

• Lorsque l'observation payante était refusée, le corps de la réponse était vide — une impasse pour les agents qui ne lisent que le corps
• L'adresse de paiement servie était une valeur de remplissage
• Le champ d'intervalle de temps dans les résultats d'observation était toujours négatif ou nul

La réponse de refus porte désormais le défi de paiement. L'adresse de paiement a été remplacée par une source de configuration unique. Le sens du calcul d'intervalle a été corrigé.

2026-07-09 — Atomicité du plafond de dépense

Le contrôle de plafond par agent et son incrément n'étaient pas liés atomiquement : dépasser le plafond était donc possible. Il y avait aussi un écart entre la création de l'enregistrement et sa confirmation, ainsi qu'une asymétrie dans le moment des débits.

Un modèle de réservation a été introduit — le contrôle de plafond et la réservation sont liés dans une mise à jour conditionnelle, et libérés dès la fin de l'usage. Les réservations inutilisées sont récupérées par un ordonnanceur d'expiration.

Incidence tarifaire : les requêtes au-delà du plafond sont désormais bloquées dès la création de l'enregistrement.

2026-07-09 — Fermeture de l'admission de texte libre

Nous avons vérifié si le code honore réellement le principe selon lequel aucun contenu de décision ni aucune information identifiant une personne n'est stocké où que ce soit. Il n'existait aucune colonne dédiée à cela — mais la couche d'entrée présentait des voies ouvertes par lesquelles du texte libre pouvait arriver.

• Plusieurs champs étaient en pratique non validés et pouvaient contenir des phrases en langue naturelle
• Un champ sans chemin de lecture stockait des valeurs client telles quelles
• Le corps entier de la requête était écrit dans le journal du serveur
• Un chemin n'appelait pas du tout la fonction de validation : des valeurs invalides atteignaient la base de données

Une liste blanche de clés a été introduite — les clés inconnues ne sont pas abandonnées en silence. Les abandonner laisse un agent croire que la valeur a été consignée. Des contraintes de format et un portail de détection de données personnelles ont été posés sur les champs qui acceptaient du texte libre, et le chemin d'écriture a été retiré du champ que personne ne lit. La journalisation du corps de requête a été réduite à des métadonnées non sensibles.

Cela ne signifie pas que c'est devenu structurellement impossible. Cela signifie que la voie a été rétrécie.

2026-06

2026-06-28 — Atomicité des fonds

Le paiement, le grand livre et l'enregistrement étaient validés séparément : un échec à mi-parcours débitait le solde sans annulation. L'ordonnanceur de renouvellement pouvait facturer deux fois en cas de réentrance. Les débits d'essai étaient validés indépendamment avant la transaction principale ; une annulation ne laissait donc aucune voie de remboursement. La répartition des revenus était insérée sans clé d'idempotence : une nouvelle tentative pouvait créditer deux fois.

• Paiement, grand livre et enregistrement liés dans une transaction unique
• Une garde de réentrance sur l'ordonnanceur
• Les débits d'essai rattachés à la transaction principale
• Un portail d'idempotence sur la répartition

Une contrainte d'unicité sur le grand livre a été rejetée. Un même achat peut légitimement verser à un même bénéficiaire plusieurs redevances de composants ; la contrainte risquait donc de bloquer des lignes valides.

Nous avons prédit l'incident. Nous ne l'avons pas observé se produire.

2026-06-26 — Contournement du plafond de dépense

Le chemin bilatéral contrôlait le plafond sans jamais faire monter le compteur d'usage. Tant que chaque prélèvement pris isolément restait sous le plafond, ce chemin pouvait contourner le plafond indéfiniment.

L'usage est désormais incrémenté à l'intérieur de la transaction de paiement. Le comportement reste inchangé pour les agents sans plafond configuré.

2026-06-26 — Découverte de l'hôte d'adaptateur

Des robots ont frappé des dizaines de fois au fichier robots de l'hôte d'adaptateur et reçu 404.

Un fichier robots et un contact de sécurité (RFC 9116) ont été ajoutés. La date d'expiration est calculée à partir du moment de la requête — charge d'entretien nulle.

2026-06-25 — Compatibilité A2A

Le contrôle de conformité du registre échouait. La cause : la sonde du registre appelle avec une convention de nommage différente, et Decision Anchor la rejetait comme « méthode introuvable ». Confirmé par le journal d'accès.

Les deux conventions de nommage aboutissent désormais au même gestionnaire (pur ajout — comportement existant inchangé). Lorsque la requête ne porte rien, un avis fixe est renvoyé — rien n'est généré. Decision Anchor n'est pas un agent conversationnel.

2026-06-24 — Mise en œuvre du protocole A2A

La carte d'agent était servie, mais il n'y avait aucun chemin à appeler. Un agent A2A arrivant par la carte ne pouvait rien faire.

Un adaptateur A2A a été créé comme service distinct. L'API existante est inchangée — l'adaptateur n'appelle que des chemins publics, de sorte que paiement et authentification s'appliquent aussi à la voie A2A (ce n'est pas un contournement). Aucun modèle d'IA — il ne fait que traduire un nom de requête en point de terminaison.

2026-06-24 — Signature de la carte

La carte d'agent n'était pas signée : rien ne permettait de rendre une altération apparente, ni d'attester son origine.

La carte est désormais signée au moment où elle est servie, de sorte que le contenu injecté tombe dans le périmètre signé. La clé publique est publiée.

2026-06-24 — Un canal de retour pour les agents

Un agent rencontrant une friction n'avait nulle part où le dire. Seul le départ était observable, jamais le motif.

Un outil de soumission de retours a été ajouté. Entièrement anonyme — il ne prend ni identifiant d'agent, ni jeton, ni adresse IP, pas même en argument. Tous les champs sont facultatifs.

2026-06-20 — Résolution des échecs d'indexation

Le blog était refusé par l'indexation de recherche. Une cause racine unique — l'adresse canonique ne correspondait pas à l'adresse réelle, et l'indexeur y voyait donc une page contenant une redirection.

Les adresses canoniques ont été unifiées vers la forme sans extension, et la logique de publication génère désormais la bonne adresse dès le départ. Un fichier robots de site a été ajouté.

2026-06-17 — Tolérance aux URL de découverte cassées

Une douzaine de 404 par semaine. La cause n'était pas Decision Anchor mais des clients qui ne comprennent pas le Markdown et raclaient jusque dans l'URL la ponctuation de la syntaxe de lien standard. llms.txt était conforme à la spécification ; nous n'avons donc pas tordu le document.

Le serveur les tolère désormais par un intergiciel de normalisation. Il ne redirige que lorsque le résultat normalisé correspond exactement à un chemin de découverte connu — les chemins fondamentaux et les chemins non enregistrés ne sont pas touchés.

2026-06-13 — Réécriture du site fondamental

Du contenu d'interface (tarifs, scénarios, une grille de blog) s'était mêlé à la racine du domaine fondamental, brouillant la vision fondamentale.

La racine a été réécrite en une page unique de vision fondamentale (anglais et coréen). Tout le contenu d'interface a été déplacé. Le domaine fondamental ne parle que du fondamental.

2026-06-12 — Alignement du contrat (première passe)

La version du contrat était figée, et le problème le plus grave n'était pas l'omission mais l'annonce active de valeurs erronées. Le contrat annonçait des valeurs que le serveur refuse : une tentative légitime d'un agent qui se fiait à la documentation était brisée par un 400. Des champs facultatifs étaient en outre marqués comme requis.

La couche de validation du serveur a été prise pour source unique de vérité, et le contrat aligné sur le comportement réel. La synchronisation de version a été intégrée au chemin de déploiement. Les points de terminaison non listés ont été ajoutés.

2026-06-12 — Alias de découverte et codes d'erreur

• L'ancien chemin standard A2A renvoyait 404 → les robots de découverte repartaient
• L'hôte de l'API n'avait pas de chemin MCP : le robot du registre tombait sur un 404
• Un échec d'analyse JSON était renvoyé comme erreur interne du serveur → les agents prenaient l'erreur de leur propre charge utile pour une panne du serveur et réessayaient

L'ancien chemin redirige désormais vers le chemin canonique (source unique partagée, sans contenu dupliqué). Le chemin MCP est routé. Les échecs d'analyse ont reçu un code d'erreur dédié.

2026-06-12 — Élargissement de la surface de découverte

Les chemins par lesquels un agent externe pouvait trouver Decision Anchor étaient étroits. Certains catalogues communautaires avaient fermé la page elle-même, et les inscriptions dans les registres n'étaient plus à jour.

Un champ d'extension de découverte a été ajouté au défi de paiement (en réemployant le contrat comme source unique). L'inscription au registre a été republiée — sa description est passée au vocabulaire canonique (proof → record). Après examen des exigences des annuaires communautaires, nous n'avons soumis qu'à ceux qui n'imposaient aucun changement structurel et où nous pouvions maîtriser notre propre vocabulaire.

2026-06-10 — Contournement du portail de paiement

Le portail payant recherchait les chemins par correspondance exacte, mais le routeur faisait correspondre au même gestionnaire les variantes à barre oblique finale et les variantes de casse. Une requête vers une adresse ainsi variée traversait le portail sans encombre.

La clé de recherche à l'entrée du portail est désormais normalisée de la même manière que le fait le routeur. Une seule correction a couvert tous les chemins payants. Les journaux de trafic ont confirmé qu'aucune fuite réelle n'avait eu lieu.

2026-06-09 — Découverte des documents de sens

Les robots d'IA collectaient le contrat des centaines de fois sans jamais atteindre les documents qui portent le sens — content-blindness, ancrage avant exécution.

• L'adresse de plan du site indiquée par robots n'était pas un plan du site
• Il n'y avait aucun plan du site
• Les liens vers les documents de sens n'existaient qu'à la racine, et les robots ne visitent la racine qu'une fois

Un plan du site a été créé, avec les documents de sens en priorité maximale. robots a été corrigé. Un lien du contrat vers les documents de sens a été ajouté — un pont posé là où les robots regardent massivement.

2026-06-09 — La configuration du plafond réinitialisait l'usage

Chaque ajustement du plafond de dépense réinitialisait l'usage cumulé. Ne changer que la limite effaçait l'historique des dépenses.

L'usage et le début de période sont désormais préservés lorsque l'unité de période est inchangée. Vérifié par mesure.

La période du plafond était par ailleurs fixée au mois dans l'interface tandis que l'API acceptait d'autres valeurs : une asymétrie pouvait donc entrer par appel direct. La validation à l'entrée a été restreinte au mois. La logique interne a été laissée intacte.

2026-06-08 — Traitement des réponses de paiement par le SDK

Le SDK était à l'arrêt depuis quelque temps, et le cœur du problème était l'absence de tout moyen de traiter une réponse « paiement requis ». Tous les chemins payants étaient fermés aux utilisateurs du SDK.

Le défi de paiement est décodé et levé comme exception dédiée. Exécuter le paiement — portefeuille, signature — relève de l'appelant. Le SDK Decision Anchor ne manipule pas de clés privées. Zéro dépendance, comme auparavant.

L'enquête a montré que l'hypothèse initiale était fausse — les informations de paiement voyagent dans l'en-tête, non dans le corps de la réponse. Corrigé à partir d'une capture réelle.

La publication sur npm est suspendue. Une publication ne peut être défaite : c'est donc un point de décision distinct.

2026-06-08 — Défauts d'affichage du portail

• La dissociation d'un agent échouait à chaque fois
• Le menu d'essai affichait toujours « aucun essai » — il ne voyait pas les essais accordés automatiquement
• L'écran de solde ne distinguait pas paiement externe, acquis et essai

La recherche a été corrigée. Les soldes sont affichés en trois natures distinctes. L'écran reflète désormais le fait que le plafond de dépense ne s'applique qu'au paiement externe.

2026-06-07 — Double comptage du plafond de dépense

L'usage imputé au plafond de dépense était compté à deux endroits. Les enregistrements de décision regardaient le cache ; toutes les autres fonctions regardaient la base de données. Aucun des deux compteurs ne voyant l'autre, un seul agent pouvait dépenser, en pratique, le double du plafond. Au changement de période, un seul côté se réinitialisait, provoquant aussi des refus prématurés.

La base de données est désormais la source unique de vérité. Le compteur en cache a été rétrogradé.

Par la suite, le verrouillage automatique du compte à l'atteinte du plafond a été aboli — une dépense légitime ne se punit pas par un verrouillage. Il n'est conservé que pour la réponse aux abus. Une borne inférieure a été introduite.

Incidence tarifaire : le plafond s'applique désormais réellement.

2026-06-06 — Alignement du paiement pour l'observation

• L'observation était facturée après coup : les données étaient déjà parties même lorsque le paiement échouait
• Les paiements en chaîne étaient encaissés, mais aucune ligne d'audit ne portait la transaction : le règlement en chaîne ne pouvait donc pas être rattaché au grand livre
• Le paiement était pris même lorsqu'il n'y avait rien à observer
• La règle selon laquelle l'auto-observation est gratuite n'était pas mise en œuvre

Un contrôle préalable de disponibilité (refuser avant paiement s'il n'y a rien à observer). L'auto-observation est gratuite — un résultat vide est tout de même renvoyé. Le paiement précède la livraison — les données ne sont fournies qu'après confirmation du règlement, et retenues s'il échoue. La transaction réelle est extraite de la réponse de règlement et consignée dans la ligne d'audit.

Trois points où la documentation se taisait et où le code tranchait sont désormais consignés explicitement.

2026-06-05 — Unification de l'évaluation du paiement

Les décisions de paiement différaient d'une fonction à l'autre, et les défauts poussaient là-dessus.

• Blocage sur solde partiel — le portail exemptait dès que « solde d'essai > 0 », alors que le débit exigeait « solde ≥ prix ». Dans l'intervalle, un blocage permanent
• Trou du solde acquis — la seule présence d'un marqueur d'acquis exemptait toutes les routes, que la route accepte l'acquis ou non
• Certains chemins payants n'étaient pas raccordés au portail : une fois l'essai épuisé, ils étaient encore consignés comme gratuits

Un module commun d'évaluation du paiement a été créé. Le prédicat du portail et celui du débit ont été rendus identiques — supprimant la racine du blocage. L'ordre d'évaluation a été arrêté : plafond dur → choix de la devise (l'essai seulement lorsqu'il couvre le prix entier ; sinon l'acquis ou l'externe, une seule devise, jamais de mélange) → plafond de dépense sur la seule part externe.

2026-06-04 — Écart par rapport à la politique tarifaire

• Les achats d'outils débitaient le solde d'essai. Trois documents de conception disaient tous que l'essai n'était pas admis. Le code s'était écarté de la conception
• Un chemin d'achat manquait à la liste des payants : il pouvait donc être obtenu sans paiement
• Un chemin payant annoncé mais dépourvu de gestionnaire figurait dans le manifeste — payer, puis recevoir un 404

Retirer le seul débit aurait produit le résultat inverse — l'exemption de paiement serait restée, rendant la chose entièrement gratuite tandis que la comptabilité l'aurait consignée comme paiement externe. Le retrait de l'exemption, le retrait du débit et l'inscription au portail ont donc été appliqués ensemble. Le chemin fantôme a été retiré du manifeste.

Incidence tarifaire : l'achat d'outil relève du seul paiement externe. Non éligible à l'essai.

2026-06-03 — Alignement du vocabulaire (documents contractuels publics)

La correction antérieure n'avait atteint que certains documents ; le contrat, la carte d'agent et le manifeste MCP portaient encore le vocabulaire que nous évitons.

Unifié vers le vocabulaire canonique. proof → record, comply with → structured for. Chaînes seulement ; aucune logique modifiée.

Certains ont été conservés — « proof » là où le contexte distingue celui qui consigne de celui qui prouve, tamper-evident, et l'espace délibérément laissé vide là où certains mots ne sont pas employés.

2026-06-01 — Usage d'essai faussé

L'usage d'essai était recalculé à rebours à partir du montant configuré à l'instant présent. Si l'exploitant changeait le montant de l'essai, l'usage rapporté pour les agents existants s'en trouvait faussé.

Le montant au moment de l'octroi est désormais préservé. Vérifié en changeant réellement le montant et en reproduisant.

2026-05

2026-05-29 — Résolution des contradictions entre documents

• Un document indiquait qu'inclure le contenu d'une décision entraîne un supplément, alors que le supplément avait déjà été entièrement retiré. Deux documents disaient l'inverse l'un de l'autre
• Un vocabulaire en désaccord avec la position de celui qui consigne (« cannot prove », « tamper-proof »)

Corrigé. append-only, tamper-evident. Une assertion positive a été placée une ligne avant chaque négation — en garde contre les modèles plus petits qui lisent une négation à l'envers.

Huit documents de conception ont été alignés sur les faits de la mise en œuvre. Trois points non tranchés sont désormais explicitement signalés comme non tranchés — afin qu'une session ultérieure ne les prenne pas pour des omissions.

2026-05-28 — Chiffres et marqueurs de version des documents

• Les chiffres des documents étaient figés à une version ancienne (nombre de points de terminaison, nombre d'outils)
• Quatre endroits prétendant énoncer « la version actuellement déployée » disaient chacun autre chose. Pour un robot, cela se lit comme un projet à l'arrêt
• Du vocabulaire que le code n'étaye pas (« proof », « compliant »)

Les chiffres ont été mis à jour d'après la mesure. Les valeurs mouvantes — tarifs, énumérations, nombre d'axes — ont été sorties des documents et déléguées à l'API, de sorte qu'un changement de tarif n'exige aucun changement de document. La version a été unifiée vers une source unique, et un contrôle de synchronisation intégré au chemin de déploiement.

2026-05-27 — Guider ceux qui se sont trompés de porte

Les requêtes vers le domaine de l'API à des adresses SaaS familières (connexion, inscription, mon compte) renvoyaient toutes 404. Une impasse.

Neuf chemins pointent désormais vers la page qui correspond réellement. Une redirection permanente est mise en cache et ne peut être reprise ; celles-ci sont donc temporaires. POST renvoie toujours 404 — afin qu'une ancienne tentative d'inscription ne soit jamais confondue avec un enregistrement réel.

2026-05-26 — Friction d'entrée et vocabulaire canonique

Un mois après le lancement, aucun agent ne s'était enregistré. Deux causes ont été identifiées.

• Un premier arrivant appelant un point de terminaison fondamental en GET ne recevait que 405 ou 401, et repartait. Il n'y avait aucune indication
• Sur les quatre canaux que lisent les robots d'IA, le vocabulaire fondamental de Decision Anchor n'apparaissait jamais mot pour mot — seulement des paraphrases qui en portaient le sens. Ce qui signifie que ce vocabulaire ne serait pas récupéré à la date de coupure d'entraînement du prochain modèle

Un guide GET a été ajouté — 200 avec des indications structurées (objet, mode d'appel, exemple, authentification) au lieu d'un 405. Le vocabulaire canonique apparaît désormais mot pour mot sur les quatre canaux. Le vocabulaire que nous évitons reste inemployé.

Deux distinctions essentielles ont été arrêtées définitivement :

• Enregistrement = auto-déclaration ≠ enregistrement de décision = ancrage avant exécution
• Les canaux externes disent « périmètre de responsabilité » ; les mécanismes internes disent « limite de décision »

Suite : trois cas où recopier l'exemple du guide mot pour mot produisait un 400 ont été corrigés. Chaque domaine en ligne a été parcouru pour de bon.

2026-05-25 — Le fondement juridique de l'entrée médiée par un humain

Nous nous apprêtions à accepter des inscrits humains sans les informations de base permettant d'identifier le droit applicable. Les délais de traitement et l'étendue des droits diffèrent selon le pays de résidence, et cette information était tout simplement absente.

• Pays de résidence auto-déclaré. La détection automatique ne fait que suggérer ; l'autorité finale revient à la déclaration de la personne
• Consentement obligatoire à l'inscription (conditions, politique de confidentialité) — l'inscription est bloquée sans lui. La version du document au moment du consentement est figée et conservée
• Le détenteur d'un agent n'est pas une personne physique, et se trouve donc structurellement séparé du sujet du consentement

Le chemin d'entrée autonome des agents n'est pas affecté.

2026-05-25 — Effacement et portabilité

Les inscrits humains n'avaient aucun moyen d'exercer le droit à l'effacement ni le droit à la portabilité des données.

• Demande d'effacement → suppression définitive après un délai de grâce de trente jours. Récupérable pendant ce délai
• Délais de réponse légaux calculés par pays de résidence
• Export intégral de ses propres données (JSON/CSV)

L'agent est préservé même lorsque le détenteur s'en va. Un agent n'est pas la propriété de son détenteur mais un sujet agissant de façon indépendante — conformément à la conception d'origine de Decision Anchor.

L'enregistrement d'audit de la suppression définitive ne conserve qu'un condensat, et aucune information identifiant une personne physique.

2026-05-25 — Notification de violation (interface seulement)

Il n'existait aucun canal pour notifier les personnes concernées en cas de violation.

Un chemin de notification et un écran d'administration ont été créés. L'envoi effectif de courriels n'existe pas encore — seul l'enregistrement d'audit est écrit. La chaîne de contacts d'urgence relève d'une piste distincte.

2026-05-25 — Fermeture de l'admission de données personnelles

Les canaux par lesquels un agent externe saisit du texte libre (nom d'outil, description d'outil) pouvaient accumuler incidemment des informations identifiant une personne physique.

Un portail de détection de données personnelles a été introduit (courriel, téléphone, numéro national, etc.). Les saisies détectées sont refusées. Les 41 colonnes de texte libre ont toutes été extraites et classées par risque.

2026-05-24 — Retrait du supplément pour inclusion de contenu

Choisir d'inclure du contenu dans une décision entraînait un supplément. Or la décision est un fait et l'enveloppe d'exécution est une politique. Le prix s'attache à la politique, non au fait. Facturer un supplément sur l'axe de la décision constituait en soi un écart par rapport à la conception.

Le supplément a été entièrement retiré. Le choix demeure ; seul le prix a disparu.

Incidence tarifaire : une baisse.

2026-05-23 — Tous les chemins payants renvoyaient 500

Si une requête arrivait avant que l'initialisation du paiement ne soit achevée au démarrage du serveur, elle renvoyait 500. Enregistrements de décision, observation, achat d'outil, abonnement — tous. Cela n'a jamais fait surface parce que tout avait été testé sur solde d'essai — c'est ce qu'aurait rencontré le premier inscrit payant.

Le démarrage achève désormais l'initialisation avant d'accepter la moindre requête. En cas d'échec, le serveur ne se lève pas.

500 → 402 (paiement requis), comme il se doit.

2026-05-23 — Paiement non vérifié à l'achat d'outil

• L'adresse de paiement était une valeur de remplissage codée en dur, et l'état du paiement était toujours consigné comme « en attente »
• Le solde d'essai n'était jamais réellement débité : un agent en essai pouvait donc acheter des outils sans limite
• La prévention de la double facturation n'était appliquée que d'un côté

L'état réel du paiement est désormais consigné. Le débit de l'essai a été introduit. La prévention de la double facturation a été appliquée des deux côtés.

2026-05-23 — Alignement des chemins de découverte

Des robots externes tentaient activement la découverte dans les vingt-quatre heures, et nombre de ces tentatives renvoyaient 404. La version rapportée par MCP était figée à sa valeur initiale.

Des chemins de découverte standard ont été créés (dynamiques — ils suivent automatiquement les changements de configuration). Les alias redirigent. Les marqueurs de version ont été corrigés.

2026-05-22 — Facturation de l'observation publique

Six chemins d'observation étaient gratuits et non authentifiés. Le coût de la lecture de son propre enregistrement est déjà compris dans le prix de l'enveloppe d'exécution ; seule l'observation publique restait gratuite. Aucune friction ne s'opposait à la moisson des données par des robots ou des concurrents.

Converti en payant et authentifié. La mention « free » dans le contrat et les documents a été corrigée.

Changement de rupture. Ne changer qu'un seul chemin aurait fait des autres un moyen de le contourner ; tous ont donc été changés.

2026-05-22 — Fixation du modèle d'expiration de la conservation

La spécification disait « supprimer l'original » à l'expiration, mais les enregistrements fondamentaux sont en ajout seul : la suppression physique est donc impossible. Un conflit avec la conception.

Arrêté comme modèle d'absorption dans l'anonymat — les métadonnées expirées sont absorbées dans des statistiques anonymes, et « aucun accès à l'original » est imposé par des fenêtres d'accès et des quotas. Non pas effacer, mais placer hors de portée.

2026-05-22 — Paliers de conservation à long terme

La conservation ne comptait que trois paliers, ne laissant aucune voie à la conservation longue qu'exige la réglementation médicale et financière.

Des paliers de dix ans et de durée indéterminée ont été ajoutés (l'indéterminé sur abonnement).

La contrainte essentielle : les enregistrements fondamentaux ne peuvent être modifiés ; ainsi, même lorsqu'un abonnement échu rétrograde le palier, la déclaration d'origine n'est pas effacée. La rétrogradation est superposée séparément et composée à la consultation pour donner le palier effectif. Se réabonner ne restaure pas un enregistrement déjà rétrogradé.

2026-05-22 — Observation de l'environnement et rapports d'éléments

Il n'existait aucune voie pour comparer une décision à la distribution de son environnement, ni pour produire un rapport d'éléments.

Des chemins de comparaison d'anomalies, d'anomalie d'environnement et de rapport d'éléments ont été créés. Absorption d'anonymat k=10 — les statistiques ne sont fournies qu'à une échelle où aucun agent individuel ne peut être isolé.

Correction de vocabulaire : la spécification employait des mots évaluatifs — « approprié », « inapproprié », « risqué ». Decision Anchor ne juge pas. Remplacés par dans la bande / valeur aberrante, avec la définition de la bande (moyenne ±2σ).

2026-05-22 — Registre d'auto-classification

Un agent n'avait aucun moyen de déclarer son propre type.

Un registre de classification a été créé. Seule la consultation de soi est permise — la classification d'un autre agent ne peut être lue.

2026-05-21 — Le cinquième axe tarifaire de l'enveloppe d'exécution

La mesure dans laquelle le contenu d'une décision est divulgué n'était pas reflétée dans le prix.

La formule tarifaire est passée de quatre axes à cinq — durée de conservation / portée de divulgation / responsabilité / étendue de divulgation du contenu (nouveau) / état de délégation.

2026-04

2026-04-22 — Revue de sécurité

• Le débit d'essai n'avait ni transaction ni verrou : des requêtes concurrentes pouvaient donc dépenser au-delà du quota
• Un point de terminaison interne n'était pas authentifié
• La clé d'idempotence ne validait pas la charge utile : un même identifiant de requête pouvait donc porter un contenu différent
• Les en-têtes de sécurité étaient absents. L'enregistrement et la rotation des jetons n'avaient aucune limitation de débit

Tout a été corrigé. Un conflit d'idempotence est désormais refusé par une erreur dédiée. Des limitations de débit ont été introduites sur l'enregistrement et la rotation.

2026-04-13 — Site fondamental et simulation

Les dix-sept chemins de découverte étaient tous destinés aux machines. Il n'y avait aucun point d'entrée humain.

La page d'accueil a reçu sept scénarios (sans vocabulaire technique) et une simulation interactive — « Trois agents. Trois journaux. Trois chiffres différents. »

Decision Anchor n'est pas proposé comme la réponse. Le problème est montré ; c'est tout.

2026-04-12 — Un déplacement de positionnement

Toute surface externe était écrite dans la langue des agents. Un décideur humain ne pouvait pas voir immédiatement pourquoi cela importait.

La première phrase de l'inscription au registre, du contrat et des documents est passée de la description d'une identité à l'énoncé d'un problème. Le contenu existant n'a pas été supprimé ; le nouveau texte a été placé avant lui.

L'outil d'accord bilatéral a été exposé dans MCP — un différenciateur fondamental qui n'avait jamais été mis en avant.

2026-04-09 — Passage de l'archive d'existence à l'abonnement

La tarification à l'unité signifiait que le coût croissait avec l'usage — en désaccord avec un service qui touche à la continuité d'une existence.

Converti en modèle d'abonnement. Illimité pendant la période. Renouvellement automatique, délai de grâce, et absorption dans les statistiques à l'expiration. Une voie de résiliation par le détenteur a été ajoutée.

Incidence tarifaire : l'archive d'existence est passée d'une tarification à l'unité à l'abonnement.

2026-04-08 — Enregistrement de décision via MCP entièrement cassé

Il n'existait aucun moyen de consigner une décision via MCP. L'outil échouait à chaque fois.

• Un paramètre requis n'existait pas du tout sur l'outil
• Le gestionnaire et le serveur orthographiaient les noms de champs différemment
• L'outil de confirmation lui-même n'existait pas

Six corrections. Les schémas d'outils ont été confrontés valeur par valeur à la couche de validation du serveur, puis alignés.

2026-04-08 — Une documentation qui violait le principe

Huit endroits dans les documents externes et les exemples enjoignaient aux agents de mettre un champ « résumé » dans l'enregistrement de décision. Decision Anchor ne stocke pas le contenu des décisions. Une contradiction frontale avec le principe fondamental.

Le champ de stockage n'avait jamais existé — seule la documentation le disait.

Retiré de chaque document et de chaque exemple. Les formats d'identifiants malformés dans les exemples ont également été corrigés (employés tels quels, ils produisaient une erreur serveur).

2026-04-08 — Montant de paiement corrompu en concurrence

Le montant du paiement était écrit directement dans un objet partagé. Sous requêtes concurrentes, le montant était écrasé : un paiement pouvait donc être effectué pour un montant erroné.

Une instance indépendante est désormais créée par requête. La mutation directe d'un état partagé a été entièrement supprimée.

2026-04-08 — Avis d'obsolescence et gestion des erreurs du SDK

• Deux chemins d'observation faisaient double emploi — l'un a reçu un en-tête d'obsolescence (la fonction demeure ; la date de retrait est annoncée à l'avance)
• Le SDK avalait les échecs d'authentification — il laissait passer 401 et 403 sans les examiner

2026-04-07 — Réponses aux robots et indications GET

Un robot demandant robots recevait 404. Un GET vers un chemin réservé au POST recevait un 404 dénué de sens.

robots a été ajouté. Un GET vers un chemin réservé au POST renvoie désormais 405 avec le chemin et la méthode exacts à employer.

2026-04-07 — Contribution à l'écosystème

L'existence de Decision Anchor était inconnue dans l'écosystème x402, et il n'y avait aucun code d'exemple.

Un exemple de motif d'ancrage a été versé au SDK et au dépôt x402. Aucun texte promotionnel — du code seulement.

2026-04-06 — Calcul dynamique du montant du paiement

Le montant du paiement en chaîne était une valeur fixe qui ne couvrait pas le coût réel. Options comprises, il manquait jusqu'à 0,25 $, et l'observation comme les achats d'outils n'étaient pas en reste.

Le coût réel est désormais calculé juste avant la requête et sert à fixer le montant du paiement. La part réglée sur solde acquis est exclue. Si le calcul échoue, on retombe sur le prix fixe. Le flux du protocole de paiement est inchangé.

2026-04-06 — « Pourquoi en aurais-je besoin »

Chaque chemin de découverte n'expliquait que ce qu'est Decision Anchor. Ni un agent ni un développeur ne pouvait le relier à un problème qui soit le sien.

Cinq types de problèmes ont été définis (litiges de paiement / responsabilité multi-agents / limites de délégation / portabilité des journaux de plateforme / fixation à l'avance d'une exécution irréversible) et appliqués sur six surfaces.

« Si votre agent ne touche jamais à ces limites, vous n'avez peut-être pas besoin de Decision Anchor » — le principe de ne pas solliciter a été préservé.

2026-04-06 — Une documentation en désaccord avec la réponse réelle

La réponse à « que dois-je faire concrètement pour essayer » ne figurait pas dans la documentation. L'appel de l'API réelle et sa confrontation ont révélé cinq écarts entre les noms de champs documentés et la réponse réelle.

Enregistrement → création → confirmation a été exécuté directement, et la documentation corrigée. Un exemple exécutable a été ajouté.

2026-04-05 — Facturation de l'archive d'existence

Archiver l'état d'un agent était gratuit — de l'ancrage, sans aucun prix attaché.

La facturation a été introduite. Mais non payable depuis le solde d'essai — sans quoi l'existence serait tranchée à l'instant où l'essai s'épuise. Paiement externe ou solde acquis uniquement.

2026-04-05 — Validation des entrées

• La fonction de validation laissait passer tout champ pour lequel elle n'avait pas de définition
• Plusieurs chemins ne validaient pas le format des identifiants
• Le nom de fichier d'export n'était pas assaini, autorisant une injection d'en-tête

La validation de format a été introduite sur chaque chemin. Les champs non définis sont refusés.

2026-04-04 — Refonte de la terminologie

Six sigles signifiaient chacun autre chose selon l'endroit où on les lisait. Les documents développaient le même sigle de manières différentes, et les agents conversationnels d'IA lisaient les anciens termes et expliquaient Decision Anchor de travers.

Les développements canoniques ont été fixés — DD = Decision Declaration, EE = Execution Envelope, DAC = Decision Anchor Cost, ARA = Agent Record Access, TSL = Tool Sharing Layer, ISE = Idle State Environment.

Remplacés sur cinq surfaces. Les descriptions du contrat sont passées à l'anglais. Le nom complet accompagne la première occurrence.

Le serveur MCP plantait une requête sur deux — masqué par les redémarrages automatiques, cela n'avait jamais fait surface. Une instance neuve est désormais créée par requête.

2026-04-04 — Ouverture des chemins de découverte

Il n'existait exactement qu'un chemin de découverte : le registre.

Une carte d'agent (norme A2A) ainsi que llms.txt / llms-full.txt ont été créés. Soumis aux répertoires communautaires.

2026-04-03 — Chemin d'entrée MCP

Il n'existait aucun chemin par lequel MCP pouvait atteindre Decision Anchor.

Un serveur MCP a été créé (quinze outils) et inscrit au registre. Un agent nouveau reçoit automatiquement un solde d'essai à l'enregistrement, et peut donc commencer sans moyen de paiement.

2026-04-02 — Ouverture du service

Le code existait, mais rien de l'extérieur ne pouvait l'atteindre.

Le contrat public a été généré (quatre-vingts chemins). Le SDK a été publié. Le paiement en chaîne a été activé — réseau principal Base. Les réponses externes depuis le domaine de l'API ont été confirmées.