M5: la jambe brute d'agregation n'a que 2 etats — 2 consommateurs comblent le trou a la main, avec 2 regles differentes #14388

Relevé en réparant #14359 (review préflight de myia-po-2025:CoursIA-2, pullrequestreview du 2026-09-02T20:43Z). La jambe de-biaisée de M5 a désormais quatre états, dont NO BEATS — c'est ce que la review demandait, et c'est livré. La jambe brute en garde deux, et l'asymétrie est assumée dans cette PR plutôt que corrigée en silence. Voici pourquoi, et ce qu'il faudrait pour la lever.

L'état actuel, mesuré

scripts/hmm_regime_vol.py :

agg_verdict = "BEATS" if n_beats == n_seeds else "INCONCLUSIVE"   # jambe brute : 2 états
agg_verdict_centered = _aggregate_debiased_state(...)             # jambe recentrée : 4 états

La jambe brute ne peut donc pas dire « le modèle perd ». Deux consommateurs comblent le trou à la main, chacun à sa façon :

Le notebook énonce la convention en toutes lettres dans sa cellule 3 : « la convention du JSON : BEATS exige 4/4 seeds, sinon INCONCLUSIVE ». Ce n'est pas un bug qu'il ignore — c'est un contrat publié dont il dérive sa propre lecture.

Pourquoi ce n'est pas folded dans #14359

Deux raisons, dans cet ordre :

1. La review porte sur aggregate_verdict_debiased, nommément — les quatre NO BEATS publiés sont tous sur la jambe recentrée. Élargir la jambe brute dans le même geste dépasse la réserve et mélange deux contrats.
2. Ça casserait des sorties commitées. Sur une grille identique, ETH h=10 (4/4 BEATEN brut) passerait de INCONCLUSIVE à NO BEATS : n_inc du notebook perd 1, et sa branche DEGRADE — conditionnée sur == 'INCONCLUSIVE' — cesse de tirer pour cette ligne. Les compteurs imprimés dans les sorties commitées deviennent faux sans qu'aucune cellule ne lève. C'est le cas exact que C.2 + Stop & Repair interdisent de laisser passer : il faut re-générer l'artefact (~609 s CPU) puis ré-exécuter le notebook, pas rafistoler la prose.

Les trois autres lignes (2/4 et 3/4 BEATEN) resteraient INCONCLUSIVE même après l'élargissement, puisque la règle est l'unanimité : la table Cycle 25 continuerait de diverger du champ. C'est le vrai fond du sujet — la table publie une lecture majoritaire, le champ appliquerait une règle d'unanimité, et personne n'a jamais tranché laquelle des deux fait foi.

Ce que demanderait la levée

1. Trancher la question de fond : le verdict agrégé brut est-il unanime (cohérent avec la jambe recentrée et avec BEATS) ou majoritaire (cohérent avec la table Cycle 25) ? Une seule des deux, écrite une fois.
2. Réutiliser _aggregate_debiased_state — ou en extraire la partie commune — plutôt que d'écrire une seconde machine d'états. Deux machines qui doivent s'accorder finissent par diverger.
3. Re-générer scripts/results/m5_hmm_regime.json avec le code neuf, puis ré-exécuter m5_hmm_regime_research.ipynb et committer ses sorties (C.2). Ne pas éditer les compteurs imprimés à la main (Stop & Repair, secrets-hygiene règle 6).
4. Aligner la table « Per-coin results » de docs/M5_HMM_REGIME.md sur la règle retenue, en disant explicitement si une ligne change de libellé et pourquoi.
5. Contrôle négatif obligatoire, dans les deux sens : une config 3/4 BEATEN doit rester hors de l'état de perte sous la règle d'unanimité — et y entrer sous la règle majoritaire. Un test qui ne montre pas la bascule ne teste pas la règle.

Ce que ce n'est pas

Ce n'est pas une réouverture de la réserve de #14359 : elle portait sur aggregate_verdict_debiased, qui a maintenant ses quatre états, ses six verdicts publiés rejoués depuis le code, et ses contrôles négatifs 3/4 des deux côtés. C'est le pan voisin, sur un champ différent, avec un coût de ré-exécution que la PR de bias-audit n'avait pas à porter.

See #1454, #14359, #12788.