Les trois étages de vérification.

runward vérifie des décisions d'ingénierie. Il ne vérifie délibérément pas tout : la frontière n'est pas un accident, c'est l'architecture. Une livraison sous runward repose sur trois étages de vérification, chacun avec son responsable, et une seule question décide de l'étage auquel appartient un contrôle :

Ce contrôle doit-il être infalsifiable ?

Étage 1 : les décisions d'ingénierie, la porte déterministe

Ce qui doit être infalsifiable : que les décisions porteuses ont été prises, tracées, prouvées. C'est runward check --strict : des pointeurs de preuve typés qui résolvent vers du contenu réel, des manifestes de conformité aux règles, le sceau contre l'érosion silencieuse. Mêmes entrées, même verdict ; aucun prompt ne peut le convaincre de passer. Il prouve qu'une décision est tracée et pointe vers quelque chose de réel, jamais la qualité du code. Dans le vocabulaire de l'état de l'art, c'est un capteur déterministe au repos : les « deterministic sensors » que recense la littérature exécutent quelque chose (tests, linters, compilateurs) ; celui-ci lit des artefacts au repos et n'exécute rien.

Rien d'autre ne joue ce rôle. Il n'y a pas de « seconde porte ».

Étage 2 : les contrôles mécaniques, les hooks de l'opérateur

Compiler, typer, tester un fichier modifié est déterministe aussi : ce sont les « deterministic sensors » au sens plein du terme, des capteurs qui exécutent. Mais c'est un problème de fichier, pas un problème de mission. Cela appartient à l'outillage propre de l'opérateur : la couture de hooks opt-in autour de la porte, et ce que le harnais de l'opérateur offre (un hook qui lance le typechecker après chaque édition, un contrôle pre-push). Ces contrôles informent et corrigent ; ils ne décident pas d'une phase. Le franchissement de phase reste l'affaire de l'étage 1.

La couture est à runward ; son contenu est à vous.

Étage 3 : le jugement, la revue consultative

Un regard neuf sur un diff, humain ou LLM, a une vraie valeur et il est falsifiable par construction. Il est donc consultatif, jamais bloquant : la revue produit des constats, l'opérateur décide, et si un constat compte durablement il devient de la matière d'étage 1 (un ADR, un pointeur de preuve). La porte peut voir qu'une revue a eu lieu et qu'elle est fraîche ; elle ne lit jamais le verdict. Un contrôle piloté par le modèle est contournable, et un contrôle contournable n'est pas une porte : c'est aussi pourquoi un outil MCP peut découvrir runward mais jamais l'imposer.

Le test de partition

Pour toute nouvelle vérification que vous êtes tenté d'ajouter, demandez dans l'ordre :

1. Est-ce une décision d'ingénierie au niveau mission ? → une règle de l'art plus une preuve dans le manifeste. Étage 1.
2. Est-ce vérifiable mécaniquement sur un fichier ? → un hook. Étage 2.
3. Est-ce du jugement ? → consultatif. Étage 3.

Un contrôle qui semble appartenir à deux étages est presque toujours deux contrôles à séparer. « Le code est-il sécurisé ? », c'est une décision de sécurité tracée (étage 1) plus un scan mécanique (étage 2) plus une lecture d'expert (étage 3) : trois contrôles, trois responsables, une frontière honnête chacun.

Cette partition rejoint le vocabulaire de l'état de l'art : le survey « Code as Agent Harness » (arXiv 2605.18747) nomme la même ligne de partage, « deterministic sensors and human-review gates ». Un survey décrit un paysage, il ne valide pas un produit ; la convergence, elle, se constate.