Epic — Protocole de décision de tradabilité (CVN-N001-EK)¶

OP : wp#270 · GH #1161 · parent Need CVN-N001 · statut New (Proposed / Planning).

Filiation¶

Need : CVN-N001.
Prédécesseur : CVN-N001-EI (diagnostic). EI a posé la question de la tradabilité ; cet Epic opérationnalise la décision — il ne refait pas du diagnostic exploratoire.
Source : le cadrage v2 (note transcrite ci-dessous en forme d'Epic).
Couche à ne pas confondre : l'ADR « tradability decision protocol » (les règles durables) est un livrable de S01, pas l'Epic. L'Epic est le programme de travail qui instancie et exécute ces règles.

1. Contexte & justification¶

Le pilote cost-sensitivity (EI) est ressorti inconclusive / sous-puissant (intervalles compatibles avec perte et gain à tout coût), dominé par la dispersion inter-actifs (cinq anecdotes, pas un edge portefeuille). L'historique (tracks ML-boost abandonnés, transfert AUC→f1_buy faible, best_iter=1) rend « encore un sweep exploratoire » dangereux (garden of forking paths). La suite n'est ni « on arrête » (non justifié sur de la sous-puissance) ni « on continue à tâtonner » : c'est un protocole de décision pré-enregistré et falsifiable, avec interdit structurel aucune optimisation aval avant preuve amont.

2. Objectif & définition de succès¶

Le succès de cet Epic est un VERDICT défendable, pas un edge positif garanti. L'Epic fabrique la discipline permettant de conclure, parmi : PROMOTE jusqu'à un edge net déployable, KILL program thesis, ou INFEASIBLE. Un KILL ou un INFEASIBLE proprement obtenu est un succès de l'Epic (décision nette), pas un échec.

3. Thèse-programme sous test (nommée)¶

Il existe un edge directionnel long-only, économiquement tradable au coût conservateur P90 (à la taille d'ordre / capacité visée), porté par le signal d'entrée ML sur defi_top5, avec la famille de label actuelle (triple-barrière ATR, horizon H4) et la classe de modèle actuelle (GBT).

KILL program thesis (budget de familles épuisé sans PROMOTE) ⇒ abandon / sortie de roadmap de cette thèse. Toute bascule (p. ex. cross-sectionnelle / market-neutral) est un Epic séparé à estimand et gates propres, pas une suite de celui-ci.

4. Périmètre¶

Dans le périmètre : la chaîne de gates (Phases 2→6), l'ADR + le charter, la pré-étude quantitative, les registres, et un verdict de niveau Epic.

Hors périmètre : tout déploiement / trading réel ; le filtering / sizing / exécution avant gates franchis ; la thèse cross-sectionnelle (Epic distinct) ; tout usage du holdout final hors PROMOTE ; tout sweep sous couvert de pré-étude.

5. Découpage en Stories¶

Les Stories S05–S08 sont conditionnelles : elles ne s'ouvrent que sur un PROMOTE amont et peuvent ne jamais ouvrir (sur KILL / INFEASIBLE). Ne pas les pré-engager comme travail certain.

Story	Livrable (cadrage)	Contenu	Gate de sortie	Conditionnalité
S01	D1 — ADR + charter (brouillon Phase 0)	produit l'ADR « tradability decision protocol » (règles durables) + charter avec placeholders ; thèse-programme nommée ; frontière long-only / cross-sectionnel ; règles `KILL / ONE-ITERATION / PROMOTE / INFEASIBLE`	revue méthodo	ferme
S02	D2 — Pré-étude quantitative Phase 1	coût P90 (capacité) → `E_econ_min` → mapping → `E_pred_min` ; simulation de puissance → MDE / univers minimal ; null-gate principal (purgé/embargé, conservatism-wins) ; budgets ; résolution R1 Sortino	comité ; `INFEASIBLE` possible	ferme
S03	D3 — Verrouillage du charter (Phase 0 lock)	injection des valeurs D2 ; gel	sign-off conjoint opérateur + méthodo + risk owner ; séparation des rôles (verrouilleur ≠ lanceur) ; trace immuable OP	ferme
S04	D4 — Protocole Phase 2 + run prédictivité	test prédictif contre le null-gate verrouillé ; critère `E_pred_min`/FDR	`PROMOTE` / `ONE-ITERATION` / `KILL tuple` / `KILL family` / `INFEASIBLE`	ferme
S05	Phase 3 — espérance brute (coût 0)	politique d'action figée en validation imbriquée ; label vs politique ; retour ciblé encadré	continue / retour ciblé (consomme un slot)	conditionnelle (sur `PROMOTE` S04)
S06	Phase 4 — survie au coût	espérance nette au coût P90 (capacité) + stress cost	continue / `KILL`	conditionnelle
S07	Phase 5 — filtering / meta-labeling	meta-label sur edge établi (net, pas trade-count)	continue / stop	conditionnelle
S08	Phase 6 — sizing / exécution / portefeuille	sizing, limites, exécution, capacité	—	conditionnelle

6. Gates & issues de niveau Epic¶

Chaîne : prédictivité → espérance brute → survie aux coûts → filtering → sizing/exécution. Issues terminales de l'Epic : PROMOTE-jusqu'au-déployable, KILL program thesis, INFEASIBLE. KILL hiérarchique : tuple → famille → thèse-programme. Registre des tuples tués (anti-résurrection).

Arbre de décision (tuple)¶

L'arbre de décision tuple-par-tuple — vue opérationnelle de la chaîne de gates ci-dessus (PROMOTE / ONE-ITERATION nested-sans-budget / KILL tuple → famille → thèse / INFEASIBLE), avec les règles transverses (holdout 1×/tuple, anti-snooping, structurel = nouveau tuple) — vit sur sa page dédiée : Arbre de décision (tuple).

7. Dépendances & ADR¶

Produit l'ADR « tradability decision protocol » (livrable S01).
S'appuie sur : ADR-0097 (template/Invariant exploratory) ; l'Epic label-embargo (CVN-N001-EA) pour la purge/embargo du null et des folds ; le modèle de coût (instrumentation à mesurer, fin des placeholders) ; OP comme source de vérité (ADR-76) ; chaîne committee→OP (ADR-52/82).

8. Risques & points ouverts¶

R1 — Sortino (porté par S02). Définition / périodicité / MAR / annualisation + base du plancher ~1.0. Bloque tout énoncé « sub-floor » actionnable ; neutralisé dans le constat jusqu'à résolution.
Substrat INFEASIBLE (sortie de S02) : décision à assumer (élargir l'univers/folds), pas un échec.
Data snooping en pré-étude : S02 ne doit pas inspecter d'outcomes tuple-spécifiques pour choisir le tuple ; sinon le choix devient un tuple enregistré et consomme du budget.
Coût mesuré hors régime de capacité : E_econ_min faux si le P90 n'est pas à la taille d'ordre visée.

9. Registres à tenir¶

Tuples enregistrés ; tuples tués ; budget de familles ; budget FDR / multiple-testing ; holdout final (accès datés) ; conditions de réouverture.

10. Gouvernance & frontières¶

Opérateur = Dominique (toutes actions OP / git / runs). Revue méthodologique = peer. D3 exige le sign-off conjoint (opérateur + méthodo + risk owner) avec séparation des rôles. La création du work package OP de cet Epic, l'attribution de l'id, et la liaison « successeur de CVN-N001-EI » sont l'action de l'opérateur — ce document en est la transcription narrative (OP wp#270 créé 2026-06-09).