Aliwkarimi98/SniperGold_ML
Watch
1
0
Fork
You've already forked SniperGold_ML
 1
forked from chiki2bum2/SniperGold_ML
Code Pull requests Activity
SniperGold_ML/docs/P3_S10_OWNER_ADJUDICATION.md

670 lines
27 KiB
Markdown
RawPermalinkNormal ViewHistory

research: freeze canonical setup architecture and repair contract
2026-08-22 21:53:41 +07:00
# 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.*
Copy permalink