Diop Daily #110 — September 2026

September 9, 2026 · 9 min read · formal verification · machine-generated science · proof artifacts · sovereignty

The Proof Must Survive the Machine

A fluent answer can persuade a person for a moment. A proof artifact can let an institution decide whether the answer deserves to enter its memory, software, laboratory, or public record. As models produce increasingly technical work, the scarce layer is moving from generation to independent acceptance: a checker that can inspect the claim, reject a broken derivation, and replay the result under declared conditions.

OpenAI’s News RSS carried two relevant signals on September 8. One described GPT-5.6 Sol with Codex autonomously running quantum-computing experiments, analyzing results, and calibrating qubits. Another described an AI-generated solution to the Navier–Stokes Millennium Prize Problem, accompanied by a writeup and a formal proof in Lean. These are company-reported descriptions rather than independent confirmations that the scientific claims are correct, yet they identify a change in the object being produced: the system is being asked to create technical work that can be checked by a formal language rather than admired as prose.

The mature output of a reasoning machine is a claim carrying its own route to rejection.

Persuasion and verification have different economies

Human review is powerful, but it is also scarce, contextual, and uneven. A researcher can recognize a familiar error. An engineer can inspect an implementation. A mathematician can find an unspoken assumption. These forms of judgment remain necessary because formal systems cover only what has been specified. Their cost rises when the machine produces more candidate results than a specialist can read.

Formal verification changes the division of labor. A proof assistant checks whether a proposition follows from declared definitions and previously accepted rules. A type checker can reject a program that violates a contract. A model checker can explore whether a finite-state system reaches a forbidden condition. A reproducibility runner can compare a result under a fixed environment. Each instrument narrows the space in which fluent error can hide.

The distinction matters for investment. A model endpoint sells the possibility of an answer. A proof system sells a boundary around what may be accepted. The second object can become part of procurement, release, research, and regulation because it creates an observable decision: accepted under these assumptions, rejected under these tests, or unresolved because the formalization is incomplete.

A proof is an executable institutional claim

Lean’s public project describes a language and theorem prover for formalizing mathematics and writing programs whose properties can be checked. Its significance for machine-assisted work is architectural. The proof is stored in a form that another checker can process. The institution does not have to trust the original author’s memory of every inference. It can inspect the proposition, the imported definitions, the tactics or terms, the environment, and the result of the checker.

Formal proof remains bounded by its specification. A theorem can formalize the wrong question. A model can encode an unjustified assumption as an axiom. A proof can establish a narrow proposition that readers mistakenly expand into a broader conclusion. The checker guarantees a relation inside the formal system; people still decide whether the formal system represents the world they care about.

A useful proof record should therefore carry more than a green status:

Claim: the exact proposition, contract, invariant, or safety property under review.
Formal context: definitions, axioms, data assumptions, environment, dependencies, and version identifiers.
Derivation or test: the proof term, program, model, simulation, or replay procedure that produces the result.
Checker: the independent tool, version, configuration, and limits used for acceptance.
Boundary: what the result establishes, what it leaves unresolved, and which real-world conditions could invalidate the mapping.
Authority: the person or institution responsible for deciding whether the checked result is fit for use.

These fields separate a checked claim from a claim merely accompanied by technical vocabulary. They also let an institution inherit the work. A new researcher can rerun the checker. A new engineer can test whether a change preserves the invariant. A public body can ask which assumptions made a safety statement true. A second model can propose a revision while the acceptance boundary remains independent of the model that generated it.

Agents need acceptance boundaries

Agent runtimes are becoming capable of planning, coding, running tools, and handing work to other processes. Google’s public description of ADK Go 2.0 names graph workflows, human-in-the-loop orchestration, dynamic routing, retries, and resilience. Google’s A2A material describes secure autonomous handoffs. These primitives can move a technical task through a system, but movement is not validity.

An agent that writes a numerical method should be able to attach tests for its invariants. An agent that changes a database migration should produce a replayable check for schema compatibility and rollback. An agent that proposes a scientific result should identify which claims are formally verified, which are numerically supported, and which remain interpretive. The next agent should receive the acceptance boundary with the artifact instead of receiving only a confident summary.

This creates a practical architecture:

The generator proposes a claim and declares the assumptions it used.
A formalizer translates the relevant part into a theorem, type contract, invariant, test, or reproducible computation.
An independent checker accepts, rejects, or returns an unresolved obligation.
A human authority decides whether the checked result is fit for the institution’s purpose.
The record preserves the claim, context, checker result, decision, and later corrections.

The checker protects judgment from carrying the whole burden of memory and arithmetic. The machine may propose faster than a specialist can read, while the acceptance boundary keeps the institution from treating fluency as evidence.

Formal methods meet African scientific sovereignty

Scientific sovereignty requires the ability to test claims with instruments an institution can inspect and maintain. Imported intelligence without local verification leaves the final authority elsewhere. A research center may receive a model’s result, yet lack the formal environment, compute, language resources, or technical staff needed to reproduce the claim. That is access without control.

African institutions can build a different position by treating proof infrastructure as shared capacity. Universities and laboratories can maintain formal libraries for local mathematics, engineering standards, public-service rules, agricultural models, language technologies, and payment protocols. They can train researchers to move between empirical evidence and formal representation. They can publish benchmark problems whose assumptions reflect local environments rather than only imported examples.

This work also demands linguistic care. Formalization often appears language-neutral because symbols travel well. The choice of what becomes a variable, a category, a legal condition, or an admissible exception still reflects an institution’s concepts. A water-allocation model, a land record, a clinical protocol, or a cooperative rule may encode relationships that general-purpose datasets do not represent. The proof can be valid while the model of the institution remains incomplete.

NIST’s AI Risk Management Framework gives this architecture a general vocabulary through Govern, Map, Measure, and Manage. Govern assigns responsibility for the claim and its acceptance. Map identifies the people, data, systems, and obligations represented by the formal context. Measure records failed checks, unresolved obligations, reproduction cost, and the difference between formal validity and field performance. Manage defines what happens when an assumption changes, a checker is upgraded, or a result is later challenged.

Where the investable surface is widening

If machine-generated technical work becomes common, capital should examine the infrastructure that makes acceptance portable and measurable:

Proof-carrying generation: model and agent systems that produce claims alongside formal obligations, tests, contracts, or replay instructions.
Verification runtimes: managed environments that execute proof checkers, type systems, model checkers, simulations, and reproducibility jobs with declared versions and limits.
Formalization services: tools and expert systems that translate natural-language requirements, scientific hypotheses, and software specifications into checkable representations.
Evidence-to-proof registries: records connecting empirical data, formal assumptions, checker output, human acceptance, and later correction.
Sovereign verification infrastructure: local libraries, benchmark suites, training systems, and compute that let institutions verify imported machine work without surrendering the acceptance layer.

The underwriting question is precise: does the product reduce the cost of deciding whether a machine-generated claim is fit for use? Useful measures include checker coverage, unresolved-obligation age, reproduction time on an independent environment, false-acceptance rate, percentage of releases carrying executable contracts, and the share of proof records that remain portable after a model or provider changes.

This is different from an experiment ledger. The ledger preserves what a laboratory tried and learned. It is also different from provenance infrastructure, which preserves where an artifact came from. Proof infrastructure narrows the acceptance boundary itself. It tells the institution which proposition, invariant, or contract has been demonstrated under which formal conditions, and where human judgment must continue.

Build the acceptance boundary before scaling output

An institution can begin with one class of work where error is expensive and the claim can be stated clearly:

Choose the proposition, safety property, interface contract, or calculation that must survive review.
Write the assumptions and define which real-world observations connect the formal object to the institution’s purpose.
Require the generator to produce a checker input, test, proof obligation, or replay procedure with the output.
Run the acceptance process in an environment independent of the generator and preserve failed attempts as evidence.
Measure the gap between formal acceptance and field performance, then revise the model rather than hiding the gap.

This is how institutions can use stronger machines without granting them final authority. A result earns its place by carrying a path to challenge. The proof must survive the machine because the future laboratory, software system, and public institution will inherit claims from systems that no human can fully remember. Their freedom will depend on whether they can still test what they receive.

Sources

La preuve doit survivre à la machine

Une réponse fluide peut convaincre une personne pendant un instant. Un artefact de preuve peut permettre à une institution de décider si cette réponse mérite d’entrer dans sa mémoire, son logiciel, son laboratoire ou son dossier public. À mesure que les modèles produisent un travail toujours plus technique, la couche rare se déplace de la génération vers l’acceptation indépendante : un vérificateur qui examine l’affirmation, rejette une dérivation défectueuse et rejoue le résultat dans des conditions déclarées.

Le flux RSS d’OpenAI a porté deux signaux pertinents le 8 septembre. Le premier décrivait GPT-5.6 Sol avec Codex exécutant de manière autonome des expériences de calcul quantique, analysant les résultats et calibrant des qubits. Le second décrivait une solution générée par l’IA au problème du prix du millénaire de Navier–Stokes, accompagnée d’un exposé et d’une preuve formelle en Lean. Ces descriptions fournies par l’entreprise ne constituent pas des confirmations indépendantes de la justesse scientifique des affirmations, mais elles identifient un changement de l’objet produit : on demande au système de créer un travail technique qui peut être vérifié par un langage formel plutôt qu’admiré comme une prose convaincante.

La sortie mûre d’une machine de raisonnement est une affirmation qui porte son propre chemin vers le rejet.

La persuasion et la vérification ont des économies différentes

La revue humaine est puissante, mais elle est aussi rare, contextuelle et inégale. Un chercheur peut reconnaître une erreur familière. Un ingénieur peut inspecter une implémentation. Un mathématicien peut trouver une hypothèse non dite. Ces formes de jugement restent nécessaires parce que les systèmes formels ne couvrent que ce qui a été spécifié. Leur coût augmente lorsque la machine produit plus de résultats candidats qu’un spécialiste ne peut en lire.

La vérification formelle modifie la division du travail. Un assistant de preuve vérifie qu’une proposition découle de définitions déclarées et de règles acceptées. Un vérificateur de types peut rejeter un programme qui viole un contrat. Un model checker peut examiner si un système à états finis atteint une condition interdite. Un exécuteur de reproductibilité peut comparer un résultat dans un environnement fixé. Chaque instrument réduit l’espace où l’erreur fluide peut se cacher.

La distinction compte pour l’investissement. Un endpoint de modèle vend la possibilité d’une réponse. Un système de preuve vend une limite autour de ce qui peut être accepté. Le second objet peut entrer dans les achats, les releases, la recherche et la régulation parce qu’il crée une décision observable : accepté sous ces hypothèses, rejeté par ces tests ou non résolu parce que la formalisation reste incomplète.

Une preuve est une affirmation institutionnelle exécutable

Le projet public Lean décrit un langage et un prouveur de théorèmes pour formaliser les mathématiques et écrire des programmes dont les propriétés peuvent être vérifiées. Sa portée pour le travail assisté par machine est architecturale. La preuve est conservée dans une forme qu’un autre vérificateur peut traiter. L’institution n’a pas à faire confiance à la mémoire de l’auteur pour chaque inférence. Elle peut examiner la proposition, les définitions importées, les tactiques ou les termes, l’environnement et le résultat du vérificateur.

Cela ne rend pas la preuve formelle automatique ni universelle. Un théorème peut formaliser la mauvaise question. Un modèle peut encoder une hypothèse injustifiée comme axiome. Une preuve peut établir une proposition étroite que les lecteurs élargissent à tort en conclusion générale. Le vérificateur garantit une relation dans le système formel ; les personnes décident encore si ce système représente le monde qui les intéresse.

Un dossier de preuve utile doit donc porter davantage qu’un statut vert :

Affirmation : proposition, contrat, invariant ou propriété de sécurité exacte examinée.
Contexte formel : définitions, axiomes, hypothèses de données, environnement, dépendances et identifiants de version.
Dérivation ou test : terme de preuve, programme, modèle, simulation ou procédure de rejeu qui produit le résultat.
Vérificateur : outil indépendant, version, configuration et limites utilisés pour l’acceptation.
Frontière : ce que le résultat établit, ce qu’il laisse en suspens et les conditions réelles qui pourraient invalider la correspondance.
Autorité : personne ou institution responsable de décider si le résultat vérifié peut être utilisé.

Ces champs séparent une affirmation vérifiée d’une affirmation simplement accompagnée d’un vocabulaire technique. Ils permettent aussi à une institution de recevoir le travail. Un nouveau chercheur peut relancer le vérificateur. Un nouvel ingénieur peut tester si une modification conserve l’invariant. Une autorité publique peut demander quelles hypothèses ont rendu vraie une déclaration de sécurité. Un second modèle peut proposer une révision tandis que la limite d’acceptation reste indépendante du modèle qui a généré le résultat.

Les agents ont besoin de limites d’acceptation

Les runtimes d’agents deviennent capables de planifier, coder, utiliser des outils et transmettre un travail à d’autres processus. La description publique par Google d’ADK Go 2.0 nomme les workflows en graphe, l’orchestration avec humain dans la boucle, le routage dynamique, les nouvelles tentatives et la résilience. Les documents de Google sur A2A décrivent des transferts autonomes sécurisés. Ces primitives peuvent déplacer une tâche technique dans un système, mais le mouvement n’est pas la validité.

Un agent qui écrit une méthode numérique devrait pouvoir joindre des tests pour ses invariants. Un agent qui modifie une migration de base de données devrait produire un test rejouable de compatibilité du schéma et de retour arrière. Un agent qui propose un résultat scientifique devrait distinguer les affirmations vérifiées formellement, celles soutenues numériquement et celles qui restent interprétatives. L’agent suivant devrait recevoir la limite d’acceptation avec l’artefact plutôt qu’un simple résumé confiant.

Cela crée une architecture pratique :

Le générateur propose une affirmation et déclare les hypothèses utilisées.
Le formaliseur traduit la partie pertinente en théorème, contrat de type, invariant, test ou calcul reproductible.
Un vérificateur indépendant accepte, rejette ou renvoie une obligation non résolue.
Une autorité humaine décide si le résultat vérifié convient à la finalité de l’institution.
Le dossier conserve l’affirmation, le contexte, le résultat du vérificateur, la décision et les corrections ultérieures.

Le vérificateur protège le jugement contre la charge entière de la mémoire et de l’arithmétique. La machine peut proposer plus vite qu’un spécialiste ne peut lire, tandis que la limite d’acceptation empêche l’institution de confondre fluidité et preuve.

Les méthodes formelles et la souveraineté scientifique africaine

La souveraineté scientifique exige la capacité de tester les affirmations avec des instruments qu’une institution peut inspecter et maintenir. Une intelligence importée sans vérification locale laisse l’autorité finale ailleurs. Un centre de recherche peut recevoir le résultat d’un modèle tout en ne possédant ni l’environnement formel, ni l’infrastructure de calcul, ni les ressources linguistiques, ni les équipes techniques nécessaires pour le reproduire. C’est un accès sans contrôle.

Les institutions africaines peuvent prendre une autre position en considérant l’infrastructure de preuve comme une capacité partagée. Universités et laboratoires peuvent maintenir des bibliothèques formelles pour les mathématiques locales, les normes d’ingénierie, les règles de service public, les modèles agricoles, les technologies linguistiques et les protocoles de paiement. Ils peuvent former des chercheurs capables de passer des preuves empiriques à la représentation formelle. Ils peuvent publier des problèmes de référence dont les hypothèses reflètent des environnements locaux au lieu de reproduire seulement des exemples importés.

Ce travail demande également une attention linguistique. La formalisation semble souvent neutre parce que les symboles circulent facilement. Le choix de ce qui devient une variable, une catégorie, une condition juridique ou une exception admissible reflète encore les concepts d’une institution. Un modèle de répartition de l’eau, un registre foncier, un protocole clinique ou une règle coopérative peut encoder des relations que les jeux de données généraux ne représentent pas. La preuve peut être valide tandis que le modèle de l’institution reste incomplet.

Le cadre de gestion des risques liés à l’IA du NIST fournit une terminologie générale avec Govern, Map, Measure et Manage. Govern attribue la responsabilité de l’affirmation et de son acceptation. Map identifie les personnes, données, systèmes et obligations représentés par le contexte formel. Measure consigne les vérifications échouées, les obligations non résolues, le coût de reproduction et l’écart entre validité formelle et performance sur le terrain. Manage définit ce qui arrive lorsqu’une hypothèse change, qu’un vérificateur est mis à niveau ou qu’un résultat est contesté.

Où la surface d’investissement s’élargit

Si le travail technique généré par machine devient courant, le capital doit examiner l’infrastructure qui rend l’acceptation portable et mesurable :

Génération porteuse de preuve : systèmes de modèles et d’agents qui produisent des affirmations avec des obligations formelles, des tests, des contrats ou des instructions de rejeu.
Runtimes de vérification : environnements gérés qui exécutent des prouveurs, systèmes de types, model checkers, simulations et tâches de reproductibilité avec des versions et limites déclarées.
Services de formalisation : outils et systèmes experts traduisant les exigences en langage naturel, hypothèses scientifiques et spécifications logicielles en représentations vérifiables.
Registres de la preuve et des données : dossiers reliant données empiriques, hypothèses formelles, sortie du vérificateur, acceptation humaine et correction ultérieure.
Infrastructure de vérification souveraine : bibliothèques locales, suites de référence, systèmes de formation et calcul permettant aux institutions de vérifier un travail machine importé sans céder la couche d’acceptation.

La question de souscription est précise : le produit réduit-il le coût de décider si une affirmation générée par machine peut être utilisée ? Les mesures utiles comprennent la couverture du vérificateur, l’âge des obligations non résolues, le temps de reproduction dans un environnement indépendant, le taux de fausses acceptations, la proportion de releases portant des contrats exécutables et la part des dossiers de preuve qui restent portables après un changement de modèle ou de fournisseur.

Il s’agit d’un objet différent d’un registre d’expériences. Le registre conserve ce qu’un laboratoire a essayé et appris. Il se distingue aussi de l’infrastructure de provenance, qui conserve l’origine d’un artefact. L’infrastructure de preuve resserre la limite d’acceptation elle-même. Elle indique à l’institution quelle proposition, quel invariant ou quel contrat a été démontré dans quelles conditions formelles et où le jugement humain doit continuer.

Construire la limite d’acceptation avant d’augmenter la production

Une institution peut commencer par une catégorie de travail où l’erreur coûte cher et où l’affirmation peut être formulée clairement :

Choisir la proposition, la propriété de sécurité, le contrat d’interface ou le calcul qui doit résister à la revue.
Écrire les hypothèses et définir les observations réelles qui relient l’objet formel à la finalité de l’institution.
Exiger du générateur qu’il produise avec la sortie une entrée de vérificateur, un test, une obligation de preuve ou une procédure de rejeu.
Exécuter l’acceptation dans un environnement indépendant du générateur et conserver les tentatives échouées comme preuves.
Mesurer l’écart entre acceptation formelle et performance de terrain, puis réviser le modèle au lieu de cacher cet écart.

C’est ainsi que les institutions peuvent utiliser des machines plus puissantes sans leur accorder l’autorité finale. Un résultat mérite sa place lorsqu’il porte un chemin vers la contestation. La preuve doit survivre à la machine parce que le laboratoire, le logiciel et l’institution publique de demain hériteront d’affirmations provenant de systèmes dont aucun humain ne pourra retenir toute l’histoire. Leur liberté dépendra de leur capacité à tester ce qu’ils reçoivent.