Résumé

  • draft-abak-ai-evaluation-claim-preservation-00 décrit les distinctions qu’un profil de conversion doit garder pour transporter une affirmation d’évaluation IA sans en modifier silencieusement le sens.
  • Un numéro de run n’identifie pas nécessairement la tâche, le scoreur, la métrique, la tentative, l’agrégation, le jeu de données ni la population qui fondent la conclusion.
  • Une enveloppe authentifiée peut protéger un résumé ambigu. La signature prouve alors l’auteur du résumé, pas la sélection qu’il n’a jamais explicitée.

Le pouvoir caché du sélecteur

Un système d’évaluation peut produire plusieurs métriques sous une même tâche. Le projet emploie un exemple synthétique inspiré de la structure documentée par LightEval : un run fictif contient une valeur em de 0,62 et une valeur maj@8 de 0,8. Dire « run-17 a dépassé 0,75 » ne désigne aucun de ces deux objets. La phrase n’explique ni la métrique, ni le seuil, ni l’auteur du jugement.

La lacune paraît technique. Elle est en réalité décisionnelle. Choisir la première valeur, la dernière, la plus élevée ou la plus favorable revient à choisir le résultat admis dans le dossier. Lorsque 0,62 échoue et 0,8 réussit, l’ordre d’un objet JSON devient une politique non déclarée.

La révision 00 demande donc qu’une unité de résultat conserve tout ce qui distingue l’observation revendiquée : tâche, scoreur, métrique, tentative, règle d’agrégation, jeu ou partition de données et population. Le profil doit préciser quels identifiants natifs fournissent ce contexte et dans quel espace ils sont uniques.

Un JSON Pointer peut localiser /results/example~1task|0/em. Il ne dit pas à lui seul ce que mesure em, quelle version de la tâche a été utilisée, si l’URL source a changé ni si la population était complète. Il donne une adresse dans un objet ; il ne transporte pas la doctrine qui transforme la valeur en preuve.

Une source figée, pas seulement une adresse

Un sélecteur s’interprète contre un instantané identifié. Si une URL mutable reçoit une nouvelle version, l’ancien pointeur ne doit pas devenir silencieusement une référence vers un autre contenu. Le convertisseur doit lier l’objet source, la sélection, la règle de mapping et la sortie.

Le même principe vaut pour les empreintes. Une empreinte identifie des octets sous un algorithme et une règle de sélection donnés. Elle ne décrit pas les règles qui interprètent ces octets. Hacher le JSON original et hacher une forme canonique sont deux opérations différentes. Un profil qui échange l’une contre l’autre sans le dire peut afficher la même intention tout en changeant l’objet vérifié.

La révision du format source compte aussi. Lorsqu’elle est inconnue, la conversion doit garder cette limite. Lui attribuer la version actuelle par commodité crée une certitude qui n’existait pas au moment du run.

Ce souci de version ne relève pas de l’archivisme. Une nouvelle métrique portant le même nom peut changer de calcul, de direction ou d’échelle. Un ancien consommateur qui traite la nouvelle base comme l’ancienne ne préserve plus le sens, même si chaque champ passe la validation structurelle.

Exécution, score et verdict

Inspect sépare l’état d’un run de ses résultats de scoring. Le projet s’appuie sur cette distinction sans accuser l’outil d’un défaut. Son exemple synthétique contient status: success et une précision de 0,734, mais aucun critère.

« Success » peut signifier que le processus s’est terminé correctement. Ce n’est pas la preuve que la métrique a satisfait une limite de sécurité. Un score de 0,734 ne devient pas un verdict tant qu’un critère identifié ne lui est pas appliqué.

Deux inconnues doivent encore rester séparées. La source peut déclarer qu’aucun critère n’a été appliqué. Ou bien les éléments disponibles peuvent simplement ne pas établir si un critère existait. L’absence d’un champ ne permet de choisir entre ces deux situations que si le format source définit sans ambiguïté le sens de cette omission.

Un consommateur peut appliquer son propre seuil. Il doit alors créer une nouvelle évaluation qui nomme son acteur, ses entrées, sa règle, sa version, son périmètre et son résultat. Ce jugement n’est ni le verdict historique de l’évaluateur, ni la preuve qu’un critère avait été fixé avant le run.

Le dénominateur ne tient pas dans le score

Supposons 100 échantillons prévus, 80 exécutés, 76 satisfaisant le critère local et quatre ne le satisfaisant pas. La fraction observée parmi les échantillons terminés est 76/80, soit 0,95. Elle ne prouve pas que 95 des 100 échantillons prévus ont réussi.

Un export limité à 0.95 efface les vingt cas non exécutés. Une signature ultérieure peut protéger ce nombre tout en protégeant aussi l’effacement. Les nouvelles tentatives, doublons, exclusions, invalidations et changements de population posent la même question : quelle règle construit le dénominateur ?

Une campagne complète exige une population identifiée ou une règle d’inclusion reproductible, ainsi qu’une méthode de comptage. Lorsque le total est inconnu, le mapping n’a pas le droit de l’inventer. Conserver tous les enregistrements fournis ne démontre pas non plus que l’opérateur a fourni toutes les tentatives réelles.

La transformation numérique peut changer la décision

Le projet propose un autre cas synthétique : la valeur exacte 0.94996 est affichée comme 0.950, avec un seuil >= 0.95. La comparaison sur la source échoue ; la comparaison sur l’affichage réussit.

L’arrondi peut être utile. Ce qui n’est pas acceptable, c’est de l’utiliser sans l’attribuer comme une dérivation. Les unités, l’échelle, la définition de la métrique, le sens du comparateur, la précision et l’incertitude font partie de l’affirmation lorsqu’ils peuvent changer son interprétation.

Une incertitude absente n’est pas une incertitude nulle. Une normalisation n’est pas la valeur source. Une agrégation n’est pas la liste de ses entrées. La conversion peut offrir une vue plus pratique, mais elle doit préserver la frontière entre observation copiée et calcul nouveau.

L’accès à une preuve n’est pas sa vérification

Un service peut recevoir l’URL privée d’un journal sans pouvoir télécharger les octets. Il peut conserver cette référence, dire qu’il ne l’a pas récupérée et signaler qu’il ne dispose d’aucune empreinte recalculée. Il ne peut pas fabriquer une empreinte, affirmer que le journal existe encore ou traiter les octets comme vérifiés.

Emplacement public, permission d’accès, récupération réussie et rétention future sont des propriétés différentes. Une empreinte copiée depuis la source n’équivaut pas à une empreinte recalculée par le consommateur. Une référence restreinte ne devient pas un contenu disponible parce qu’elle est placée dans une déclaration signée.

Cette prudence protège aussi le vérificateur. Une référence n’est pas une autorisation de télécharger ou d’exécuter sa cible. Les journaux, prompts et sorties d’outils restent des données non fiables. Redirections, schémas d’URL, archives compressées, taille et destinations doivent rester soumis à une politique propre.

La signature tardive ne répare pas la perte ancienne

Les reçus SCITT, les statements in-toto et les rôles RATS peuvent protéger des objets, attribuer des déclarations et séparer l’appréciation de la décision du relying party. Ils ne déterminent pas automatiquement si un convertisseur a choisi la bonne métrique.

Si le premier mapping abandonne la population et ne garde que 0,95, le second mapping ne restaure pas ce contexte en signant le résumé. Il peut consulter la source originale et construire une nouvelle vue dérivée. Il doit alors déclarer cette nouvelle vérification, au lieu de prétendre que le contexte a traversé le premier saut.

Une déclaration de perte signée reste elle-même une déclaration. Elle ne prouve pas que l’inventaire des pertes est complet. De même, une enveloppe valide sous un profil sémantique non pris en charge peut être conservée comme objet opaque sans que son affirmation soit acceptée.

Validation structurelle, recalcul d’empreinte, vérification de signature, appréciation d’attestation, contrôle du mapping et jugement substantiel sont donc des vérifications typées. Une interface qui les réduit à un seul feu vert recrée au dernier écran la confusion que le dossier avait tenté d’éviter.

Préserver n’est pas certifier

Une affirmation fausse peut être parfaitement préservée. Une source compromise peut signer une contre-vérité. Un convertisseur compétent peut la transporter sans perte. La préservation ne garantit ni la qualité scientifique du benchmark, ni l’indépendance de l’évaluateur, ni l’identité exacte du modèle exécuté, ni la sûreté du déploiement.

Elle ne crée pas davantage une autorisation. Un jugement local peut alimenter une décision sous une politique identifiée. Le dossier ne prouve pas pour autant que l’acteur avait mandat, que le contrôle a atteint sa cible, que l’exécution a eu lieu ou que l’effet extérieur a suivi.

La révision 00 reste volontairement en deçà. Elle ne propose ni format filaire complet ni certification. Ses scénarios sont synthétiques. Un contrôle de schéma n’est pas un test sémantique complet. Des essais par le même auteur ne sont pas une interopérabilité indépendante.

Le test des couches de réalité

La doctrine des couches de réalité de Heng Lu donne un ordre de lecture : octets sources, résultat sélectionné, affirmation sémantique, enveloppe authentifiée, jugement du consommateur, décision autorisée et effet observé sont des couches liées mais non substituables.

La spécification initiale minimale consiste ici à annoncer le petit ensemble d’affirmations qu’un profil sait préserver, avec les cas qu’il refuse. Elle ne consiste pas à faire passer une pluralité de métriques dans un seul champ status.

La primauté du code en fonctionnement demande enfin des comportements observables. Un producteur et un consommateur indépendants, avec des versions fixées, distinguent-ils deux métriques sous le même run ? Conservent-ils un critère inconnu, une population incomplète et une preuve inaccessible ? Tant que ces résultats ne sont pas testés, l’étiquette « claim-preserving » reste une promesse documentaire.

Sources et limites

Les sources ont été gelées le 30 septembre 2026, fuseau Asia/Shanghai. La révision 00 est un Internet-Draft individuel actif visant le statut Informational. Ce n’est ni un RFC, ni un consensus IETF, ni un produit de groupe de travail, ni une certification, ni un rapport d’implémentation ou de déploiement. Les exemples sont synthétiques. L’application de la doctrine de Heng Lu relève de l’analyse de Daniel Kade.