Prueba de aceptacion de artefactos de prueba: como evaluar la formalizacion de Anthropic del Ultimo Teorema de Fermat

Una verificacion verde en Lean es evidencia seria para la formalizacion de Anthropic del Ultimo Teorema de Fermat. Dice que un enunciado formal, en un entorno Lean definido, paso el verificador de la maquina. Eso no es poca cosa. Para las matematicas asistidas por IA, desplaza la discusion de demostraciones pulidas hacia un artefacto que puede inspeccionarse.

Aun asi, un archivo verificado no es lo mismo que un artefacto aceptado. El enunciado del teorema podria diferir de la afirmacion informal. Las dependencias pueden traer supuestos que la mayoria de los lectores nunca ve. Una compilacion puede funcionar en una maquina y fallar para todos los demas. Una prueba puede verificarse hoy y luego volverse dificil de mantener cuando Mathlib cambie.

La vision practica: las verificaciones verdes merecen respeto, no confianza ciega.

La publicacion de investigacion de Anthropic sobre la formalizacion del Ultimo Teorema de Fermat, junto con su repositorio publico, da a los revisores un caso de prueba util. La pregunta no es solo si se verifico. La mejor pregunta es si otro revisor competente puede inspeccionar el enunciado, reproducir la compilacion, explicar el limite de confianza, mantener el artefacto y recuperar mas adelante una version conocida como correcta.

Ese es el trabajo de la Prueba de Aceptacion de Artefactos de Prueba, o PAAT. PAAT no juzga si la prueba es bella. Es un marco de aceptacion para decidir si un gran artefacto de prueba formal es util para investigadores y equipos tecnicos, en lugar de ser meramente impresionante. Este encuadre encaja con la disciplina de reproducibilidad comentada en reproducibilidad de benchmarks de IA: el paquete de evidencia importa tanto como el resultado principal. Tambien extiende el argumento de disciplina de fuentes detras de evidencia cientifica abierta para evaluacion de IA y el punto operativo de WeatherNext 3 y evaluacion de infraestructura de IA: la infraestructura seria de IA necesita artefactos inspeccionables, no solo salidas que parezcan solidas.

Por que una verificacion verde en Lean es necesaria pero no todo el caso de aceptacion

La tension util: sintaxis verificada frente a artefacto aceptado

La verificacion de Lean da a los revisores un limite firme. Un archivo se verifica en un entorno determinado, o no se verifica. Ese limite tiene valor real porque deja menos espacio para afirmaciones vagas. Un teorema verificado no es un parrafo que suena persuasivo. Es un objeto formal conectado con importaciones, definiciones, tacticas, enunciados de teoremas y un nucleo de confianza.

La aceptacion del artefacto plantea un conjunto mas amplio de preguntas. Que se verifico exactamente? Que dependencias fueron confiadas? Que version de la biblioteca se uso? El teorema formal corresponde al enunciado clasico del Ultimo Teorema de Fermat? Puede reproducirse el resultado desde un checkout limpio? Hay notas de revision para humanos que necesitan entender la ruta de la prueba?

Esas preguntas no son minucias. Son la diferencia entre un artefacto de prueba que puede sostener trabajo de investigacion y un artefacto de prueba que solo puede sostener un anuncio.

Que afirma Anthropic y que pueden respaldar los artefactos publicos

La publicacion de Anthropic puede respaldar el contexto informado por Anthropic sobre el trabajo y su proposito. El repositorio publico de GitHub puede respaldar una clase distinta de afirmaciones si se inspecciona en un commit fijo: disponibilidad del repositorio, estructura visible de archivos, instrucciones de compilacion en el README, archivos de verificacion final como FinalCheck.lean y datos de dependencias mediante archivos como lake-manifest.json. La documentacion de Lean y Mathlib explica el contexto de herramientas. Los materiales y el repositorio FLT de Imperial College proporcionan contexto sobre el esfuerzo de formalizacion de la comunidad. Prove2Me proporciona contexto para sistemas de IA orientados a la demostracion de teoremas.

Los limites entre esas fuentes importan. Un anuncio de investigacion no es una auditoria independiente. Un repositorio publico no es prueba de mantenimiento a largo plazo. Un README no garantiza que cada checkout futuro vaya a compilar. PAAT mantiene separadas esas afirmaciones para que la decision de aceptacion no se infle por el entusiasmo alrededor del resultado.

La pila de fuentes: que debe inspeccionarse antes de aceptar el artefacto de Fermat

Un revisor debe empezar por fuentes publicas duraderas, no por fragmentos de busqueda, publicaciones sociales o resumenes de segunda mano. Para este artefacto, la pila de fuentes incluye la publicacion de investigacion de Anthropic, el repositorio anthropics/fermats-last-theorem, el README del repositorio, FinalCheck.lean, lake-manifest.json, la pagina de caso de uso FLT de Lean, el sitio del proyecto FLT de Imperial College, el repositorio FLT de Imperial College, Prove2Me y la vision general de Mathlib.

El marco PAAT de seis puertas para grandes artefactos de prueba formal

PAAT es el marco de aceptacion de seis puertas de Optijara para artefactos de prueba formal. Esta disenado para pruebas generadas por IA o asistidas por IA en las que el resultado puede ser impresionante, pero el caso de aceptacion debe mantenerse centrado en la evidencia.

Puerta 1: procedencia y alcance

Empieza con la identidad del artefacto. Registra el repositorio canonico, hash de commit, pagina de publicacion, autor u organizacion, licencia si existe, archivos del teorema, archivos de compilacion y la version exacta bajo revision. La procedencia evita un fallo comun: juzgar un objetivo movil y descubrir despues que el artefacto cambio por debajo de la revision.

Puerta 2: equivalencia del enunciado

La equivalencia del enunciado pregunta si el teorema formal coincide con la afirmacion prevista del Ultimo Teorema de Fermat. Un teorema puede verificarse mientras codifica un dominio desplazado, una condicion oculta, una definicion enterrada dentro de una dependencia o un resultado mas estrecho de lo que los lectores suponen. El revisor tiene que mapear la frase matematica al enunciado formal en Lean y sus definiciones.

Puerta 3: superficie de axiomas y dependencias

Una prueba formal hereda confianza de sus axiomas, importaciones, bibliotecas, compilador y verificador. PAAT trata esa superficie como un limite de confianza, no como fontaneria de fondo. Los revisores deben inspeccionar informes de axiomas cuando esten disponibles, modulos importados, versiones de dependencias de Mathlib, datos del manifiesto de Lake y cualquier codigo personalizado de confianza.

Puerta 4: compilacion determinista y verificabilidad

Un artefacto formal que solo se verifica en la maquina de un colaborador no esta listo para una aceptacion amplia. La puerta 4 pregunta si un entorno limpio puede clonar el repositorio, instalar o seleccionar la cadena de herramientas Lean documentada, resolver las dependencias documentadas, compilar el proyecto y ejecutar la verificacion final.

Puerta 5: integridad y residuos del grafo de prueba

Los grandes artefactos asistidos por IA pueden contener fragmentos generados, reintentos, lemas abandonados, scripts fragiles o archivos que ya no se conectan al teorema final. La puerta 5 pregunta si el grafo de prueba es coherente. Las declaraciones clave se conectan al teorema final? Hay declaraciones no resueltas o atajos de confianza? Estan documentados los archivos intermedios generados?

Puerta 6: reproduccion, exposicion, mantenimiento y archivo

La puerta final conecta el artefacto con la continuidad humana y operativa. La reproduccion independiente muestra que otro revisor competente puede ejecutar el artefacto fuera del entorno del productor. La exposicion explica la ruta de la prueba para que los humanos puedan entender que hacen los archivos formales. El mantenimiento nombra quien actualizara dependencias y respondera ante roturas. La planificacion de archivo preserva una instantanea conocida como correcta.

Una matriz de pruebas de reproduccion para investigadores y revisores tecnicos

La prueba minima util es un clon limpio desde el repositorio canonico, seguido por la ruta documentada de dependencias y compilacion. Captura el hash de commit, la version de la cadena de herramientas, el estado del manifiesto, el objetivo final y la salida. Una revision mas fuerte anade una auditoria del enunciado, una auditoria de axiomas, un diff de dependencias y una breve nota humana que explique que se verifico.

Aceptar, pilotar o esperar: una matriz de decision para la adopcion de pruebas formales

La aceptacion debe ser conservadora. Acepta cuando el repositorio es publico, se captura el commit evaluado, el enunciado del teorema ha sido auditado, los axiomas y dependencias estan documentados, la compilacion es determinista, un revisor independiente ha reproducido la verificacion, la exposicion es legible y existe un plan de archivo. Pilota cuando la verificacion final tiene exito, pero la reproduccion de revisores, la exposicion o la evidencia de mantenimiento aun estan madurando. Espera cuando el enunciado del teorema no esta mapeado, las dependencias no estan documentadas, los pasos de compilacion estan incompletos, los axiomas no estan documentados, el repositorio no puede archivarse o la reproduccion independiente no es posible.

En que se equivocan los equipos al evaluar pruebas formales generadas por IA

El primer error es tratar la salida final del verificador como toda la revision. El resultado del verificador es esencial, pero solo esta ligado al enunciado y al entorno que se verifican.

El segundo error es ignorar la deriva del enunciado. Un teorema formal puede ser tecnicamente valido mientras los lectores infieren una afirmacion informal mas amplia o distinta.

El tercer error es ocultar los supuestos de dependencias y axiomas. Las dependencias no son vergonzosas. Las dependencias ocultas son el problema.

El cuarto error es confundir exposicion con reproduccion. Un buen recorrido ayuda a los humanos a entender la prueba, pero no sustituye una compilacion limpia ni una transcripcion de un revisor independiente.

El quinto error es olvidar el mantenimiento. Lean, Mathlib, el alojamiento del repositorio y las convenciones del proyecto pueden cambiar. Si nadie se encarga del mantenimiento o de las instantaneas de archivo, el artefacto verificado de hoy puede convertirse en la referencia rota de manana.

Lista de implementacion y plan de medicion para PAAT

Usa esta lista antes de hacer cualquier afirmacion de aceptacion:

• Captura la URL de publicacion canonica, la URL del repositorio y el hash de commit.
• Registra el archivo del teorema y el objetivo de verificacion final.
• Guarda las instrucciones de compilacion del README y los manifiestos de dependencias.
• Inspecciona la equivalencia del enunciado del teorema con un revisor cualificado.
• Documenta axiomas, importaciones, dependencias de Mathlib y limites de confianza.
• Ejecuta la compilacion y la verificacion final en un entorno limpio.
• Captura notas de reproduccion independiente.
• Enlaza la exposicion o recorrido escrito.
• Identifica propietario de mantenimiento, instantanea de archivo y nota de rollback.

{
  "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"]
}

Salvedades: que no puede demostrar PAAT

PAAT evalua la aceptabilidad del artefacto. No demuestra que la prueba sea la mas corta, clara, elegante o la mejor ruta de ensenanza. Una prueba verificada por maquina aun puede necesitar una exposicion excelente antes de que la mayoria de los humanos pueda aprender de ella.

Reproducible hoy no significa reproducible para siempre. La deriva de la cadena de herramientas es real. Mathlib evoluciona. El alojamiento de repositorios cambia. Las dependencias pueden desaparecer o moverse. El comportamiento de cache y los entornos locales pueden diferir. Por eso las instantaneas de archivo y las notas de rollback pertenecen al caso de aceptacion.

La leccion mas amplia no se limita a un teorema. Los artefactos de prueba de IA mas utiles se juzgaran por lo que afirman y por que tan bien su evidencia sobrevive a la inspeccion. Para un equipo que sigue la investigacion en IA, el trabajo practico es convertir afirmaciones de movimiento rapido en tablas de evidencia, pruebas de aceptacion, notas de reproduccion y decisiones de mantenimiento antes de que esas afirmaciones den forma a hojas de ruta o posicionamiento publico.