Skip to content

s43 — §0bis de cadrage (ADR-0098) + re-plan r3

Story : CVN-N001-EI-S05 (wp#228, GH #1060). Statut → RETOUR AU PLAN (le §0bis a trouvé un mis-cadrage régime+fold avant tout merge/run — discipline ADR-0098/0099, leçons S04). Premier vrai test rétroactif d'ADR-0098 : S05 a été planifié avant les leçons S04.

1. Verdict §0bis — s43 ne part PAS au merge/run tel quel

Lecture read-only (s43_io, s43_nodes, s43_economic_tradability, archi r1.1, MLflow). Chance : les probe_* sont des stubs → le régime n'est pas figé, on le pose correctement maintenant.

Axe Trouvaille Statut
Régime — modèle la probe entraînerait un modèle sur le fold capturé, HP non décidés (stub) → risque HP-fixés = trou s42 à poser (cf. §3.0)
Régime — chemin d'éval E(θ) = précision brute du modèle au seuil θ — PAS le funnel de déploiement (9 filtres). M = tradabilité modèle+seuil, pas funnel re-labelliser (§3.3)
Fold s43_io rejoue fold-3 SEUL ; bootstrap clusterisé sur (crypto, sub-block) = cross-crypto within-fold, ZÉRO cross-fold. ci_low règle le winner's-curse sur θ, pas sur le fold → même vulnérabilité que num_leaves multi-fold à ajouter (§3.2)
Coût bande de sensibilité ±50% présente (bien), mais le baseline cost_atr doit être réel-mesuré : faux coûts → E(θ) change de signe → faux positif d'existence gate de cadrage (§3.4)

Correction importante (vs ma 1ère lecture) : M (modèle+seuil) n'est ni majorant ni minorant de la tradabilité funnel. Un funnel sélectif — meta-label (López de Prado : filtre secondaire fait pour monter la précision) + kelly (sizing) — est conçu pour RELEVER l'edge. M est une quantité distincte que le funnel peut bouger dans les deux sens. Labelliser M « majorant » sous-estimerait le funnel et mal-cadrerait la couture.

2. La trouvaille qui dépasse s43 — le déploiement est un processus stochastique

Lecture MLflow (Sprint7 LGB defi, objectif f1_buy) : la config « déployée » est instable. Par crypto, le best HPO change à chaque cycle :

UNIUSDC (n=12) : lr ∈ {0.098, 0.119, 0.122, 0.130}, nl 27, n_est 156
LDOUSDC (n=8)  : lr ∈ {0.093, 0.109, 0.145}, nl 59, n_est 282
(pas de dimension fold dans MLflow → prod re-train par-crypto sur fenêtre roulante, pas par-fold)

→ Il n'y a pas de « modèle déployé » : le déploiement re-tire un modèle matériellement différent à chaque re-train. Conséquences :

  1. « Plus récent » sous-spécifie le régime — c'est UN tirage du processus, pas le processus. L'objet fidèle = la distribution des configs.
  2. Le tirage-de-config est un TROISIÈME axe de robustesse pour M — à côté du cross-crypto (sub-blocks) et du cross-fold (parade S04). Pas du scope-creep : S05 = « tradability generalization », et « généraliser » inclut « à travers la config que la HPO tire ». On a déjà ~7–12 tirages/crypto en MLflow.
  3. L'instabilité de sélection est en soi une trouvaille programme (territoire S11) — possiblement plus importante que l'edge d'un snapshot : un déploiement instable est un problème quel que soit l'edge d'un tirage.

Méta-pattern → formalisé : chaque §0bis du fil révèle que le déploiement est une cible mouvante et stochastique que le diagnostic suppose statique. Principe : « mapper le régime = mapper sa distribution, pas un snapshot ». Formalisé comme clause opérationnelle d'ADR-0098 (Invariant 5) — gate item en 2 temps : (i) détecter si le déploiement re-sélectionne l'artefact à chaque cycle (lecture MLflow de la stabilité de sélection) ; (ii) si oui, caractériser la métrique sur un échantillon de la distribution, pas un tirage. Scopée au régime (quel artefact le diagnostic consomme) ; conclure d'un snapshot au niveau verdict = territoire ADR-0099. (Pas de 5ᵉ ADR : raffinement de « régime » dans 0098, pas une décision neuve — éviter l'ADR-creep.) Note : « fold » est un construct du diagnostic (absent de prod) — valide comme proxy de robustesse temps/régime, pas comme unité de déploiement.

2bis. M dans la chaîne de proxies — s43 teste le rung f1_buy → économique (A0)

Ce que le dossier ne disait pas, et qui change la portée de s43. M = précision·tp − (1−précision)·sl − cost est une espérance nette par-trade : magnitude- et coût-consciente. Elle monte donc d'un rung dans la chaîne A0 :

f1_buy (classif, magnitude-aveugle)  <  M (net par-trade, magnitude+coût)  <  valeur portefeuille
                                     └── rung testé par s43 ──┘   └── couture due (étape 3) ──┘

Or l'item 0 entraîne les modèles sélectionnés par la HPO f1_buy. Donc s43 évalue les modèles que f1_buy a choisis, sur une métrique plus économique que f1_buy → s43 est, en partie, un test du rung f1_buy → M (le maillon ouvert de A0, ADR-0099 Inv 2).

Ce qu'un négatif veut dire (avec la retenue S04). Si les modèles f1_buy-sélectionnés ont M ≤ 0 (au meilleur θ, puisque M = maxθ), ce qui est montré = « le chemin f1_buy-sélectionné n'a pas d'edge net » — même au θ optimal (s43 donne à chaque modèle son meilleur θ, donc il écarte la mis-sélection de θ). C'est le fait décision-pertinent pour le programme, et l'evidence (bornée) que s43 porte sur le rung A0. ⚠️ Ne PAS sur-attribuer en « f1_buy est un mauvais proxy » : ça inviterait la lecture « f1_buy mis-classe, un meilleur critère existe » — que s43 n'établit pas, car il n'évalue que des HP f1_buy-sélectionnés (il écarte la mis-sélection de θ, pas celle des HP). Attribuer spécifiquement à « f1_buy mis-sélectionne » exigerait une comparaison à des HP M-optimaux (hors-scope). Donc : « pas d'edge économique via le chemin f1_buy » (montré) ; l'ambiguïté mis-sélection-HP vs pas-d'edge est notée, non tranchée (même discipline que le « pas de support ≠ ça nuirait » de S04). Inversement, M→portefeuille (fréquence de trade, corrélation cross-crypto, sizing/kelly, compounding — étape 3) reste la couture due non testée ici. → s43 contribue à la question fondamentale du programme, pas seulement à la tradabilité de S05.

3. Re-plan r3 (round, ordre cheap-avant-cher — le pattern A-gate-B de S04)

0. Régime = (ii) raffiné — train-sur-best_params-prod, sur un ÉCHANTILLON de tirages. Par crypto, lookup MLflow des K best_params (pas le plus récent seul) ; train une fois par (crypto, tirage) — pas de re-search HPO (préserve read-only, cheap), fidèle au processus déployé. (Exclu : (i) re-run HPO = cher + tension read-only ; (iii) HP-fixés = trou s42.)

1. Pré-filtre cross-tirage sur fold-3 (PINNÉ, cheap) — GATE du multi-fold. Évaluer M pour les K tirages par crypto sur fold-3 (pas de cold-capture, pas de risque hang ; 5×K fits rapides, minutes). Question : l'edge survit-il à l'instabilité de sélection de la HPO, ne serait-ce que sur un fold ?

Règle de décision PRÉ-ENREGISTRÉE (avant de lire — discipline Q-objectif) — et ROBUSTE cross-tirage, pas « existe-dans-un-tirage ». Le piège : « M ci_low > 0 pour au moins un tirage » refait le winner's-curse sur l'axe tirage (cherry-pick la config qui marche = le piège num_leaves transposé, existence-vs-sélection appliquée à l'axe config). La règle est donc « l'edge tient À TRAVERS les tirages » : - PASS si M.ci_low > 0 pour tous les K tirages (ou une fraction f pré-spécifiée, seuil figé avant lecture) → dépenser le multi-fold (item 2). - C_FRAGILE_TO_SELECTION (négatif pré-nommé) si l'edge n'existe que sur un sous-ensemble < f des tirages → l'edge est un artefact de la variance de sélection HPO, pas une propriété du signal. STOP, sans payer le cold-capture {2,4}. - INCONCLUSIVE_CONFIG_UNSTABLE (inconclusif pré-nommé) si les CI sont trop larges pour trancher PASS vs fragile (sous-puissance). STOP, route « plus de données ».

Nécessaire-non-suffisant. PASS au pré-filtre n'est PAS une evidence cross-fold : fold-3 reste in-sample pour l'axe fold. Les deux axes (tirage, fold) sont indépendants — le gate borne l'axe tirage, l'item 2 borne l'axe fold. Ne pas lire « gate passé » comme « M validé ».

2. Multi-fold {2,3,4} — CONDITIONNÉ au pré-filtre. La parade S04 (filtrage stabilité, orthogonale aux sub-blocks ET à l'axe tirage) : M stable cross-fold ? Gère le cold-capture {2,4} ici (le problème sans-pins de S04), pas avant. Contient le blow-up combinatoire (sinon 5×3×K d'un coup).

3. Re-label M = edge modèle+seuil, quantité distincte (le funnel peut la relever — meta-label/kelly) ; funnel = couture aval due (chaîne A0). Pas « verdict de tradabilité [déploiement] ». Précision tirage↔fenêtre : les K tirages ont leurs best_params optimisés chacun pour sa propre fenêtre roulante (params↔fenêtre↔fold découplés — cohérent avec « fold = construct diagnostic »), appliqués sur fold-3. Donc M se lit « config échantillonnée de la distribution déployée, appliquée au fold diagnostic », pas « la config déployée du fold-3 » (sur-lirait le lien).

4. Baseline coût réel mesuré (Console/PG, pas placeholders) — load-bearing pour la validité du proxy, avant le run décisionnel.

5. Couture θ-atteignabilité — notée HORS-gate. M = maxθ E(θ) au θ in-sample ; déploiement calibre θ OOS (ADR-15) → peut atterrir ailleurs (« edge à un θ que le déploiement ne prend pas » = inexploitable, analogue θ du « 0.025 hors-range »). Lien de transfert dû après*.

4. Conséquences process

  • S05 → retour au plan (statut hub + OP) ; pas de merge/un-draft de PR #1096 tant que r3 n'est pas ratifié + les probes ré-écrites sous le bon régime.
  • La couche stats/décision de s43 (envelope, bootstrap clusterisé, Bonferroni, décision keyée ci_low) est saine — r3 ne la touche pas ; il change l'acquisition du modèle (item 0), ajoute deux axes de robustesse (cross-tirage gate cross-fold), étend la taxonomie de verdicts (C_FRAGILE_TO_SELECTION / INCONCLUSIVE_CONFIG_UNSTABLE pré-nommés — complétude de taxonomie, leçon S04), re-labelle M, et valide le coût.
  • Portée élevée (§2bis) : s43 n'est plus « tradabilité de S05 » seule — il teste le rung f1_buy → M de la chaîne A0 ; un négatif y montre que le chemin f1_buy-sélectionné n'a pas d'edge net (l'ambiguïté mis-sélection-HP-vs-pas-d'edge notée, non tranchée — borne S04) = evidence bornée sur le rung A0 (ADR-0099 Inv 2). À refléter dans le hub Epic (s43 contribue à la question fondamentale).
  • Méta-note durable (§2) formalisée : ADR-0098 Invariant 5 (« mapper le régime = mapper sa distribution » — gate item détecter+échantillonner, scopé régime). S05/s43 = 2ᵉ instance de record.