SniperGold_ML/docs/P3_S22_2_REPAIR_DECISION.md

# 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.*