CVN-N001-EK-S01 — Architecture: the tradability decision protocol¶

Story artifact required by ADR-0101 (Invariant 1). S01 is a governance/process Story, so "architecture" here is the process and system-interaction architecture of the protocol (Invariant 3), not source code. Companions: the Epic overview, the plan dossier (plan_review PASSED, Meeting #269), the decision tree.

Executive summary¶

This architecture defines the governance / control plane for tradability decisions. It separates durable rules (the ADR) from instance-specific values (the charter). It enforces tuple registration, a killed-tuple check, FDR accounting, holdout discipline, and a risk-owner veto, in a strict Phase 2→6 gate order. It produces a defensible verdict — PROMOTE, KILL, or INFEASIBLE — and makes downstream optimisation before upstream proof structurally impossible. It does not authorize trading or deployment. It is realised across Stories S01–S08 (S05+ only if upstream PROMOTE).

1. Decision boundary¶

This architecture governs decisions about a strategy; it is not a trading system. It authorises no filtering, sizing, execution, or deployment before its gates are cleared. Charter lock (S03) and any run (S04) confer no trading authority. A switch to a different hypothesis family (e.g. cross-sectional / market-neutral) is a separate Epic with its own architecture, not an extension of this one.

2. What this architecture is¶

The protocol is a governance machine: it takes a named program thesis and produces a defensible verdict while bounding the search by budget and forbidding any backward optimisation. The durable rules are the ADR (adr/0102, a D1 deliverable, status Accepted); the instance values are the charter (D1, placeholders → locked S03). This document is the control architecture that binds them: components, data contracts, the state machine, enforcement points, violation policies, and the Story build-map.

3. Components¶

flowchart TB
    subgraph GOV["Governance layer (durable)"]
        ADR["ADR 0102 — durable rules
(Accepted; instance-free)"]
    end
    subgraph INST["Instance layer (per program)"]
        CH["Charter
(placeholders → locked S03)"]
    end
    subgraph ENG["Decision engine"]
        PIPE["Gate pipeline
Phase 2 → 3 → 4 → 5 → 6"]
        VE["Verdict engine
PROMOTE / ONE-ITERATION /
KILL (tuple→family→thesis) / INFEASIBLE"]
    end
    subgraph STATE["Ledgers / registries (state)"]
        RT["Registered tuples"]
        KT["Killed-tuple register
(blocking gate)"]
        FDR["FDR / multiple-testing ledger"]
        HO["Final-holdout access log"]
        BUD["Budgets
(families · ONE-ITERATION slots · FDR)"]
    end
    subgraph ROLES["Authority & gates"]
        OP["Operator"]
        ME["Methodology reviewer"]
        RO["Risk owner
(blocking veto)"]
    end

    ADR -- "constrains" --> CH
    ADR -- "defines rules of" --> PIPE
    ADR -- "defines" --> VE
    CH -- "supplies values to" --> PIPE
    CH -- "names" --> RT
    PIPE -- "emits" --> VE
    VE -- "writes" --> KT
    VE -- "decrements" --> BUD
    PIPE -- "consults / appends" --> FDR
    PIPE -- "reads once at verdict" --> HO
    RT -- "checked against" --> KT
    OP --- CH
    ME --- CH
    RO -- "joint sign-off + veto (S03)" --> CH
    RO -- "veto blocks" --> PIPE

4. Data contracts (state)¶

These contracts are defined here (architecture) even though the values are filled in S02 and the storage is implemented in S03/S04. A named ledger without a contract is not an architecture.

4.1 Registered tuple (the unit of governance)¶

A registered tuple MUST carry:

4.2 Killed-tuple register + material equivalence¶

Every KILL writes here; every new registration reads here first (blocking).

Material equivalence. A new tuple is materially equivalent to a killed tuple if it preserves the same program_thesis, label_family, feature_family, model_class, and economic action intent — regardless of cosmetic changes to horizon, threshold, feature suffix, hyperparameter family, universe subset, or action policy. A materially-equivalent tuple is rejected unless the reopening condition recorded in the register is explicitly met. Disputes are resolved by the methodology reviewer + risk owner before registration (not by the proposer).

4.3 FDR ledger (contract)¶

Appended at each test; the running spend gates further tests. Each row:

tuple_id · family_id · hypothesis_id · stage · test_type · criterion (p-value / CI / posterior) · alpha_or_fdr_allocation · consumes_tuple_budget (bool) · consumes_one_iteration_budget (bool) · cumulative_spend · decision.

4.4 Final-holdout access log + violation policy¶

One dated entry per tuple verdict; any second touch is a violation.

Violation consequence. A holdout violation invalidates the tuple verdict: the tuple cannot PROMOTE; it must be KILLed or re-registered with a new, untouched holdout under committee approval.

4.5 E_econ_min vs E_pred_min¶

E_econ_min = economic break-even from conservative P90 cost + target capacity. E_pred_min = the minimum predictive effect that meets E_econ_min through the documented predictive-to-economic mapping. The pipeline tests against E_pred_min at Phase 2 and against E_econ_min at Phase 4. They are never conflated (an f1/AUC lift is not an economic edge).

5. Control flow — verdict state machine¶

Operational view: the decision tree. The architecture-level state machine:

INFEASIBLE ≠ KILL. INFEASIBLE is not evidence against the signal (it is an under-power / substrate verdict); KILL is evidence against the registered tuple/family under the locked protocol. INFEASIBLE allows only: substrate expansion · charter revision before any run · program stop for cost/practicality. It allows no feature tinkering, threshold tuning, meta-labeling, or downstream work. Any charter revision triggered by INFEASIBLE must re-enter the S03 lock process (full re-validation + joint re-sign-off, §7) before a new run — it is not an in-place edit of a locked charter.

6. Action-policy correction (same-tuple, bounded)¶

A same-tuple correction is legal only when pre-registered and budgeted. It:

• cannot touch the final holdout;
• cannot change label, feature family, model class, universe, null-gate, or cost model (those are structural → new tuple);
• has exactly one allowed attempt if prepaid (ONE-ITERATION);
• writes to the FDR / budget ledger.

Anything outside this is a new tuple that consumes tuple + multiple-testing budget.

7. Risk-owner veto — scope¶

The risk owner does not validate the science. Their blocking veto fires on any of:

• deployment-authority ambiguity, or protocol wording implying trading authorization;
• cost/capacity assumptions not explicit;
• risk limits absent;
• holdout discipline violated;
• downstream work attempted before its gate;
• charter lock without evidence of E_econ_min / E_pred_min derivation.

A risk-owner objection cannot be overridden by methodology approval alone — only by addressing it or by an explicit, recorded waiver from the accountable owner. Without the risk-owner signature, S03 cannot lock and S04 cannot run.

8. Phase entry conditions¶

9. Invariant enforcement points¶

10. Failure modes¶

Prevented by this architecture:

• optimising thresholds on the final holdout (§4.4);
• re-testing a killed tuple under a new name (§4.2);
• promoting after beating only a diagnostic null (locked null-gate, S03);
• using meta-labeling to manufacture alpha (Phase 5 entry gate, §8);
• launching Phase 2 without a locked E_pred_min (§7 veto);
• interpreting S01/S03 as deployment approval (§1, §7).

Still possible (residual — owned downstream):

• bad cost measurement (S02 must instrument P90 at target capacity);
• under-specified material equivalence (S01 ADR wording + §4.2 dispute resolution mitigate);
• poor null-gate implementation (S02/S04);
• governance bypass outside the documented pipeline (process/audit risk, not architectural).

11. Story → component mapping (conditional activation)¶

The roadmap is not pre-committed: S05–S08 may never open. A clean KILL/INFEASIBLE is a success, and the protocol explicitly authorizes stopping.

12. Methodological basis¶

The invariants are grounded (full citations in the plan dossier §4 / References): purged & embargoed cross-validation · multiple-testing / FDR control · pre-registration / design of experiments · probability of backtest overfitting (PBO/CSCV) · final-holdout discipline.

13. Committee review outcome & recommendations¶

plan_review PASSED — strong consensus, 5/5 experts (9.0–9.5), session 717127f5, OP Meeting #270. The state machine, data contracts, and violation policies were assessed "exhaustive, internally consistent, and effectively designed to prevent common governance and methodological pitfalls."

Folded into this revision (r3): explicit ONE-ITERATION exit transitions (§5); INFEASIBLE-triggered charter revision must re-enter the S03 lock (§5).

Non-blocking recommendations routed to owner stories: