Test d'acceptation des artefacts de preuve : comment évaluer la formalisation par Anthropic du dernier théorème de Fermat

Une vérification Lean au vert est une preuve sérieuse pour la formalisation par Anthropic du dernier théorème de Fermat. Elle indique qu'un énoncé formel, dans un environnement Lean défini, a passé le vérificateur machine. Ce n'est pas anodin. Pour les mathématiques assistées par l'IA, cela déplace la discussion des démonstrations soignées vers un artefact qui peut être inspecté.

Cependant, un fichier vérifié n'est pas la même chose qu'un artefact accepté. L'énoncé du théorème peut différer de l'affirmation informelle. Les dépendances peuvent porter des hypothèses que la plupart des lecteurs ne voient jamais. Une compilation peut fonctionner sur une machine et échouer pour tous les autres. Une preuve peut être vérifiée aujourd'hui, puis devenir difficile à maintenir lorsque Mathlib change.

La position pratique : les validations au vert méritent le respect, pas une confiance aveugle.

La publication de recherche d'Anthropic sur la formalisation du dernier théorème de Fermat, ainsi que son dépôt public, donnent aux évaluateurs un cas de test utile. La question n'est pas seulement : a-t-elle été vérifiée ? La meilleure question est de savoir si un autre évaluateur compétent peut inspecter l'énoncé, reproduire la compilation, expliquer la frontière de confiance, maintenir l'artefact et retrouver plus tard une version connue comme valide.

C'est le rôle du Proof Artifact Acceptance Test, ou PAAT. PAAT ne juge pas si la preuve est belle. C'est un cadre d'acceptation pour décider si un grand artefact de preuve formelle est utile aux chercheurs et aux équipes techniques, au lieu d'être seulement impressionnant. Ce cadrage correspond à la discipline de reproductibilité discutée dans la reproductibilité des benchmarks d'IA : le dossier de preuves compte autant que le résultat annoncé. Il prolonge aussi l'argument de discipline des sources derrière les preuves scientifiques ouvertes pour l'évaluation de l'IA et le point opérationnel tiré de WeatherNext 3 et l'évaluation de l'infrastructure d'IA : une infrastructure d'IA sérieuse a besoin d'artefacts inspectables, pas seulement de sorties d'apparence solide.

Pourquoi une vérification Lean au vert est nécessaire sans constituer tout le dossier d'acceptation

La tension utile : syntaxe vérifiée contre artefact accepté

La vérification Lean donne aux évaluateurs une frontière nette. Un fichier se vérifie dans un environnement donné, ou il ne se vérifie pas. Cette frontière a une vraie valeur parce qu'elle laisse moins de place aux affirmations vagues. Un théorème vérifié n'est pas un paragraphe qui semble persuasif. C'est un objet formel relié à des imports, des définitions, des tactiques, des énoncés de théorèmes et un noyau de confiance.

L'acceptation de l'artefact pose un ensemble plus large de questions. Qu'est-ce qui a exactement été vérifié ? Quelles dépendances ont été considérées comme fiables ? Quelle version de bibliothèque a été utilisée ? Le théorème formel correspond-il à l'énoncé classique du dernier théorème de Fermat ? Le résultat peut-il être reproduit depuis un clone propre ? Existe-t-il des notes de revue pour les humains qui doivent comprendre le chemin de preuve ?

Ces questions ne sont pas du pinaillage. Elles font la différence entre un artefact de preuve capable de soutenir un travail de recherche et un artefact de preuve capable seulement de soutenir une annonce.

Ce qu'Anthropic affirme et ce que les artefacts publics peuvent étayer

La publication d'Anthropic peut étayer le contexte rapporté par Anthropic sur le travail et son objectif. Le dépôt GitHub public peut étayer une autre catégorie d'affirmations s'il est inspecté à un commit fixe : disponibilité du dépôt, structure de fichiers visible, instructions de compilation dans le README, fichiers de vérification finale comme FinalCheck.lean et données de dépendances via des fichiers comme lake-manifest.json. La documentation de Lean et de Mathlib explique le contexte des outils. Les documents et le dépôt FLT de l'Imperial College fournissent du contexte sur l'effort de formalisation communautaire. Prove2Me fournit du contexte pour les systèmes d'IA destinés à la démonstration de théorèmes.

Les frontières entre ces sources comptent. Une annonce de recherche n'est pas un audit indépendant. Un dépôt public n'est pas une preuve de maintenance à long terme. Un README ne garantit pas que chaque futur clone pourra compiler. PAAT garde ces affirmations séparées afin que la décision d'acceptation ne soit pas gonflée par l'enthousiasme autour du résultat.

La pile de sources : ce qui doit être inspecté avant d'accepter l'artefact Fermat

Un évaluateur doit commencer par des sources publiques durables, pas par des extraits de recherche, des publications sociales ou des résumés de seconde main. Pour cet artefact, la pile de sources inclut la publication de recherche d'Anthropic, le dépôt anthropics/fermats-last-theorem, le README du dépôt, FinalCheck.lean, lake-manifest.json, la page de cas d'utilisation FLT de Lean, le site du projet FLT de l'Imperial College, le dépôt FLT de l'Imperial College, Prove2Me et la vue d'ensemble de Mathlib.

Le cadre PAAT à six portes pour les grands artefacts de preuve formelle

PAAT est le cadre d'acceptation à six portes d'Optijara pour les artefacts de preuve formelle. Il est conçu pour les preuves générées par l'IA ou assistées par l'IA, lorsque le résultat peut être impressionnant mais que le dossier d'acceptation doit rester fondé sur les preuves.

Porte 1 : provenance et périmètre

Commencez par l'identité de l'artefact. Notez le dépôt canonique, le hash de commit, la page de publication, l'auteur ou l'organisation, la licence si elle existe, les fichiers de théorèmes, les fichiers de compilation et la version exacte examinée. La provenance évite un échec fréquent : juger une cible mouvante, puis découvrir plus tard que l'artefact a changé pendant la revue.

Porte 2 : équivalence de l'énoncé

L'équivalence de l'énoncé demande si le théorème formel correspond à l'affirmation visée du dernier théorème de Fermat. Un théorème peut être vérifié tout en encodant un domaine décalé, une condition cachée, une définition enfouie dans une dépendance ou un résultat plus étroit que ce que les lecteurs supposent. L'évaluateur doit relier la phrase mathématique à l'énoncé Lean formel et à ses définitions.

Porte 3 : surface des axiomes et des dépendances

Une preuve formelle hérite de la confiance accordée à ses axiomes, imports, bibliothèques, compilateur et vérificateur. PAAT traite cette surface comme une frontière de confiance, pas comme une plomberie d'arrière-plan. Les évaluateurs doivent inspecter les rapports d'axiomes lorsqu'ils sont disponibles, les modules importés, les versions des dépendances Mathlib, les données du manifeste Lake et tout code personnalisé considéré comme fiable.

Porte 4 : compilation déterministe et vérifiabilité

Un artefact formel qui ne se vérifie que sur la machine d'un contributeur n'est pas prêt pour une acceptation large. La porte 4 demande si un environnement propre peut cloner le dépôt, installer ou sélectionner la chaîne d'outils Lean documentée, résoudre les dépendances documentées, compiler le projet et exécuter la vérification finale.

Porte 5 : intégrité du graphe de preuve et résidus

Les grands artefacts assistés par l'IA peuvent contenir des fragments générés, des essais, des lemmes abandonnés, des scripts fragiles ou des fichiers qui ne sont plus reliés au théorème final. La porte 5 demande si le graphe de preuve est cohérent. Les déclarations clés se rattachent-elles au théorème final ? Existe-t-il des déclarations non résolues ou des raccourcis de confiance ? Les fichiers intermédiaires générés sont-ils documentés ?

Porte 6 : reproduction, exposition, maintenance et archive

La porte finale relie l'artefact à la continuité humaine et opérationnelle. Une reproduction indépendante montre qu'un autre évaluateur compétent peut exécuter l'artefact hors de l'environnement du producteur. L'exposition explique le chemin de preuve afin que les humains puissent comprendre ce que font les fichiers formels. La maintenance nomme qui mettra à jour les dépendances et répondra aux ruptures. La planification d'archive préserve un instantané connu comme valide.

Une matrice de tests de reproduction pour les chercheurs et les évaluateurs techniques

Le test minimal utile est un clone propre depuis le dépôt canonique, suivi du chemin documenté de dépendances et de compilation. Capturez le hash de commit, la version de la chaîne d'outils, l'état du manifeste, la cible finale et la sortie. Une revue plus forte ajoute un audit de l'énoncé, un audit des axiomes, un diff de dépendances et une courte note humaine expliquant ce qui a été vérifié.

Accepter, piloter ou attendre : une matrice de décision pour l'adoption de preuves formelles

L'acceptation doit être conservatrice. Acceptez lorsque le dépôt est public, que le commit évalué est capturé, que l'énoncé du théorème a été audité, que les axiomes et dépendances sont documentés, que la compilation est déterministe, qu'un évaluateur indépendant a reproduit la vérification, que l'exposition est lisible et qu'un plan d'archive existe. Pilotez lorsque la vérification finale réussit, mais que la reproduction par les évaluateurs, l'exposition ou les preuves de maintenance sont encore en maturation. Attendez lorsque l'énoncé du théorème n'est pas relié, que les dépendances ne sont pas documentées, que les étapes de compilation sont incomplètes, que les axiomes ne sont pas documentés, que le dépôt ne peut pas être archivé ou que la reproduction indépendante n'est pas possible.

Ce que les équipes comprennent mal lorsqu'elles évaluent des preuves formelles générées par l'IA

La première erreur consiste à traiter la sortie finale du vérificateur comme toute la revue. Le résultat du vérificateur est essentiel, mais il n'est lié qu'à l'énoncé et à l'environnement vérifiés.

La deuxième erreur est d'ignorer la dérive de l'énoncé. Un théorème formel peut être techniquement valide pendant que les lecteurs déduisent une affirmation informelle plus large ou différente.

La troisième erreur est de masquer les hypothèses de dépendances et d'axiomes. Les dépendances ne sont pas embarrassantes. Les dépendances cachées sont le problème.

La quatrième erreur est de confondre exposition et reproduction. Une bonne présentation aide les humains à comprendre la preuve, mais elle ne remplace pas une compilation propre ni la transcription d'un évaluateur indépendant.

La cinquième erreur est d'oublier la maintenance. Lean, Mathlib, l'hébergement du dépôt et les conventions du projet peuvent changer. Si personne ne possède la maintenance ou les instantanés d'archive, l'artefact vérifié d'aujourd'hui peut devenir la référence cassée de demain.

Liste de contrôle de mise en oeuvre et plan de mesure pour PAAT

Utilisez cette liste de contrôle avant de formuler toute affirmation d'acceptation :

• Capturer l'URL canonique de publication, l'URL du dépôt et le hash de commit.
• Noter le fichier de théorème et la cible de vérification finale.
• Sauvegarder les instructions de compilation du README et les manifestes de dépendances.
• Inspecter l'équivalence de l'énoncé du théorème avec un évaluateur qualifié.
• Documenter les axiomes, imports, dépendances Mathlib et frontières de confiance.
• Exécuter la compilation et la vérification finale dans un environnement propre.
• Capturer les notes de reproduction indépendante.
• Lier l'exposition écrite ou la présentation détaillée.
• Identifier le responsable de maintenance, l'instantané d'archive et la note de retour arrière.

{
  "framework": "PAAT",
  "artifact": "Anthropic Fermat formalization",
  "gates": [
    "provenance_and_scope",
    "statement_equivalence",
    "axiom_dependency_surface",
    "deterministic_build",
    "proof_graph_integrity",
    "reproduction_exposition_maintenance_archive"
  ],
  "decision": ["accept", "pilot", "wait"],
  "residual_risks": ["toolchain_drift", "statement_drift", "archive_gap", "review_capacity"]
}

Limites : ce que PAAT ne peut pas prouver

PAAT évalue l'acceptabilité de l'artefact. Il ne prouve pas que la preuve est la plus courte, la plus claire, la plus élégante ou le meilleur chemin d'enseignement. Une preuve vérifiée par machine peut encore exiger une excellente exposition avant que la plupart des humains puissent en tirer un apprentissage.

Reproductible aujourd'hui ne signifie pas reproductible pour toujours. La dérive de la chaîne d'outils est réelle. Mathlib évolue. L'hébergement des dépôts change. Les dépendances peuvent disparaître ou se déplacer. Le comportement du cache et les environnements locaux peuvent différer. C'est pourquoi les instantanés d'archive et les notes de retour arrière font partie du dossier d'acceptation.

La leçon plus large ne se limite pas à un seul théorème. Les artefacts de preuve d'IA les plus utiles seront jugés par ce qu'ils affirment et par la façon dont leurs preuves résistent à l'inspection. Pour une équipe qui suit la recherche en IA, le travail pratique consiste à transformer des affirmations rapides en tableaux de preuves, tests d'acceptation, notes de reproduction et décisions de maintenance avant que ces affirmations ne façonnent des feuilles de route ou un positionnement public.