Fiche de décision — Garde intérimaire sur la sélection f1_buy live¶
- Tracker : GH #1112
- Date : 2026-06-05
- Statut : DÉCIDÉ 2026-06-05 — gel f1_buy-promotion
onpar défaut (§5/§7) ; reste à poser (geste live opérateur) + promouvoir #1112 en OP wp - Origine : committee Meeting OP #250 rec 2 (
EXECUTION_RISK) · fiche économique §8 - Principe : [[feedback_hedge_without_believing]] — hedge sans affirmer ; [[feedback_no_discipline_workflows]] — pas de discipline qui repose sur « se souvenir »
1. Décision à prendre¶
Pendant les semaines C→B (le temps que S12 bâtisse le substrat keyé+coût-validé et que l'analyse B adjuge l'anti-corrélation), quelle exposition garder face à un signal crédible-mais-non-confirmé que sélectionner les modèles par
f1_buypeut détruire de la valeur économique ?
Ce n'est pas la question scientifique (« f1_buy anti-corrèle-t-il ? » → B juge, on n'affirme pas). C'est la question opérationnelle, distincte et co-temporelle.
2. Faits¶
- Aperçu reconnaissance (⚠️ pas un verdict) : sur la tranche post-S19 propre (n=23),
corr(f1_buy, sortino) = −0.54,corr(f1_buy, total_return) = −0.62, avec un mécanisme (over-trade : BUY↑ → f1_buy↑ mais coût↑ → net↓). Confondu (substrat sortino-sélectionné) → peut s'évaporer sur le substrat propre. B est le juge. - Asymétrie : un garde cheap et réversible vs des semaines de composition négative potentielle sur capital réel si le signal tient.
- ADR-2 (pas de promotion auto) : la promotion d'un modèle en live est déjà un geste opérateur délibéré et gaté — il n'y a pas de sélection-par-f1_buy automatique en arrière-plan. Le garde agit donc sur la décision de promotion, pas sur un automate.
- In-observabilité = le risque (gap #4) : aucune observabilité de l'éco réalisée → on ne peut pas voir si la sélection-f1_buy nuit déjà. On hedge ce qu'on ne voit pas — argument pour le garde cheap, pas contre.
- Exclu d'office : « sélectionner par éco simulée » — affirme un critère de remplacement lui-même non-validé (critère 4) et circulaire (le −0.54 vient d'un substrat sélectionné par cette métrique). Haut-regret.
3. Options (faible-regret only)¶
A — Discipline de promotion : veto éco-négatif (doc/checklist)¶
- Quoi : pendant C→B, aucun modèle promu sur
f1_buyseul ; son signe éco-OOS FTF ne doit pas être négatif (veto, pas un nouveau critère de sélection). Inscrit comme item de checklist sur le gate de promotion existant (ADR-2), pas un « pense-à-vérifier » flottant. - Coût : ~nul, déployable immédiatement, zéro changement système-live.
- Hedge sans croire : ✅ un veto sur l'éco-négatif n'affirme aucun critère de remplacement.
- Risque : drift — un veto par-promotion repose sur l'application à chaque geste ([[feedback_no_discipline_workflows]] : « ce qui repose sur se souvenir = drift »). Mitigé seulement si c'est un item dur de la checklist/runbook de promotion, idéalement avec le signe éco surfacé par l'outillage de promotion.
B — Gel des promotions f1_buy¶
- Quoi : geler toute nouvelle promotion de modèle sélectionné f1_buy jusqu'à ce que B adjuge.
- Coût : bloque les déploiements f1_buy pendant C→B (perte d'optionalité de déploiement — nul si peu/pas de promotion prévue sur la fenêtre).
- Hedge sans croire : ✅ un gel n'affirme rien.
- Robustesse anti-drift : ✅✅ un état unique durable, pas un « se souvenir » par-promotion → respecte [[feedback_no_discipline_workflows]] mieux que A.
C — Cap / réduction d'exposition (Console)¶
- Quoi : plafonner l'allocation de capital aux modèles f1_buy-sélectionnés.
- Coût : changement de config Console (ADR-59) ; réduit le pari sans le bloquer.
- Hedge sans croire : ✅. Robustesse anti-drift : ✅ état de config durable. Mais : plus lourd que B à poser, et arbitraire (quel cap ?).
4. Critères de décision¶
- Hedge sans croire — n'affirmer aucun critère de remplacement (élimine la sélection-éco-simulée ; A/B/C OK).
- Faible-regret des deux côtés — cheap si −0.54 s'évapore, protecteur s'il tient.
- Déployable maintenant sans changement live risqué (in-observabilité = le risque → agir vite).
- Pas de discipline drift-prone ([[feedback_no_discipline_workflows]]) — préférer un état unique à un « se souvenir par-promotion ». ⇒ favorise B (et C) sur A.
- Réversible d'un geste quand B adjuge.
5. Recommandation — B (gel), défaut INCONDITIONNEL¶
B (gel) est le défaut quelle que soit la réponse à « des promotions sont-elles prévues ? ». Un gel = réduction d'exposition (on cesse d'ajouter de l'exposition au critère suspect) ; il ne route pas par l'éco simulée (respecte le critère 4 — il pause, il ne dit pas « promeus par sortino ») ; état unique durable, réversible d'un geste, levée nette = verdict B.
Le repli A (discipline) est à l'envers — corrigé. Trois raisons (opérateur, 2026-06-05) : 1. Garde le plus faible dans le cas le plus risqué. « Des promotions sont prévues » est précisément le moment où du neuf f1_buy-sélectionné part en live et (si −0.54 tient) commence à composer. Y mettre le garde faible (A) inverse la logique de risque. 2. « Discipline » contre quoi ? Aucun critère validé n'existe encore (c'est ce que B doit produire). Une promotion « disciplinée » ne peut retomber que sur f1_buy (le suspect) ou l'éco simulée (non-validée, critère 4) → A = théâtre, ou retour silencieux à f1_buy. 3. A est un workflow-de-discipline (« à chaque promotion, applique la discipline ») — exactement ce que [[feedback_no_discipline_workflows]] proscrit. Le principe penche vers le gel aussi dans le cas « promotions prévues ».
Forme correcte — défaut restrictif : gel on par défaut ; si un besoin de promotion surgit → exception documentée, justifiée sur des bases non-f1_buy (rollback known-good, config validée autrement, critère non-suspect), pas un downgrade en mode-discipline. Justifier affirmativement pour promouvoir (restrictif), au lieu de permettre-avec-overlay. L'exception reste rare et délibérée — donc pas un « pense-à-y » récurrent, donc pas un workflow.
Bénéfice de bord : le fait « promotions prévues ? » devient non-porteur — il ne décide plus la force du garde (qui basculerait sur un forecast révisable en cours de fenêtre), seulement si l'exception se déclenche. Plus robuste, et tu n'as pas à attendre le forecast pour poser le garde.
Non retenu : la sélection-par-éco-simulée (critère 1) ; le repli-A-en-défaut (les 3 raisons ci-dessus).
6. Placement + déploiement¶
- Placement : promouvoir #1112 en work package OP (roadmap, pas une issue GH perdable) — l'item devient tracé + décidé + daté, anti-évaporation.
- Deploy-when : maintenant. C'est la seule chose qui ne doit pas attendre le code du substrat (tout le sens d'un garde intérimaire).
- Geste : le déploiement (gel/checklist/cap) touche le live → ton geste (domaine Console/kill-switch/runbook, pas d'implémentation autonome). Je trace l'item décidé/daté + lève le gel quand B rend son verdict.
7. Prochaine action¶
DÉCIDÉ (opérateur, 2026-06-05) : gel f1_buy-promotion, on par défaut, levée = verdict B, exception = justification non-f1_buy documentée. deploy=now, geste live à l'opérateur.
- Je promeus #1112 en OP wp avec cette forme +
deploy=now+ condition de levée (verdict B) — l'item devient tracé + décidé + daté. - Tu poses le geste live (gel) ; je trace l'item décidé/daté + lève le gel quand B rend son verdict.
- Le séquençage code S12 est désormais libre (voir ci-dessous) — PR maintenant.
Séquençage S12 (délégué, à exécuter après le garde) : 1a+1c est auto-contenu —
model_hyperparams+feature_hashdonnent la capacité de join (une ligne est rattachable à sa config + son feature-set) ;optuna_trial_id(1b, différé) est un cross-ref MLflow additif, pas un demi-état à compléter ; l'incrément 2 (baselines) est orthogonal (tablefinetune_baselines, pas le keying definetune_results). Donc pas de demi-keying → PR maintenant (diff reviewable, déféraux 1b/2 déclarés honnêtement), incrément 2 en suivant. (≠ le cas « finis 2 d'abord » : il n'y a pas de demi-état silencieux.)