SniperGold_ML/docs/P3_S22_2_REPAIR_DECISION.md

P3-S22.2 — REPAIR DECISION

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

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.