Conformance

Le dépôt reg-conformance est une suite neutre vis-à-vis de l’implémentation. Elle définit des propriétés — safety, liveness, tolérance aux fautes, I8 — et une interface ConsensusBackend : reserve, commit, release, reconcile, get_state. Elle ne prescrit ni Raft, ni Paxos, ni une base particulière. Tout backend qui tient les propriétés déclarées de son profil est le sujet possible d’une conformance. « Consensus » dans le nom de l’interface désigne un point de coordination d’état, pas forcément un algorithme distribué.

Catalogue

Le README et le document illustratif rapportent les mêmes comptes, vérifiés selon eux par un test indépendant du générateur : 144 combinaisons théoriques, 42 admissibles structurellement (9 mono-processus, 18 mono-hôte, 15 multi-hôtes), 102 rejetées. Les règles R1, R2 et R3 lient le périmètre d’hôte, la concurrence et la déduplication. Un profil qui viole les bornes de résilience est rejeté : pour le crash seul, n ≥ 2f+1 ; pour le byzantin, n ≥ 3m+1.

Lancer

Depuis une copie du dépôt, les commandes documentées sont :

python3 tools/enumerate_configs.py
python3 tools/validate_profiles.py
python3 tests/test_catalog_enumeration.py
python3 tools/verify_effective_guarantees.py

Le runner runner.py se décrit comme suite v0.3.2. Modes : --mode http (adaptateur, niveau de preuve 2), --mode native (noyau en processus, niveau 3), ou les deux. Un résultat doit déclarer interface_mode. Mélanger natif et adaptateur sans étiquette est non conforme au sens de RFC-7. Les états de rapport incluent PASS, FAIL, INCONCLUSIVE, NOT_APPLICABLE, ADAPTER_REQUIRED, IMPLEMENTATION_GAP. INCONCLUSIVE n’est jamais un PASS.

spec.md v0.3.1 dit que le runner enregistre 53 vecteurs, dont 36 vecteurs étendus encore en IMPLEMENTATION_GAP, C4 natif non applicable, CT-R4-009 et CT-R4-010 ouverts. Cette phrase date le périmètre du fichier. L’arbre a continué. Il ne faut pas lire 36 comme le décompte vivant sans relire VECTORS.md.

Validation publiée — 20 octobre 2026

Preuves, au 19 octobre 2026

Les journaux sous evidence/ portent des en-têtes qui disent l’exécution dans l’environnement de l’auteur, pas par un vérificateur indépendant. Le hash prouve que le fichier n’a pas changé depuis l’attestation. Il ne prouve pas que le test a été bien exécuté. deployment.manifest reste, dans les profils lus, une dépendance bloquante : sans lui, un auditeur externe ne relie pas la preuve à l’hypothèse d’hôte.

Le README résume encore certains profils multi-hôtes comme sans preuve, et écrit qu’aucune implémentation de consensus multi-hôte n’existe. Le profil consensus-replicated.yaml du même arbre déclare pourtant RaftConsensusBackend 5.6.0 et pointe des journaux evidence/test-raft-*.log. Ces deux textes ne concordent pas. Les journaux eux-mêmes disent un essaim de 3 nœuds, un modèle de faute sans byzantin, et un auteur plutôt qu’un tiers. Le journal de tenir_governance précise que les nœuds de test utilisent localhost et des ports distincts : ce n’est pas un essai sur un réseau physique multi-hôtes. Le dessin d’architecture ajoute : Raft 5.6.0 n’est pas une preuve de consensus en environnement hostile.

Harnais S1

Le dépôt tenir-conformance-s1-g1, version 0.1.0, est le harnais exécutable S1 G0+G1, « Evidence Lost After Commit ». Sa première ligne dit qu’il n’est pas une validation du REG de production. Le fichier G1 le répète : passer les tests prouve que le harnais satisfait les assertions G0, pas que REG ou TENIR est validé.

STATUS.md est plus précis, et plus étroit. Il dit que les définitions opérationnelles G0 de S1 à S6 ont été confrontées à une membrane de laboratoire RFC-4, pour les entrelacements séquentiels testés, avec des artefacts de CI. Le chemin S1 appelle un vrai PolicyEngine pour le score. Cela n’établit pas la concurrence non contrainte, la vérification cryptographique de production, ni la certification d’une passerelle. La phrase publique qu’il demande de tenir est exactement celle-là.

Limites écrites dans le README du harnais : la clé publique de confiance est fournie par l’appelant ; la rotation et la révocation ne sont pas implémentées ; les postconditions déclarées ne prouvent pas un effet dans le monde ; les engagements S11 sont des artefacts en processus. Lancer le cas S1 :

python -m pytest tests/test_s1.py -v
python tools/run_s1.py

Les niveaux de preuve de la spec — correspondance sémantique, test via adaptateur, conformance native — restent des étiquettes à déclarer. Aucune n’équivaut à un audit indépendant tant que le sujet, la révision et l’environnement ne sont pas épinglés proprement. Le texte de spec.md le dit.