# P3-S22.2 — REPAIR DECISION ```text Date : 2026-08-25 Session : P3-S22.2 — DISCREPANCY IMPACT ASSESSMENT & REPAIR DECISION Status : DECISION SUPPORT ONLY — NO REPAIR IMPLEMENTED Policy : docs/CODE_VERIFICATION_AND_SILENT_BUG_POLICY_v1.md Decision : ADJ-1 ACCEPT WITH CONTRACT CLARIFICATION (option 2); ADJ-2 REPAIR REQUIRED — SEPARATE AUTHORIZATION (option 3) for the RESEARCH/ML M30 construction; NO production MQL5 repair. Evidence : ml/p3/p3_s222_discrepancy_impact/output/*.json/csv ``` This document answers the phase question: > Do ADJ-1 and ADJ-2 materially affect the system, historical Candidate Setup > population, or ML baseline — and therefore is a production repair actually > justified? --- ## Part E — Repair decision matrix ### ADJ-1 — F2 `mit_state` label for PARTIALLY_FILLED | Entry | Value | |---|---| | Observed behavior | MQL5 `AF_FVGZoneState`/`AF_OBZoneState` never assign `mit_state=1`; partial fills stay `UNMITIGATED(0)` + `partial_filled` flag | | Expected contract behavior | F2 contract (P3_S12 §F) and committed research chain encode `PARTIALLY_FILLED(1)`, ACTIVE, consumable | | Root cause | implementation models partial fill via the auxiliary flag instead of the enumerated state | | Affected layer | F2 zone-state representation (label only); not consumers, not F3, not features | | Downstream effect | none — IsActive()/zone_consumable treat 0 and 1 identically (Part A 14/14; Part C 686/686) | | Historical affected rows | 0 | | ML affected rows | 0 (mit_state is not a feature/label; FEATURE_COLS geometry-based) | | Production risk | none demonstrated (source-verified enum only used in IsActive) | | Evidence strength | VALIDATED — independent contract oracle, 14 cases, 6/6 mutations, full-scope counterfactual IDENTICAL | | Recommended action | **2 — ACCEPT WITH CONTRACT CLARIFICATION**: document that the two encodings are functionally equivalent; amend the F2 contract note (additive) to state the implementation's flag-based encoding is contract-equivalent. No code repair justified. | ### ADJ-2 — Research M30 gate construction (index-pair vs UTC-clock) | Entry | Value | |---|---| | Observed behavior | committed M30 gate series built by index-pair resampling of M15 (`m30_from_m15`); drifts from the UTC 30-min grid at gaps; 38,399 / 197,032 (19.49%) bars have a different gate value vs the independent UTC-clock oracle | | Expected contract behavior | runtime M30 = broker CopyRates (UTC grid); research comment "identical to the runtime M30 OHLC" does not hold at session/data gaps | | Root cause | index-pair (2 x M15 per M30) grouping keeps a data-index phase that misaligns with wall-clock across gaps; the phase persists over continuous stretches | | Affected layer | research M30 gate series → F3 semantic input (`m30`); H4/M15 gates unaffected | | Downstream effect | F3 Candidate Setup creation changes under runtime-consistent UTC-clock semantics: 686 → 707 in-scope; 202 committed identities NOT reproduced, 223 different identities appear; per-bar F4/F3 outcomes differ | | Historical affected rows | 202 of 686 committed in-scope chain identities (29.4%) not reproduced under the UTC-clock oracle; 223 different identities appear | | ML affected rows | frozen P3-S18/P3-S20 rows unchanged (this phase); the population they derive from is M30-construction-dependent → a research repair would change ML input rows and thus require re-derivation of P3-S18/P3-S20 results | | Production risk | production MQL5 itself reads broker M30 (UTC grid) and is NOT defective; the divergence is research-vs-runtime in the historical/ML chain | | Evidence strength | VALIDATED — independent UTC-clock oracle (fixtures, 0-mismatch on committed per-bucket dirs, 5/5 mutations), deterministic full-scope replay, mechanism spot-check (shared 0% creation-bar diffs vs baseline-only 62%) | | Recommended action | **3 — REPAIR REQUIRED — SEPARATE AUTHORIZATION**: rebuild the RESEARCH M30 gate construction on the UTC grid and re-derive Candidate Setups / P3-S18 / P3-S20 rows as a separate, explicitly authorized phase. NO production MQL5 repair needed. | --- ## Summary of impact per assessment dimension | Dimension | ADJ-1 | ADJ-2 | |---|---|---| | F2 zone state semantics | unaffected (label only) | not applicable (M30, not F2) | | F3 Candidate Setup creation | identical (686/686) | **changes** (202 not reproduced, 223 new) | | F4 MTF gating | unaffected | gate values differ on 19.5% bars; F3 outcomes change | | Candidate Setup population | identical | **changes** (686 → 707 in-scope under UTC M30) | | P3-S16 v1 labels | unaffected | would change only if rows re-derived (population-dependent) | | P3-S18/P3-S20 ML | unchanged | rows unchanged as frozen; population-sensitive if repaired | | production-facing behavior | none | production MQL5 unaffected (reads broker UTC-grid M30) | --- ## Is production repair justified? - **ADJ-1**: NO production repair justified. The representation difference is inert at every downstream stage. The only warranted action is a contract clarification (additive documentation), so option 2. - **ADJ-2**: NO production (MQL5) repair is justified or needed — the runtime already reads the broker M30 (UTC grid), which is the correct semantics. The DEFECT is in the historical RESEARCH/ML chain's M30 gate construction, which demonstrably changes the Candidate Setup population and therefore the ML input rows. A repair here means re-deriving the research pipeline (UTC-grid M30 gate → F3 chain → Candidate Setups → P3-S18/P3-S20 rows → ML results) under separate authorization. This is option 3, scoped to research, NOT a production code change. --- ## Hard constraints honoured ```text NO production MQL5 modification. NO FEATURE_CONTRACT / label / TP-SL / horizon change. NO ML retraining. NO calibration. NO nonlinear model. NO external data. NO Tickstory/Dukascopy. NO deployment. NO trading. NO optimization / parameter search. NO silent repair. No historical artifact rewritten (P3-S16..P3-S22 untouched except additive docs required by the handover). Any repair remains hypothetical unless a later phase authorizes it. ``` *End of P3-S22.2 repair decision. Decision support only — implementation was NOT authorized or performed in this phase.*