# P3-S.10 OWNER ADJUDICATION — SNIPERGOLD_ML ```text Date : 2026-08-22 Session : P3-S.10 — Owner Adjudication & Canonical Setup Contract Freeze Status : DESIGN / ADJUDICATION / CONTRACT FREEZE ONLY. NO production change. NO ML. NO optimization. NO backtest. Method : For each OD — question -> verified evidence -> alternatives -> consequences -> DECISION -> rationale -> unresolved -> implementation implications. Human verification : REMAINS CANCELLED (permanent research-path decision). Outputs : docs/SNIPERGOLD_CANONICAL_SETUP_CONTRACT_v1.md (frozen contract) docs/P3_S10_REPAIR_IMPLEMENTATION_SPEC.md (future implementation) docs/SESSION_HANDOVER_2026-08-22_P3_S10_OWNER_ADJUDICATION.md docs/P3_S9_CONSOLIDATED_REPAIR_PLAN.md (addendum only, §9) Provenance : Forge HEAD 533c8c6647a552d01a1a290cb2d0505f94887666 (VERIFIED, == origin/main, branch main, working tree = untracked P3-S.7/ P3-S.8/P3-S.9 artifacts only). ``` --- ## A. CHECKPOINT (Phase 0 — restoration) ```text Expected P3-S.9 parent/reference : 533c8c6 Current local HEAD : 533c8c6647a552d01a1a290cb2d0505f94887666 VERIFIED Remote HEAD (origin/main) : 533c8c6647a552d01a1a290cb2d0505f94887666 VERIFIED Branch : main VERIFIED Working tree : only untracked P3-S.7/P3-S.8/P3-S.9 artifacts; zero tracked modifications VERIFIED P3-S.9 artifacts read : P3_S9_ARCHITECTURE_REVIEW.md, P3_S9_ROOT_CAUSE_MATRIX.md, P3_S9_CONSOLIDATED_REPAIR_PLAN.md, SESSION_HANDOVER_..._P3_S9_...md VERIFIED P3-S.2..S.8 authoritative specs : SMC_LIQUIDITY_SWEEP_SPEC_v1 (S.2), SMC_CHOCH_MSS_SPEC_v1 (S.3), SMC_FVG_SPEC_v1 (S.4), SMC_ORDER_BLOCK_SPEC_v1 (S.5), SMC_DISPLACEMENT_SPEC_v1 (S.6), SMC_MTF_ALIGNMENT_SPEC_v1 (S.7), SMC_CANDIDATE_SETUP_SPEC_v1 (S.8) VERIFIED Repository state : CONSISTENT — proceed with adjudication. ``` --- ## B. OD-1 — H4/M30 GATE POLICY ### 1. Question > Must H4 and M30 be direction-compatible prerequisites for Candidate Setup formation? ### 2. Verified evidence ```text - P3-S.7 S-N/S-C : H4/M30 are 0.30-weight VOTES; "CAN trigger entry alone; NO gate/override/invalidate" — the CURRENT vote model. - P3-S.7 S-H/S-A : the top-down order is an ANALYSIS/READING order; the DECISION is a flat vote; no REQUIRED stage; "hierarchy not implemented". - P3-S.8 Definition B (legacy) : HTF-align (D1/H4/H1) is a HARD GATE for the only real setup state machine in the repository. - P3-S.8 CS-13/CS-14 : H4/M30 alone CANNOT create a Candidate Setup under either definition; they CAN create an entry signal via the vote. - P3-S.9 §E/§F proposal : H4/M30 = REQUIRED direction-compatible CONTEXT GATES for the setup layer; the override of S-N/S-C is recorded as OD-1. ``` ### 3. Alternatives ```text A1 (adopted) : H4 AND M30 are hard direction-compatible gates; conflict or neutral state -> NO CANDIDATE SETUP. A2 : Keep vote permissiveness (status quo) — context never gates. A3 : Asymmetric half-gate (one TF gates, the other votes). ``` ### 4. Consequences ```text A1 : Candidate Setups require top-down agreement (matches legacy B + brief's causal order). Fewer setups; the vote layer still emits directional signals (signal != setup separation retained). Deterministic, testable. A2 : Leaves D-1/D-8/D-13 and root cause G unresolved; setups could form against context; contradicts the canonical chain. A3 : No project evidence for a half-gate; introduces arbitrary asymmetry. ``` ### 5. DECISION ```text OD-1 = YES. H4 must be direction-compatible AND M30 must be direction-compatible for a Candidate Setup to form. A conflict means NO CANDIDATE SETUP. Gate semantics (frozen): H4_state(asof) and M30_state(asof) must each be non-zero AND equal to the chain direction. A neutral (0) state fails the gate. Important distinction (recorded): SIGNAL != CANDIDATE SETUP. H4-only / M30-only / M15-only BUY may exist as DIRECTIONAL SIGNALS (vote layer, unchanged). They may NOT create a Candidate Setup, because the canonical setup contract requires higher-TF context gates (P3-S.7 S-N/S-C overridden for the SETUP LAYER ONLY; the vote remains for signal scoring — P3-S.9 §F, §M.1). ``` ### 6. Rationale ```text The canonical chain is the project's OWN legacy v4.x institutional gate (P3-S.8 Definition B) and the brief's causal order (Liquidity -> Structure Change -> Zone -> Return -> Confirmation). P3-S.7's permissiveness described the CURRENT vote model, not the target setup layer; P3-S.9 explicitly identified this override as OD-1. This is an architecture decision, not a performance decision. ``` ### 7. Unresolved ```text None at the architecture level. "Direction-compatible" is a semantic sign-match on as-of closed states (no numeric threshold to tune). ``` ### 8. Implementation implications ```text F3 (setup layer): H4/M30 gate evaluation at chain entry. F4 (MTF): conflict policy wired to the gate (OD-4). Tests: gate-fail cases (conflict, neutral, stale as-of) in the CS-T class. ``` --- ## C. OD-2 — CANONICAL MTF MODEL ### 1. Question > Which MTF model is canonical for the SniperGold architecture? ### 2. Verified evidence ```text - Engine 2 agent path : H4/M30/M15/M3 (hardcoded AF_E2_TF_S1..S4; P3-S.7 §1). - ML / Feature Contract : D1/H4/H1 + M15 (f0-f18); parity-verified (P3-S.7 S-PR); agent path has NO Python counterpart (parity = N/A by absence). - P3-S.7 D-5/D-6 : FEATURE_CONTRACT MTF mismatch; THREE MTF models coexist. - P3-S.9 §F proposal : H4/M30/M15/M3 canonical for agent+setup; D1/H4/H1 deprecated to reference for the agent path. ``` ### 3. Alternatives ```text B1 (adopted) : H4/M30/M15/M3 = canonical runtime/setup model; D1/H4/H1/M15 recorded as legacy/current training semantics; future F4 alignment requirement. B2 : D1/H4/H1/M15 canonical — M30/M3 roles undefined; contradicts the runtime and DESIGN.md four-TF model. B3 : No canonical model (both coexist indefinitely) — leaves root causes E/G/H unresolved. ``` ### 4. Consequences ```text B1 : Matches the runtime engine and the setup chain; creates a documented FUTURE alignment requirement for training; does NOT modify the ML pipeline this session. B2 : Requires removing/re-mapping M30/M3; contradicts the actual engine. B3 : Perpetuates the three-model drift (D-5/D-6); blocks F4. ``` ### 5. DECISION ```text OD-2 = H4 / M30 / M15 / M3 is the CANONICAL SniperGold runtime/setup model. H4 = Narrative / higher-TF context M30 = Context M15 = Entry M3 = Price Action / optional micro confirmation Recorded (NOT modified this session): D1/H4/H1 + M15 = legacy/current training semantics (FEATURE_CONTRACT f0-f18). H4/M30/M15/M3 = canonical setup/runtime semantics. -> A FUTURE ALIGNMENT REQUIREMENT (F4) must reconcile training to the canonical model or document the divergence as intentional. The old ML architecture is NOT silently rewritten. ``` ### 6. Rationale ```text The four-TF model is the actual runtime (agents, aggregator, display) and the DESIGN.md analysis hierarchy; the setup chain (H4 gate -> M30 gate -> M15 chain -> M3 optional) cannot be expressed in the D1/H4/H1 model. The training model is parity-verified FOR ITS OWN scope and is untouched here; alignment is deferred to F4 per P3-S.9 §N Phase 4. ``` ### 7. Unresolved ```text None at the architecture level. The training-alignment DETAIL (which features map to which canonical TF semantics) is F4 implementation scope. ``` ### 8. Implementation implications ```text F4 (D-5, D-6): FEATURE_CONTRACT/training alignment or explicit divergence document; slot->TF identity enforcement (D-3). FEATURE_CONTRACT.md is NOT modified by this session. ``` --- ## D. OD-3 — VALIDITY-WINDOW SEMANTICS ### 1. Question > How long may each event/zone remain valid for a Candidate Setup? ### 2. Verified evidence ```text - Sweep : f7 EVENT lifecycle onset..onset+40 (SEQ_WINDOW, P3-S.0 fix; P3-S.2 R-H); one onset per reference; supersession; EXPIRED after window; INVALIDATED/CONSUMED not modeled in f7. - CHoCH : f8 = persistent STATE (last CHoCH) PER CONTRACT; f9/f18 chain consumers MUST apply validity window = 40 (P3-S.3 S-9/S-10); legacy gate (curBar - chochBar) <= 40 AND chochBar >= swpBar (P3-S.3 §10). - OB/FVG : ZONE persistent until MITIGATED; NO age expiry; NO invalidation (P3-S.4 S-8/S-10; P3-S.5 S-8/S-10). - M15 entry : same-bar in Definition A; legacy tap on a FRESH (unmitigated) zone (P3-S.8 CS-29). - M3 : interval NOT DEFINED (P3-S.8 CS-29); M3 optional (S-P). - SeqWindow=40 scope : f7 expiry (ML) + legacy gates; NOT Engine 2 (P3-S.8 CS-28). - P3-S.9 §I : per-primitive contracts; "a single global SeqWindow is NOT automatically reused everywhere" (session brief §7). ``` ### 3. Alternatives ```text C1 (adopted) : Per-primitive validity CONTRACT with semantics + numerics; numerics only where project semantics justify them; otherwise OPEN NUMERIC PARAMETER (never from performance). C2 : One global SeqWindow=40 for everything (status-quo-ish collapse) — rejected: violates the session's design principle and the evidence (each primitive has distinct lifecycle). ``` ### 4. Consequences ```text C1 : Deterministic, per-stage windows; W_sweep=W_choch=40 justified; W_setup/W_m3/W_zone_age recorded as OPEN NUMERIC PARAMETERS with full semantic contracts; implementation cannot silently tune them. C2 : Repeats the f7/f9/f18 stale-consumption class; conflates EVENT, ZONE, SETUP lifecycles; contradicts P3-S.9 §I. ``` ### 5. DECISION ```text OD-3 = DECIDED AS A SEMANTIC CONTRACT (per-primitive validity). Liquidity EVENT : unit M15 bars; start = onset b; end = b + W_sweep; expiration = EXPIRED after W_sweep; invalidation = none (superseded by a newer onset); consumption = read-only. W_sweep = 40 (justified: InpSeqWindow origin, P3-S.0/P3-S.2). CHoCH EVENT : unit M15 bars; start = onset b'; end = b' + W_choch; ordering b' >= b (after sweep) and b' <= b + W_sweep; W_choch = 40 (justified: legacy gate, P3-S.3). OB/FVG ZONE : unit M15 bars; start = formation ts; end = none by age (mitigation/invalidation only); W_zone_age = NONE by semantics; an explicit cap = OPEN NUMERIC PARAMETER. M3 confirmation : unit M3 bars; optional; evaluated within setup validity; W_m3 = OPEN NUMERIC PARAMETER. M15 entry cond. : unit M15 bars; per closed bar; bounded by stage windows. Candidate Setup : unit M15 bars; start = creation ts; end = creation + W_setup; W_setup = OPEN NUMERIC PARAMETER. SEMANTIC CONTRACT vs NUMERIC PARAMETER (explicit): - SEMANTIC CONTRACT : what starts/ends/expires/invalidates/consumes each primitive (the table above + §K of the canonical contract). - NUMERIC PARAMETER : the constant value. 40/40 are JUSTIFIED by project semantics. W_setup, W_m3, W_zone_age are OPEN NUMERIC PARAMETERS — they must be set in implementation with contract tests, NEVER from AUC/PF/ profit/backtest. ``` ### 6. Rationale ```text The evidence shows three distinct lifecycle classes (EVENT with bounded window; ZONE persistent until mitigation; SETUP with formation + validity) that a single SeqWindow cannot express. The 40-bar value has a documented project origin (InpSeqWindow "sweep -> CHoCH -> entry must chain within"), so it is reused ONLY for the sweep/CHoCH EVENT legs it was designed for — not for zones or the setup itself. ``` ### 7. Unresolved ```text OPEN NUMERIC PARAMETERS (by design, not ambiguity): W_setup, W_m3, W_zone_age (cap), plus FVG min-gap / OB min-size / zone-consumer scope (F2/F6 scope). All have defined SEMANTIC contracts; only the constants are open, and they are barred from performance-based selection. ``` ### 8. Implementation implications ```text F1 (EVENT contract): f9/f18 + Engine-2 consumers apply W_sweep/W_choch. F2 (ZONE contract): mitigation-aware consumption; zone age semantics. F3 (setup layer): W_setup + W_m3 as explicit contract constants with tests. ``` --- ## E. OD-4 — MTF CONFLICT POLICY ### 1. Question > What happens when timeframes disagree? ### 2. Verified evidence ```text - P3-S.7 S-X : "Defined policy: NONE" — arithmetic resolution only; SPECIFICATION AMBIGUOUS. - P3-S.7 S-A : same-level votes; contradiction lowers the aggregate bias; no BLOCK/WAIT/CONFLICT state (MTF-T21). - P3-S.8 Definition B : conflict -> gate fails -> no signal (hard gate). - P3-S.9 §F proposal : H4<->M30 conflict -> NO setup; M15 vs H4/M30 -> NO setup; M3 contrary -> micro-score only. ``` ### 3. Alternatives ```text D1 (adopted) : GATE-FAIL policy for the setup layer (P3-S.9 proposal); arithmetic ONLY in the signal-scoring layer. D2 : Arithmetic voting everywhere (status quo) — no policy. D3 : Mixed — HTF conflict blocks, LTF conflict arithmetic (effectively D1 for the setup layer; redundant). ``` ### 4. Consequences ```text D1 : Deterministic setup-layer conflicts; consistent with legacy B; the flat aggregator remains usable as a scoring layer where arithmetic is valid. D2 : Leaves D-2/D-13 and root cause F unresolved; setups can form against context; no determinism. D3 : Adds nothing over D1. ``` ### 5. DECISION ```text OD-4 = GATE-FAIL POLICY for the SETUP LAYER. H4 <-> M30 conflict (opposite signs) : Candidate Setup = BLOCKED. H4/M30 compatible, M15 chain conflicts : Candidate Setup = BLOCKED. M3 conflict : M3_CONFIRMED = FALSE; Candidate Setup MAY remain valid (M3 optional); a contrary M3 reduces ONLY the micro-score. Canonical authority (frozen): H4/M30 = directional context GATES M15 = setup authority M3 = optional micro confirmation NO arithmetic voting resolves setup-layer conflicts. The flat aggregator may continue to exist LATER as a scoring/signal layer, but it is NOT the canonical definition of Candidate Setup. ``` ### 6. Rationale ```text Root cause F (flat score as setup) and D-2/D-13 are structural; only a policy with an explicit BLOCK state makes setup-layer conflicts deterministic and testable. Arithmetic remains valid where it belongs: ranking valid setups (score layer). ``` ### 7. Unresolved ```text None at the architecture level. ``` ### 8. Implementation implications ```text F4 (D-2, D-13): conflict policy in the MTF hierarchy. F3: gate evaluation consumes the policy at chain entry. Tests: conflict matrix (H4xM30, M15xH4/M30, M3-contrary) in the CS-T class. ``` --- ## F. OD-5 — CANONICAL ORDER BLOCK SEMANTICS ### 1. Question > Which Order Block definition is canonical, and does the CHoCH stage make a > separate OB structural-break requirement redundant? ### 2. Verified evidence ```text - P3-S.5 S-1..S-5 : CANONICAL current = opposite-color candle B immediately before strong-move candle M (body >= 1.5 x avg, 20-bar mean); zone = full range of B; NO structural precondition. - P3-S.5 §7/A-2 : LEGACY second definition = opposite candle before STRUCTURE BREAK (BOS/CHoCH); documented, NOT canonical. - P3-S.6 §7 : answer B — OB "strong move" = "A simplified proxy for Displacement (same concept family, lower threshold)"; 1.5 vs 1.6 = BUG-P3S6-001, "NOT adjudicated" (P3-S.6 A-2). - P3-S.6 S-5/S-7 : displacement requires NO structure; OB/displacement are the same concept family with different constants. - Canonical chain (P3-S.9 D.1) : Sweep -> CHoCH -> OB/FVG ZONE -> M15 entry; CHoCH is a SEPARATE REQUIRED stage before the zone leg. ``` ### 3. Alternatives (the A/B/C/D/E question) ```text A : OB "strong move" is INTENTIONALLY a simpler proxy for Displacement. B : OB should require canonical Displacement (1.6x). C : OB should require BOS/CHoCH (legacy structure-break definition). D : OB requires a specific combination. E : specification remains unresolved. ``` ### 4. Consequences ```text A : Detector (validated CONFORMING, P3-S.5 S-1) stays unchanged; the two constants are documented as two roles (zone-formation gate vs confirmation attribute); minimal change to validated parts (P3-S.9 §K). B : Modifies a validated detector + display; embeds displacement into the zone; creates asymmetry vs the FVG zone leg (FVG has no displacement requirement); no design source demands it. C : REDUNDANT with the canonical chain's CHoCH stage; resurrects the legacy A-2 definition; creates inconsistency with the FVG alternative (no structural requirement). D : Only the canonical formation rule itself (opposite candle + strong move + full-range zone + unmitigated) — no extra combination needed. E : Leaves BUG-P3S5-002 unresolved; blocks contract freeze. ``` ### 5. DECISION ```text OD-5 = A (intentional simpler proxy), with explicit answers: A. YES — the OB "strong move" (1.5 x avg body) is INTENTIONALLY a simpler proxy for Displacement (1.6 x avg body): same concept family, lower threshold, ZONE-FORMATION gate. (P3-S.6 §7 answer B adopted.) B. NO — OB does NOT require canonical Displacement as an input. Displacement remains an independent OPTIONAL confirmation attribute. The constants 1.5/1.6 are KEPT SEPARATE and DOCUMENTED (BUG-P3S6-001 -> DOCUMENT ONLY, F6). Unifying would modify a validated CONFORMING detector and conflate two distinct roles. C. NO — OB does NOT require BOS/CHoCH. The legacy structure-break definition (P3-S.5 A-2) is historical, non-canonical. REDUNDANCY ANSWER: YES, requiring CHoCH in the canonical chain DOES make a separate OB structural-break requirement redundant — the chain's CHoCH stage is the structural confirmation; the zone leg requires only an UNMITIGATED, direction-compatible zone. D. Canonical OB = (opposite-color candle B) + (strong move M, 1.5 x avg) + (zone = full range of B) + (unmitigated until close-through full fill). No additional combination. E. RESOLVED — not left open. SUPERSEDED BY OD-5 (recorded, history preserved): any reading of SMC_ORDER_BLOCK_SPEC_v1.md §5 that treats the legacy structure-break definition as canonical for the setup layer. The spec's CANONICAL current definition (S-1..S-9) is CONFIRMED unchanged. ``` ### 6. Rationale ```text Chosen on design intent / source behavior / architecture / causal semantics / consistency — NOT on results: 1. The dominant failure class is CONSUMER-side (P3-S.9 §3); detectors are validated. Keeping the OB detector unchanged preserves the validated part. 2. P3-S.6's own recorded answer classifies the OB strong move as a proxy — the "simpler proxy" is the project's intended semantic, not an error. 3. The chain already provides structural confirmation via CHoCH; a second structural-break requirement inside OB is redundant and inconsistent with the FVG alternative. 4. The 1.5/1.6 split maps to two different roles (zone formation vs confirmation) — a documented distinction, not a defect to "fix". ``` ### 7. Unresolved ```text None at the architecture level. BUG-P3S5-002 (two OB definitions) is resolved by designation (canonical vs historical). BUG-P3S6-001 is resolved by documentation (DOCUMENT ONLY, F6). Zone-consumer scope (P3-S.5 A-3/A-5, P3-S.4 A-6) and min-size filters remain F2/F6 implementation scope. ``` ### 8. Implementation implications ```text F6 (BUG-P3S5-002, BUG-P3S6-001): documentation only — record the canonical vs legacy OB definitions and the 1.5/1.6 role split. F2: zone mitigation-aware consumption (OB close-through; FVG wick full-fill legacy canonical); zone selection scope. ``` --- ## G. CANONICAL CANDIDATE SETUP DEFINITION ```text FROZEN (docs/SNIPERGOLD_CANONICAL_SETUP_CONTRACT_v1.md §A/§D): ONE Candidate Setup = a discrete, causally-ordered entity on the M15 entry layer: H4 context gate -> M30 context gate -> fresh Liquidity EVENT -> CHoCH/MSS EVENT (after sweep) -> unmitigated OB|FVG ZONE -> M15 entry condition -> CANDIDATE_SETUP (direction = chain direction); M3 optional -> M3_CONFIRMED. H4 gate : H4_state(asof) non-zero and == chain direction (OD-1) M30 gate : M30_state(asof) non-zero and == chain direction (OD-1) Liquidity : fresh EVENT (W_sweep=40) (OD-3) CHoCH : EVENT after sweep, fresh (W_choch=40), same direction (OD-3) Zone : unmitigated OB|FVG, direction-compatible (OD-5; F2) M15 entry : zone membership + confirmation conjunction + premium/discount filter; displacement may boost (contract §C/§D) M3 : optional micro confirmation (OD-4; no veto) ``` --- ## H. PRIMITIVE ROLE MATRIX (frozen) | Primitive | Role | Required? | Produces | Window | |---|---|---|---|---| | H4 | CONTEXT STATE (Narrative gate) | REQUIRED | STATE | as-of closed H4 bar | | M30 | CONTEXT STATE (Context gate) | REQUIRED | STATE | as-of closed M30 bar | | Liquidity Sweep | EVENT (stage 1) | REQUIRED | EVENT | W_sweep=40 | | CHoCH/MSS | STRUCTURAL EVENT (stage 2) | REQUIRED | EVENT | W_choch=40 | | OB | ZONE (stage 3, OB OR FVG) | ALTERNATIVE | ZONE | unmitigated; no age expiry | | FVG | ZONE (stage 3, OB OR FVG) | ALTERNATIVE | ZONE | unmitigated; no age expiry | | Displacement | ATTRIBUTE / OPTIONAL CONFIRMATION | OPTIONAL | ATTRIBUTE | per-bar | | M15 | ENTRY CONDITION / CHAIN CARRIER | REQUIRED | CONDITION | per closed M15 bar | | M3 | OPTIONAL MICRO CONFIRMATION | OPTIONAL | CONDITION | optional (W_m3 open) | --- ## I. MTF HIERARCHY (frozen) ```text H4 (Narrative STATE) -> direction-compatible context GATE M30 (Context STATE) -> direction-compatible context GATE M15 (Entry layer) -> the setup chain lives here (setup authority) M3 (Price Action) -> optional micro confirmation (no veto) Can H4 alone create a setup? NO (context state only) Can M30 alone create a setup? NO (context state only) Can M15 alone create a setup? NO (chain requires H4+M30 gates; the E-rule alone = entry condition, not a setup) Can M3 alone create a setup? NO (micro-confirmation only) Conflict policy: OD-4 (gate-fail for the setup layer). As-of contract: P3-S.7 S-T closed-bar lock (contract §L). ``` --- ## J. EVENT / ZONE / STATE / ATTRIBUTE / CONDITION CONTRACTS (frozen) ```text EVENT : {timestamp, direction, valid_until, superseded, source} ZONE : {timestamp, direction, upper_bound, lower_bound, mitigation_state, invalidated} STATE : {value, as_of, timeframe} ATTRIBUTE : {value, bar_timestamp, timeframe} CONDITION : {boolean, as_of, timeframe, reason} Consumer contract: EVENT -> apply validity window; ZONE -> apply mitigation/invalidation; STATE -> as-of closed value; SETUP -> identity + lifecycle, never raw detector states. (Full spec: docs/SNIPERGOLD_CANONICAL_SETUP_CONTRACT_v1.md §K.) ``` --- ## K. SETUP IDENTITY (frozen) ```text {setup_id (monotonic), direction, sweep {onset ts, dir, window}, choch {onset ts, dir}, zone {type, formation ts, bounds, mit at creation}, entry TF = M15, creation ts, M3 ts (nullable), expiry/invalidation reason (EXPIRED|INVALIDATED|CONSUMED|NONE)} Uniqueness: (direction, sweep onset, choch onset, zone formation ts, creation ts). CAUSAL identity; one setup = one identity (no per-bar recreation). ``` --- ## L. SETUP LIFECYCLE (frozen) ```text NONE -> CONTEXT_VALID -> LIQUIDITY_TRIGGERED -> STRUCTURE_CONFIRMED -> ZONE_READY -> ENTRY_ARMED -> CANDIDATE_SETUP -> [M3_CONFIRMED optional] -> EXPIRED | INVALIDATED | CONSUMED. Strict order; no skipping; no reactivation; stage expiry before CANDIDATE_SETUP discards the forming setup; at most one entry signal per setup; zone mitigation mid-chain invalidates. ``` --- ## M. REPAIR FAMILIES (frozen for implementation) ```text F1 EVENT CONTRACT : BUG-P3S2-001, BUG-P3S3-001, D-12. F2 ZONE CONTRACT : BUG-P3S4-001/-002, BUG-P3S5-001 (+ zone scope A-3/A-5/A-6). F3 SETUP LAYER : D-8, D-9, D-10, D-11, D-1 (aggregator re-scope), OD-1/OD-3/OD-4 gates+windows. F4 MTF/TRAINING ALIGNMENT : D-2, D-3, D-5, D-6, BUG-P3S2-003, BUG-P3S3-002, OD-2/OD-4. F5 DISPLAY : D-4. F6 DOCUMENTATION : BUG-P3S5-002 (OD-5), BUG-P3S6-001 (OD-5), BUG-P3S5-003/-004, BUG-P3S2-004/-005, BUG-P3S3-003, BUG-P3S4-003/-004, D-7, D-14. Full detail: docs/P3_S10_REPAIR_IMPLEMENTATION_SPEC.md. ``` --- ## N. FUTURE IMPLEMENTATION ORDER (frozen, NOT executed) ```text Phase I : F1 EVENT Contract Repair Phase II : F2 Zone Contract Repair Phase III : F3 Candidate Setup Layer Phase IV : F4 MTF / Training Alignment Phase V : F5 Display / Explainability Phase VI : Regression + parity + setup dataset rebuild Test-first: SPEC -> TEST -> IMPLEMENTATION -> REGRESSION -> PARITY. No direct hot-fix. Historical evidence and prior checkpoints preserved. ``` --- ## O. OPEN DECISIONS ```text OPEN NUMERIC PARAMETERS (by design; semantically contracted, numerically open, barred from performance selection): W_setup — Candidate Setup post-formation validity (M15 bars). W_m3 — M3 confirmation lookback (M3 bars). W_zone_age — optional zone-age cap (default: none — project semantics). FVG min-gap / OB min-size / zone-consumer scope — F2/F6 implementation scope (P3-S.4 A-1, P3-S.5 A-1/A-3/A-5, P3-S.4 A-6). Implementation-scope items (NOT architecture blockers): - FVG mitigation variant unification (wick full-fill canonical vs display close variant; P3-S.4 A-2) -> F2. - Runtime TF-identity enforcement (D-3) -> F4. - Display vs decision consistency (D-4) -> F5. - Training alignment detail (OD-2) -> F4. NO unresolved architecture decisions remain. ``` --- ## P. FINAL ARCHITECTURE STATUS ```text READY FOR REPAIR Verified conditions: OD-1 resolved ........................ YES (H4/M30 hard gates) OD-2 resolved ........................ YES (H4/M30/M15/M3 canonical) OD-3 resolved as semantic contract .. YES (per-primitive windows; 40/40 justified; OPEN NUMERIC PARAMETERS recorded, not tuned) OD-4 resolved ........................ YES (gate-fail policy) OD-5 resolved ........................ YES (A; redundancy answered) Candidate Setup contract frozen ...... YES (v1) MTF model frozen ..................... YES (H4/M30/M15/M3) Primitive roles frozen ............... YES (role matrix §H) Setup identity frozen ................ YES (§K) Lifecycle frozen ..................... YES (§L) NO PRODUCTION CODE CHANGED .......... VERIFIED (docs only) Next gate: P3-S.11 — F1 EVENT CONTRACT REPAIR (separate implementation session; tests first; one repair family at a time). ``` *Provenance: Forge HEAD 533c8c6647a552d01a1a290cb2d0505f94887666. P3-S.10 artifacts added; 0 production files modified. Human verification CANCELLED.*