Teste de Aceitação de Artefato de Prova: Como avaliar a formalização do Último Teorema de Fermat pela Anthropic

Uma checagem verde no Lean é uma evidência séria para a formalização do Último Teorema de Fermat pela Anthropic. Ela diz que uma declaração formal, em um ambiente Lean definido, passou pelo verificador da máquina. Isso não é pouca coisa. Para a matemática assistida por IA, ela afasta a discussão de demonstrações polidas e a aproxima de um artefato que pode ser inspecionado.

Ainda assim, um arquivo verificado não é o mesmo que um artefato aceito. A declaração do teorema pode diferir da afirmação informal. Dependências podem carregar pressupostos que a maioria dos leitores nunca vê. Uma compilação pode funcionar em uma máquina e falhar para todos os outros. Uma prova pode passar hoje e depois se tornar difícil de manter quando a Mathlib mudar.

A visão prática: checagens verdes merecem respeito, não confiança cega.

A publicação de pesquisa da Anthropic sobre a formalização do Último Teorema de Fermat, junto com seu repositório público, dá aos revisores um caso de teste útil. A pergunta não é apenas: ela passou na checagem? A pergunta melhor é se outro revisor capaz consegue inspecionar a declaração, reproduzir a compilação, explicar o limite de confiança, manter o artefato e recuperar uma versão comprovadamente boa mais tarde.

Esse é o trabalho do Teste de Aceitação de Artefato de Prova, ou PAAT. O PAAT não julga se a prova é bonita. Ele é uma estrutura de aceitação para decidir se um grande artefato de prova formal é útil para pesquisadores e equipes técnicas, em vez de ser apenas impressionante. Esse enquadramento se alinha à disciplina de reprodutibilidade discutida em reprodutibilidade de benchmarks de IA: o pacote de evidências importa tanto quanto o resultado principal. Ele também estende o argumento de disciplina de fontes por trás de evidência científica aberta para avaliação de IA e o ponto operacional de WeatherNext 3 e avaliação de infraestrutura de IA: infraestrutura séria de IA precisa de artefatos inspecionáveis, não apenas de saídas que parecem fortes.

Por que uma checagem verde no Lean é necessária, mas não todo o caso de aceitação

A tensão útil: sintaxe verificada versus artefato aceito

A checagem no Lean dá aos revisores um limite rígido. Um arquivo passa em um determinado ambiente, ou não passa. Esse limite tem valor real porque deixa menos espaço para afirmações vagas. Um teorema verificado não é um parágrafo que soa persuasivo. É um objeto formal conectado a importações, definições, táticas, declarações de teoremas e um núcleo confiável.

A aceitação do artefato faz um conjunto mais amplo de perguntas. O que exatamente foi verificado? Quais dependências foram confiadas? Qual versão da biblioteca foi usada? O teorema formal corresponde à declaração clássica do Último Teorema de Fermat? O resultado pode ser reproduzido a partir de uma cópia limpa? Há notas de revisão para humanos que precisam entender o caminho da prova?

Essas perguntas não são preciosismo. Elas são a diferença entre um artefato de prova que pode apoiar trabalho de pesquisa e um artefato de prova que só pode apoiar um anúncio.

O que a Anthropic está afirmando e o que os artefatos públicos podem sustentar

A publicação da Anthropic pode sustentar o contexto relatado pela Anthropic sobre o trabalho e seu propósito. O repositório público no GitHub pode sustentar uma classe diferente de afirmações se for inspecionado em um commit fixo: disponibilidade do repositório, estrutura visível de arquivos, instruções de compilação no README, arquivos de checagem final como FinalCheck.lean e dados de dependência por meio de arquivos como lake-manifest.json. A documentação do Lean e da Mathlib explica o contexto das ferramentas. Os materiais e o repositório de FLT do Imperial College fornecem contexto sobre o esforço de formalização da comunidade. O Prove2Me fornece contexto para sistemas de IA voltados à prova de teoremas.

Os limites entre essas fontes importam. Um anúncio de pesquisa não é uma auditoria independente. Um repositório público não é prova de manutenção de longo prazo. Um README não é garantia de que toda cópia futura será compilada. O PAAT mantém essas afirmações separadas para que a decisão de aceitação não seja inflada pelo entusiasmo em torno do resultado.

A pilha de fontes: o que deve ser inspecionado antes de aceitar o artefato de Fermat

Um revisor deve começar por fontes públicas duráveis, não por trechos de busca, posts sociais ou resumos de segunda mão. Para este artefato, a pilha de fontes inclui a publicação de pesquisa da Anthropic, o repositório anthropics/fermats-last-theorem, o README do repositório, FinalCheck.lean, lake-manifest.json, a página de caso de uso de FLT do Lean, o site do projeto FLT do Imperial College, o repositório FLT do Imperial College, Prove2Me e a visão geral da Mathlib.

A estrutura PAAT de seis portões para grandes artefatos de prova formal

PAAT é a estrutura de aceitação de seis portões da Optijara para artefatos de prova formal. Ele foi projetado para provas geradas por IA ou assistidas por IA em que o resultado pode ser impressionante, mas o caso de aceitação precisa permanecer centrado em evidências.

Portão 1: Proveniência e escopo

Comece pela identidade do artefato. Registre o repositório canônico, hash do commit, página da publicação, autor ou organização, licença se houver, arquivos do teorema, arquivos de compilação e a versão exata em revisão. A proveniência evita uma falha comum: julgar um alvo móvel e depois descobrir que o artefato mudou por baixo da revisão.

Portão 2: Equivalência da declaração

A equivalência da declaração pergunta se o teorema formal corresponde à afirmação pretendida do Último Teorema de Fermat. Um teorema pode passar na checagem enquanto codifica um domínio deslocado, uma condição oculta, uma definição enterrada dentro de uma dependência ou um resultado mais estreito do que os leitores presumem. O revisor precisa mapear a sentença matemática para a declaração formal no Lean e suas definições.

Portão 3: Superfície de axiomas e dependências

Uma prova formal herda confiança de seus axiomas, importações, bibliotecas, compilador e verificador. O PAAT trata essa superfície como um limite de confiança, não como encanamento de fundo. Revisores devem inspecionar relatórios de axiomas quando disponíveis, módulos importados, versões de dependências da Mathlib, dados de manifesto do Lake e qualquer código confiável personalizado.

Portão 4: Compilação determinística e verificabilidade

Um artefato formal que só passa na checagem na máquina de um colaborador não está pronto para aceitação ampla. O Portão 4 pergunta se um ambiente limpo consegue clonar o repositório, instalar ou selecionar a cadeia de ferramentas Lean documentada, resolver dependências documentadas, compilar o projeto e executar a checagem final.

Portão 5: Integridade e resíduos do grafo de prova

Grandes artefatos assistidos por IA podem conter fragmentos gerados, tentativas, lemas abandonados, scripts frágeis ou arquivos que não se conectam mais ao teorema final. O Portão 5 pergunta se o grafo de prova é coerente. As declarações principais se conectam ao teorema final? Há declarações não resolvidas ou atalhos confiados? Os arquivos intermediários gerados estão documentados?

Portão 6: Reprodução, exposição, manutenção e arquivamento

O portão final conecta o artefato à continuidade humana e operacional. A reprodução independente mostra que outro revisor capaz consegue executar o artefato fora do ambiente do produtor. A exposição explica o caminho da prova para que humanos entendam o que os arquivos formais estão fazendo. A manutenção nomeia quem atualizará dependências e responderá a quebras. O planejamento de arquivamento preserva um instantâneo comprovadamente bom.

Uma matriz de testes de reprodução para pesquisadores e revisores técnicos

O teste útil mínimo é um clone limpo a partir do repositório canônico, seguido pelo caminho documentado de dependências e compilação. Capture o hash do commit, a versão da cadeia de ferramentas, o estado do manifesto, o alvo final e a saída. Uma revisão mais forte acrescenta uma auditoria de declaração, auditoria de axiomas, diferença de dependências e uma breve nota humana explicando o que foi verificado.

Aceitar, pilotar ou esperar: uma matriz de decisão para adoção de prova formal

A aceitação deve ser conservadora. Aceite quando o repositório for público, o commit avaliado estiver capturado, a declaração do teorema tiver sido auditada, axiomas e dependências estiverem documentados, a compilação for determinística, um revisor independente tiver reproduzido a checagem, a exposição for legível e existir um plano de arquivamento. Pilote quando a checagem final tiver sucesso, mas a reprodução por revisores, a exposição ou a evidência de manutenção ainda estiverem amadurecendo. Espere quando a declaração do teorema não estiver mapeada, as dependências não estiverem documentadas, as etapas de compilação estiverem incompletas, os axiomas não estiverem documentados, o repositório não puder ser arquivado ou a reprodução independente não for possível.

O que as equipes erram ao avaliar provas formais geradas por IA

O primeiro erro é tratar a saída final do verificador como toda a revisão. O resultado do verificador é essencial, mas está vinculado apenas à declaração e ao ambiente sendo verificados.

O segundo erro é ignorar a deriva da declaração. Um teorema formal pode ser tecnicamente válido enquanto leitores inferem uma afirmação informal mais ampla ou diferente.

O terceiro erro é ocultar pressupostos de dependências e axiomas. Dependências não são constrangedoras. Dependências ocultas são o problema.

O quarto erro é confundir exposição com reprodução. Um bom passo a passo ajuda humanos a entender a prova, mas não substitui uma compilação limpa e a transcrição de um revisor independente.

O quinto erro é esquecer a manutenção. Lean, Mathlib, hospedagem de repositórios e convenções de projeto podem mudar. Se ninguém é responsável pela manutenção ou por instantâneos de arquivamento, o artefato verificado de hoje pode se tornar a referência quebrada de amanhã.

Checklist de implementação e plano de medição para o PAAT

Use este checklist antes de fazer qualquer afirmação de aceitação:

• Capture a URL canônica da publicação, a URL do repositório e o hash do commit.
• Registre o arquivo do teorema e o alvo de checagem final.
• Salve as instruções de compilação do README e os manifestos de dependência.
• Inspecione a equivalência da declaração do teorema com um revisor qualificado.
• Documente axiomas, importações, dependências da Mathlib e limites confiados.
• Execute a compilação e a checagem final em um ambiente limpo.
• Capture notas de reprodução independente.
• Vincule a exposição escrita ou o passo a passo.
• Identifique responsável pela manutenção, instantâneo de arquivo e nota de reversão.

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

Ressalvas: o que o PAAT não consegue provar

O PAAT avalia a aceitabilidade do artefato. Ele não prova que a prova é a mais curta, mais clara, mais elegante ou o melhor caminho de ensino. Uma prova verificada por máquina ainda pode precisar de excelente exposição antes que a maioria dos humanos consiga aprender com ela.

Reprodutível hoje não significa reprodutível para sempre. A deriva da cadeia de ferramentas é real. A Mathlib evolui. A hospedagem de repositórios muda. Dependências podem desaparecer ou se mover. O comportamento de cache e os ambientes locais podem diferir. É por isso que instantâneos de arquivamento e notas de reversão pertencem ao caso de aceitação.

A lição mais ampla não se limita a um teorema. Os artefatos de prova de IA mais úteis serão julgados pelo que afirmam e por quão bem suas evidências sobrevivem à inspeção. Para uma equipe que acompanha pesquisa de IA, o trabalho prático é transformar afirmações em rápida evolução em tabelas de evidências, testes de aceitação, notas de reprodução e decisões de manutenção antes que essas afirmações moldem roteiros ou posicionamento público.