SniperGold_ML/docs/P3_S10_OWNER_ADJUDICATION.md

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