CVN-N001-EI-S05 — Economic metrics + θ-curves (Block 4) · hub Story¶
Hub documentaire de la Story S05 (diagnostic
s43, généralisation du statut C — tradabilité du signal). Partie du programme CVN-N001-EI. État live = OpenProject (wp#228, GH #1060, ADR-76).
En une phrase¶
Le signal ML est-il tradable net de frais, à un rythme déployable, pour LightGBM / XGBoost / CatBoost ? (généralise le « non » établi sur CatBoost.)
RÉSULTAT (2026-06-09, v2) —
C_FRAGILE_TO_SELECTION/ STOP — STATUT : STOP pending S09, PAS de clôture, PAS d'ABANDON. Le gate tient mais repose sur le replay s18 que A6 a flaggé FAIL 5/5 → interprétation suspendue jusqu'à S09. Pas d'edge robuste à la sélection + inner-significatif + non-dégénéré à coût nul (portfolio STOP correct). Le par-crypto (miné sans nouveau run) montre que la queue haute-confiance semble discriminer sur le draw récent (précision 0.29–0.41 à rate 10–16%) — mais tenu au même standard que l'axe config, c'est un cherry-pick post-hoc : 1/10 cellules inner-significatives = niveau du hasard, draw récent non-représentatif (selection p_pos≈0), gross + binary-M. → hypothesis-generating, pas une cible ; absence-of-evidence dans les deux sens (ni « tradable UNI/ARB », ni « signal mort »). Candidat à tester (high-power pré-enregistré) = mécanisme de queue générique (meta-labeling/EK), pas les cellules post-hoc. Bornes : GBDT (ex-XGBoost), fold-3, gross. → Rapport d'expérience v3 (pour revue).
Les documents (dans l'ordre de lecture)¶
| # | Document | Quoi | Pour qui |
|---|---|---|---|
| 1 | Plan dossier (r2.7) | le quoi & pourquoi — problématisation (non-tech), user stories, hypothèses, état de l'art, méthode statistique, règles de décision pré-enregistrées. Committee plan_review PASSED. |
décideur, quant, relecteur |
| 2 | Architecture (r1.1) | le comment c'est construit — Hamilton-native 2-couches, graphe de nodes, contrats d'interface, transport cross-pod, conformité ADR. | ingénieur, archi |
| 3 | Runbook opérateur | le comment on s'en sert — déclencher, lire le verdict, troubleshooting, gate coût. | opérateur |
| 4 | Stratégie de tests | le comment on le valide — pyramide, table de décision exhaustive, invariants, validation système. | dev, QA |
| 5 | §0bis de cadrage + re-plan r3 (2026-06-04) | RETOUR AU PLAN — le §0bis (ADR-0098, leçons S04) a trouvé un mis-cadrage régime+fold avant tout merge/run : la config « déployée » est un processus stochastique (pas un snapshot), s43 ne rejoue qu'un fold + n'évalue pas le funnel. Restructure le round. |
quant, relecteur |
| 6 | Fiche de décision — exclusion XGBoost (2026-06-05) | ✅ DÉCIDÉE (A) — read-only MLflow pré-merge : XGBoost n'a que des essais par-trial (1927/crypto), zéro archive par-cycle → non-évaluable. Gate sur LGB+CB (les deux avec distributions de sélection fidèles). + les 2 bornes de verdict (familles évaluables ; classe GBDT). | décideur, opérateur |
| 7 | MLOps readiness | à remplir au merge de l'impl (ADR-70) | DRI |
État¶
In progress → In specification — RETOUR AU PLAN (r3) (2026-06-04, edge backward ADR-81 --force, motif = §0bis ; OP wp#228 = SSoT, transition loggée). Le §0bis de cadrage (dossier) — premier test rétroactif d'ADR-0098 sur une Story planifiée avant les leçons S04 — a trouvé, probes encore stubs (rien de figé) :
- régime modèle : HP non décidés → risque trou-s42 ; régime éval : E(θ) mesure le modèle+seuil, pas le funnel de déploiement ;
- fold : s43 rejoue fold-3 seul, bootstrap cross-crypto within-fold → zéro cross-fold (même vulnérabilité que num_leaves) ;
- trouvaille qui dépasse s43 : la config « déployée » est instable (lr 0.098–0.146, nl 27–59 par crypto d'un cycle à l'autre) → pas de « modèle déployé », un processus qui re-tire ; le tirage-de-config devient un 3ᵉ axe de robustesse (cross-tirage), territoire S11.
Round r3 (cheap-avant-cher) : régime (b) — un tirage par crypto depuis son propre set (sélection par-crypto, pas d'appariement rang cross-crypto) → pré-filtre cross-tirage sur fold-3 pinné (gate) → multi-fold {2,3,4} conditionné → re-label M (quantité distincte) → baseline coût réel → couture θ hors-gate. La couche stats/décision de s43 reste saine.
r3 (b) ratifié + implémenté (2026-06-05, opérateur « go ») — le cœur compute+acquisition est bâti et testé localement (114 tests s43, dont entraînement lightgbm réel + parité fast-envelope) :
- gate pur (cross_draw_prefilter, règle robuste-cross-tirage pré-enregistrée, verdicts pré-nommés PASS_PROCEED_MULTIFOLD/C_FRAGILE_TO_SELECTION/INCONCLUSIVE_CONFIG_UNSTABLE) ;
- selection bootstrap imbriqué (externe=sélection / interne=(crypto,sub-block)) + envelope vectorisé (parité fast==sound, 57s→3.4s) ;
- acquisition régime (s43_regime : énum MLflow + train-sur-best_params + glue) avec couture durcie (fallback jamais silencieux : audit par-tirage + exclude-and-count, couverture-audit = surface resolve() complète, pinned_resolve pour les fixes-résolus) ;
- DAG restructuré (per-crypto acq isolée → group gate avec assertion-complétude K_eff) + transport cross-pod (npz keyé (crypto,fold,family,run_id)) ; scaffold probe vestigial retiré.
Prochaine étape (in-pod) : la checklist de validité §2bis du runbook (tags MLflow, complétude params, dérive early_stopping, valeurs env, parquets fold-3 self-describing, coût réel mesuré) = la barrière avant le run décisionnel — le mock vert ≠ validé (leçon S03). Puis : merge PR #1096 → deploy → dry-run smoke → run gate fold-3. In specification → In progress au merge.
Carte de traçabilité¶
problématisation (plan Ch.1) → user stories (Ch.2) → hypothèses (Ch.3) → état de l'art (Ch.4) → consolidation (Ch.5) → sections techniques (§0-§7) → architecture → runbook → tests. Aucun fil ne dangle (matrice plan Ch.5.A).