CVN-N001-EK — Arbre de décision (tuple)¶

Page de l'Epic CVN-N001-EK — Protocole de décision de tradabilité. Source : note de cadrage v2.

Vue opérationnelle de la chaîne de gates de l'Epic (§6 de l'overview), du point de vue d'un tuple enregistré. C'est la grille de décision qui empêche le tâtonnement : à chaque gate, une issue nette, et toute correction est explicitement classée « même tuple » (gratuite) ou « nouveau tuple » (coûte du budget).

Légende¶

• 🟩 Vert — progression / PROMOTE.
• 🟧 Orange — correction en validation imbriquée (même tuple, ne consomme pas de budget).
• 🟦 Bleu — nouveau tuple (coûte 1 slot + 1 unité FDR).
• 🟥 Rouge — KILL tuple → registre des tuples tués (anti-résurrection).
• 🟥 Rouge sombre — KILL program thesis (« pas d'edge tradable dans cette famille »).
• ⬜ Gris — INFEASIBLE : échec par sous-puissance → élargir univers / folds (Phase 1) puis re-tester ; ce n'est pas un nouveau tuple.

Arbre¶

flowchart TD
    A(["Tuple enregistré — test"]):::start --> P2{"Phase 2 — Prédictivité
Bat le null-gate principal
d'au moins E_pred_min (sous FDR) ?"}

    P2 -->|"Oui"| PR["PROMOTE → Phase 3"]:::promote
    P2 -->|"Non — échec par sous-puissance"| INF["INFEASIBLE
Élargir univers / folds (Phase 1)
puis re-tester — PAS un nouveau tuple"]:::infeasible
    P2 -->|"Non — échec réel"| Q1{"Proche du seuil ET
UNE cause diagnostiquée ET
budget ONE-ITERATION dispo ?"}

    Q1 -->|"Oui"| OI["ONE-ITERATION
changer UNE seule coordonnée
pré-payé : 1 slot + 1 unité FDR"]:::iter
    OI --> A
    Q1 -->|"Non"| KT["KILL tuple
→ registre des tuples tués"]:::kill

    KT --> Q2{"Candidat motivé restant
(théorie / exploration cloisonnée / diagnostic)
ET budget de famille > 0 ?"}
    Q2 -->|"Oui"| NT["Tirer un NOUVEAU tuple
depuis le budget de famille"]:::newtuple
    NT --> A
    Q2 -->|"Non"| KP["KILL program thesis
« pas d'edge tradable dans cette famille »"]:::killprog

    PR --> P3{"Phase 3 — Espérance brute > 0 ?
(politique d'action figée
en validation imbriquée)"}
    P3 -->|"Oui"| P4{"Phase 4 — Espérance nette > 0
au coût P90 (capacité) ?"}
    P3 -->|"Non — cause : politique d'action / calibration / seuil"| AP["Corriger EN validation imbriquée
PAS un nouveau tuple"]:::iter
    AP --> P3
    P3 -->|"Non — cause : label mal spécifié"| NTL["NOUVEAU tuple
(coordonnée label change → coûte budget)"]:::newtuple
    NTL --> A

    P4 -->|"Oui"| DOWN["Phase 5 filtering → Phase 6 sizing / exécution"]:::promote
    P4 -->|"Non — re-tuner pour survivre au coût = post-hoc"| KT

    subgraph RULES["Règles transverses"]
        R1["Holdout final : touché UNE fois par tuple, au verdict"]
        R2["Le tuple suivant vient de la théorie / exploration cloisonnée,
JAMAIS du résultat de confirmation (anti-snooping)"]
        R3["Changer une coordonnée structurelle = nouveau tuple = budget
Corriger la seule politique d'action = même tuple (nested)"]
    end

    classDef start fill:#1f2937,color:#fff,stroke:#111827;
    classDef promote fill:#16a34a,color:#fff,stroke:#14532d;
    classDef iter fill:#d97706,color:#fff,stroke:#7c2d12;
    classDef newtuple fill:#2563eb,color:#fff,stroke:#1e3a8a;
    classDef kill fill:#dc2626,color:#fff,stroke:#7f1d1d;
    classDef killprog fill:#7f1d1d,color:#fff,stroke:#450a0a;
    classDef infeasible fill:#6b7280,color:#fff,stroke:#374151;

Lecture rapide¶

• Le seul point d'entrée d'un nouveau tuple est la théorie / l'exploration cloisonnée — jamais le résultat d'une confirmation (anti-snooping, règle R2).
• ONE-ITERATION est un dispositif rare et pré-payé : on ne « ré-essaie » pas librement.
• Re-tuner pour survivre au coût (Phase 4) = post-hoc → c'est un KILL tuple, pas une correction.
• INFEASIBLE ≠ échec : c'est un verdict de sous-puissance qui renvoie à la Phase 1 (univers / folds).