forked from chiki2bum2/SniperGold_ML
522 lines
24 KiB
Markdown
522 lines
24 KiB
Markdown
 | # P3-S.9 CROSS-PRIMITIVE ARCHITECTURE REVIEW — SNIPERGOLD_ML
| ||
| |||
```text
| |||
Date : 2026-08-22
| |||
Session : P3-S.9 — Consolidated Architecture & Repair-Design Review
| |||
Status : ANALYSIS + ARCHITECTURE DESIGN ONLY. No production change.
| |||
Question : What should SniperGold consider to be ONE valid Candidate Setup,
| |||
how should H4/M30/M15/M3 participate in creating it, and what
| |||
existing code must change to implement that definition
| |||
consistently?
| |||
Method : EVIDENCE -> CONSOLIDATION -> ARCHITECTURE DECISION -> REPAIR
| |||
SPECIFICATION -> (future implementation).
| |||
Human verification : CANCELLED. No AUC/PF/profit used as a criterion.
| |||
Artifacts : docs/P3_S9_ROOT_CAUSE_MATRIX.md (root causes)
| |||
docs/P3_S9_ARCHITECTURE_REVIEW.md (this document)
| |||
docs/P3_S9_CONSOLIDATED_REPAIR_PLAN.md (repair matrix)
| |||
```
| |||
| |||
---
| |||
| |||
## A. CURRENT ARCHITECTURE
| |||
| |||
```text
| |||
Three layers exist today, plus a legacy reference:
| |||
| |||
1. DETECTION (Engine 1 + pure functions in AF_Engine2_Agents.mqh):
| |||
- AFEngine1MTF: closed-bar multi-TF cache (CONFORMING, P3-S.7 S-T).
| |||
- Per-TF detectors: AF_DetectSweep, AF_DetectChoch, AF_FindFVG,
| |||
AF_FindOrderBlock, AF_DetectDisplacement, AF_BuildSwing, AF_RangeStat.
| |||
- All detectors are per-TF pure functions; the SAME algorithm runs on
| |||
every timeframe slot (P3-S.7 D-7).
| |||
| |||
2. AGENT/VOTE (Engine 2):
| |||
- 4 independent agents N(C)/C/M15/E/P on H4/M30/M15/M3, each one slot,
| |||
stateless, fuzzy-weighted (P3-S.7 CONFORMING role labels).
| |||
- E-agent "ZONE + CONFIRMATION = setup" is a fuzzy weight contribution
| |||
(min(zone, max(sweep,choch)) * wSetup=0.30) — NOT an entity
| |||
(P3-S.8 D-9/D-10/D-11).
| |||
- AFAggregator: flat 2-pass weighted vote + 1.5x boost; thresholds
| |||
0.20/0.50; entry/SL/TP on M15 (P3-S.7 S-D).
| |||
| |||
3. DISPLAY (Engine 3): renders M15 structure/zones + D1/W1 levels + biases
| |||
+ aggregated signal; "TRADE SETUP" panel = the vote signal (P3-S.8 D-9).
| |||
| |||
4. LEGACY REFERENCE (v4.3/v4.4/v4.5, NOT in the current runtime):
| |||
- Hard-gated SETUP SEQUENCE: HTF-align(D1/H4/H1) -> sweep -> CHoCH
| |||
(after sweep) -> OB/FVG tap -> not-premium -> score>=threshold,
| |||
SeqWindow=40 (P3-S.8 Definition B; the ONLY real setup state machine
| |||
in the repository).
| |||
```
| |||
| |||
---
| |||
| |||
## B. EVIDENCE FROM P3-S.2..P3-S.8 (consolidated)
| |||
| |||
| Primitive | Detection | Lifecycle | Consumer | Timeframe | Training/Runtime | Setup Role | Known Bug | Ambiguity | Verdict |
| |||
|---|---|---|---|---|---|---|---|---|---|
| |||
| Liquidity Sweep | CONFORMING (P3S2 E-1..E-8) | f7 40-bar OK; in-function PARTIAL (E-9) | f9/f18 stale (E-10) | f7 M15-only; canonical AMBIGUOUS (A-2) | parity feed OK; window doc risk (E-13) | confirmation leg (A) / gate (B) | BUG-P3S2-001 | canonical TF, rejection for f10/f11 | PARTIALLY CONFORMING |
| |||
| CHoCH/MSS | CONFORMING (P3S3 E-1..E-10) | f8 state per contract; consumers stale (E-11) | f9/f18 stale | f8/f9 M15; Engine 2 per-TF | strict-vs-equal pivot drift (BUG-P3S3-002) | confirmation leg (A) / gate (B) | BUG-P3S3-001/-002 | MSS synonym, 2-3 definitions | PARTIALLY CONFORMING |
| |||
| FVG | CONFORMING geometry (P3S4 E-1/E-2/E-4/E-5/E-7) | zone persistent; invalidation not modeled | Engine 2 no mitigation (E-9) | per-TF; canonical AMBIGUOUS (A-3) | N/A by absence | zone leg (A) / gate (B) | BUG-P3S4-001/-002 | min-gap, timestamp, consumer scope | PARTIALLY CONFORMING |
| |||
| Order Block | CONFORMING current definition (P3S5 E-1..E-7) | zone persistent; invalidation not modeled | Engine 2 no mitigation/age (E-9) | per-TF; canonical AMBIGUOUS (A-4) | N/A by absence | zone leg (A) / gate (B) | BUG-P3S5-001; two OB defs (A-2) | strong-move vs structure-break | PARTIALLY CONFORMING |
| |||
| Displacement | CONFORMING (P3S6 E-1..E-7/E-10..E-12) | candle attribute, no stale | CONFORMING (E-14) | per-TF; canonical AMBIGUOUS (A-1) | N/A by absence | confirmation boost (A); not in B | BUG-P3S6-001 (1.5 vs 1.6) | terminology | CONFORMING |
| |||
| MTF | TF assignment/as-of CONFORMING (P3S7 S-T) | stateless agents; no stale | flat vote only; no cross-TF refs (S-R) | Engine 2 H4/M30/M15/M3 vs contract D1/H4/H1 | agent path N/A by absence (D-5) | vote layers; setup needs hierarchy | D-1/D-5/D-6/D-7 | conflict policy, strict hierarchy intent | PARTIALLY CONFORMING |
| |||
| Candidate Setup | E-rule (A) / gate chain (B) (P3S8 CS-1/CS-2) | A: none; B: freshness window | score-only downstream (D-9) | M15 chain; H4/M30 context | no setup layer anywhere (N/A by absence) | the central concept | D-8/D-9/D-10/D-11/D-12 | onset/completion/lifecycle/identity | SPECIFICATION AMBIGUOUS |
| |||
| |||
(Each row cites the corresponding docs/P3_S*_CONFORMANCE.md; historical
| |||
verdicts are NOT rewritten.)
| |||
| |||
---
| |||
| |||
## C. ROOT CAUSES
| |||
| |||
Ten shared root causes were identified and cross-referenced (full matrix in
| |||
docs/P3_S9_ROOT_CAUSE_MATRIX.md):
| |||
| |||
```text
| |||
A. Event/state confusion (Sweep, CHoCH, Candidate Setup)
| |||
B. Zone/mitigation consumer err (FVG, OB, Candidate Setup)
| |||
C. Duplicate event emission (Sweep, CHoCH, Candidate Setup)
| |||
D. Stale state consumption (Sweep, CHoCH, FVG, OB, Candidate Setup)
| |||
E. Multiple incompatible defs (ALL primitives)
| |||
F. Flat score as setup (MTF, Candidate Setup)
| |||
G. Timeframe role drift (MTF, Candidate Setup)
| |||
H. Training/runtime drift (CHoCH, MTF)
| |||
I. Missing setup identity (Candidate Setup)
| |||
J. Missing explicit lifecycle (Sweep, CHoCH, Candidate Setup)
| |||
```
| |||
| |||
Dominant conclusion: the DETECTORS are validated; the CONSUMER/CONTRACT layer
| |||
is where the bugs live. One consumer-contract layer (event/zone/state/
| |||
attribute contracts + setup entity) addresses A, B, C, D, I, J together.
| |||
| |||
---
| |||
| |||
## D. CANONICAL CANDIDATE SETUP PROPOSAL
| |||
| |||
### D.1 Definition (proposed canonical)
| |||
| |||
```text
| |||
A Candidate Setup is a discrete, causally-ordered entity created on the M15
| |||
entry layer when a COMPLETE sequence completes within its validity windows:
| |||
| |||
H4 context (narrative state, direction-compatible)
| |||
AND M30 context (zone state, direction-compatible)
| |||
AND liquidity sweep EVENT (fresh)
| |||
AND CHoCH/MSS EVENT (after the sweep, fresh, same direction)
| |||
AND price inside an UNMITIGATED OB or FVG zone (direction-compatible)
| |||
AND M15 entry condition (the zone membership + confirmation conjunction)
| |||
-> CANDIDATE SETUP (direction = chain direction)
| |||
[M3 micro-confirmation: OPTIONAL — moves the setup to CONFIRMED; its
| |||
absence does NOT invalidate the Candidate Setup.]
| |||
| |||
It is distinguished from (P3-S.8 R-1..R-5 kept):
| |||
market state : H4/M30 context states are INPUTS, not the setup.
| |||
event : sweep/CHoCH are STAGES of the setup, not the setup.
| |||
zone : OB/FVG membership is the ZONE stage, not the setup.
| |||
confirmation : the CHoCH/M15 confirmation is a STAGE, not the setup.
| |||
score : confluence/score may rank setups but does NOT create one.
| |||
signal : an ENTRY SIGNAL may only be emitted for a valid setup
| |||
(resolves D-9).
| |||
trade : execution (lot/SL/TP/result) is outside setup validity.
| |||
```
| |||
| |||
Source & justification:
| |||
```text
| |||
- The chain shape = the project's OWN legacy v4.x institutional gate
| |||
(P3-S.8 Definition B), the only real setup state machine in the repo.
| |||
- The direction-compatible context gates = the brief's causal order
| |||
(Liquidity -> Structure Change -> Zone -> Return -> Confirmation) and
| |||
the project's "top-down to the chart" analysis order (DESIGN.md §8).
| |||
- M3 optional = P3-S.7 S-P evidence ("M3 is NOT mandatory; can only reduce
| |||
support arithmetically") — NOT made mandatory here.
| |||
- The E-rule (Definition A) is retained ONLY as the M15 entry-condition
| |||
predicate inside the chain; it is no longer the whole setup.
| |||
```
| |||
| |||
### D.2 Why Definition A alone is insufficient (evidence)
| |||
| |||
```text
| |||
- No identity (P3-S.8 D-10), no lifecycle (A-5..A-7), no expiry (D-12),
| |||
no dedup (CS-T13), E-vote saturation hides the setup (D-11), score can
| |||
fire without it (D-9). It is a fuzzy contribution, not "ONE setup".
| |||
```
| |||
| |||
### D.3 Why Definition B is not restored verbatim (evidence)
| |||
| |||
```text
| |||
- Its HTF model is D1/H4/H1 (legacy), not the canonical H4/M30/M15/M3.
| |||
- Its score threshold is a signal filter entangled with the ML score (v4.4).
| |||
- It has no M3 layer, no setup identity, no setup lifecycle beyond
| |||
freshness, and no invalidation model.
| |||
- We EXTRACT its semantics (gates + sequence + freshness), we do NOT
| |||
restore its code (P3-S.9 §18).
| |||
```
| |||
| |||
---
| |||
| |||
## E. PRIMITIVE ROLES (proposed canonical)
| |||
| |||
| Primitive | Role (canonical) | Required? | Produces | Notes / evidence |
| |||
|---|---|---|---|---|
| |||
| H4 | CONTEXT (narrative state) | REQUIRED (direction-compatible for setup; per architecture decision, see F) | STATE | overrides P3-S.7 S-N permissiveness for the SETUP layer (signal layer unchanged) |
| |||
| M30 | CONTEXT (zone state) | REQUIRED (direction-compatible) | STATE | overrides P3-S.7 S-C permissiveness for the SETUP layer |
| |||
| Liquidity Sweep | EVENT (stage 1 of chain) | REQUIRED (with validity window) | EVENT | f7 semantics + 40-bar window (P3-S.0/P3-S.2) |
| |||
| CHoCH/MSS | STRUCTURAL CONFIRMATION EVENT (stage 2) | REQUIRED (after sweep, fresh) | EVENT | f8/f9 semantics + 40-bar window (P3-S.3 BUG-001 fix) |
| |||
| FVG | ZONE (stage 3, one of OB/FVG) | ALTERNATIVE (OB OR FVG) | ZONE | mitigation-aware membership (P3-S.4 BUG-001 fix) |
| |||
| OB | ZONE (stage 3, one of OB/FVG) | ALTERNATIVE (OB OR FVG) | ZONE | mitigation-aware membership (P3-S.5 BUG-001 fix) |
| |||
| Displacement | OPTIONAL CONFIRMATION (candle attribute) | OPTIONAL | ATTRIBUTE | boosts M15 confirmation; 1.6x constant (P3-S.6) |
| |||
| M15 | ENTRY CONDITION (the chain carrier) | REQUIRED (the setup layer) | CONDITION | E-rule retained as the entry predicate |
| |||
| M3 | MICRO CONFIRMATION (optional) | OPTIONAL | EVENT/CONDITION | S-P: not mandatory (P3-S.7) |
| |||
| |||
Rules:
| |||
```text
| |||
- No primitive may hold two conflicting roles without explicit justification;
| |||
the table above is the single role map.
| |||
- "NOT USED": none of the nine is unused in the canonical model (M3 is
| |||
optional but used; H4/M30 are context gates).
| |||
- FILTER: premium/discount position is a FILTER on the M15 entry (not in
| |||
premium for buy / not in discount for sell), carried from legacy B.
| |||
- SCORE CONTRIBUTION: confluence may RANK setups (post-creation); it never
| |||
creates one (resolves F/D-9).
| |||
```
| |||
| |||
---
| |||
| |||
## F. MTF HIERARCHY (decision proposal)
| |||
| |||
```text
| |||
Target: TRUE top-down dependencies, not labels.
| |||
| |||
H4 (Narrative STATE) -> direction-compatible context gate
| |||
M30 (Context STATE) -> direction-compatible context gate
| |||
M15 (Entry layer) -> the setup chain lives here
| |||
M3 (Price Action) -> optional micro-confirmation on the M15 setup
| |||
| |||
Answers (canonical proposal):
| |||
Can H4 alone create a setup? NO (context only; a state cannot be a setup)
| |||
Can M30 alone create a setup? NO (context only)
| |||
Can M15 alone create a setup? NO (chain requires H4+M30 context gates;
| |||
the E-rule alone = entry condition,
| |||
not a complete setup)
| |||
Can M3 alone create a setup? NO (micro-confirmation only)
| |||
| |||
Contradiction policy (proposal):
| |||
H4 vs M30 conflict -> NO setup (context gate fails) [B semantics]
| |||
M15 chain vs H4/M30 conflict -> NO setup (gate fails), NOT arithmetic
| |||
M3 vs setup conflict -> setup remains CANDIDATE (M3 optional);
| |||
a CONTRARY M3 only reduces the micro-score
| |||
| |||
Explicit override of P3-S.7 S-N/S-C permissiveness:
| |||
S-N/S-C ("CAN trigger entry alone; NO gate") described the CURRENT vote
| |||
model. The canonical SETUP layer replaces vote-permissiveness with gates;
| |||
the flat vote is retained ONLY as a signal-scoring mechanism on top of
| |||
valid setups (see D.1). This is an architecture DECISION PROPOSAL
| |||
(owner adjudication required — open decision OD-1).
| |||
| |||
Canonical MTF model (proposal):
| |||
Agent/setup path : H4/M30/M15/M3 (P3-S.7 assignments).
| |||
Training/contract: must be re-aligned to the same model in the future
| |||
implementation phase (D-5); the legacy D1/H4/H1 model is deprecated to
| |||
reference status (D-6).
| |||
```
| |||
| |||
---
| |||
| |||
## G. SETUP IDENTITY (design contract — not implemented)
| |||
| |||
```text
| |||
setup_id : monotonic integer, assigned at creation (CANDIDATE state).
| |||
direction : +1 bullish / -1 bearish (chain direction).
| |||
originating liquidity event : {sweep onset timestamp, sweep direction,
| |||
sweep validity window}
| |||
structure event : {choch onset timestamp, choch direction}
| |||
zone : {zone type (OB|FVG), zone id (formation timestamp),
| |||
boundaries, mitigation state at creation}
| |||
entry timeframe : M15 (fixed by construction)
| |||
creation timestamp: M15 bar timestamp when the chain completed
| |||
confirmation timestamp : M3 bar timestamp when M3_CONFIRMED (nullable)
| |||
expiry/invalidation reason : enumerated (EXPIRED|INVALIDATED|CONSUMED|NONE)
| |||
| |||
Uniqueness: two setups differ iff (direction, sweep onset, choch onset,
| |||
zone formation timestamp, creation timestamp) differ. This identity is
| |||
causal — every component is a dated event/zone/state from the chain.
| |||
```
| |||
| |||
---
| |||
| |||
## H. SETUP LIFECYCLE (proposed state machine, derived from evidence)
| |||
| |||
```text
| |||
NONE
| |||
|
| |||
v
| |||
CONTEXT_VALID (H4 + M30 direction-compatible states; as-of <= t)
| |||
|
| |||
v
| |||
LIQUIDITY_TRIGGERED (sweep EVENT fresh; validity window W_sweep)
| |||
|
| |||
v
| |||
STRUCTURE_CONFIRMED (CHoCH EVENT after sweep, fresh; window W_choch)
| |||
|
| |||
v
| |||
ZONE_READY (price inside an UNMITIGATED OB|FVG zone;
| |||
zone mitigation terminates ZONE_READY -> INVALIDATED)
| |||
|
| |||
v
| |||
ENTRY_ARMED (M15 entry condition holds; displacement may boost)
| |||
|
| |||
v
| |||
CANDIDATE_SETUP (COMPLETE — the chain is whole; direction fixed)
| |||
|--(optional M3 alignment)--> M3_CONFIRMED (micro-confirmed)
| |||
|--(setup validity window exceeded)-------> EXPIRED
| |||
|--(zone mitigated / contrary CHoCH / context break) -> INVALIDATED
| |||
|--(entry signal emitted from this setup)--> CONSUMED
| |||
```
| |||
| |||
Transitions (explicit):
| |||
```text
| |||
- Every stage requires the previous stage to be ACTIVE (no skipping).
| |||
- Sweep and CHoCH are EVENTS: they set the stage when they ONSET and the
| |||
stage expires when their validity window lapses.
| |||
- ZONE_READY requires an UNMITIGATED zone at every decision bar (a
| |||
mitigation mid-chain invalidates).
| |||
- ENTRY_ARMED is re-evaluated per M15 closed bar (price may leave the zone;
| |||
the setup is not destroyed by exit, it waits for re-entry while within
| |||
the setup validity window).
| |||
- CANDIDATE_SETUP is the terminal formation state; EXPIRED/INVALIDATED/
| |||
CONSUMED are terminal, non-reversible (no reactivation).
| |||
- A setup may emit AT MOST ONE entry signal (CONSUMED); a NEW setup requires
| |||
a new chain (dedup by identity, G).
| |||
```
| |||
| |||
Evidence basis: stage order = legacy B gates + brief causal order; M3
| |||
optional = S-P; mitigation invalidation = P3-S.4/S.5 mitigation semantics;
| |||
expiry = f7/f8 validity windows (P3-S.0/P3-S.3).
| |||
| |||
---
| |||
| |||
## I. EVENT / ZONE / STATE / ATTRIBUTE CONTRACTS
| |||
| |||
```text
| |||
EVENT (sweep, choch, m3): {timestamp, direction, validity_window,
| |||
superseded_by}. Consumers may read ONLY within [onset,
| |||
onset+window] and only if not superseded (fixes A/C/D).
| |||
ZONE (OB, FVG): {formation_timestamp, direction, top, bottom,
| |||
mitigation_state (UNMITIGATED|MITIGATED), invalidated(bool)}.
| |||
Consumers may read ONLY unmitigated, non-invalidated zones
| |||
(fixes B/D).
| |||
STATE (H4 narrative, M30 context): {value, as_of_bar}. Consumers may
| |||
read the newest closed value only (fixes A).
| |||
ATTRIBUTE (displacement): {value_at_closed_bar, direction}. No persistence,
| |||
no expiry (already conforming, P3-S.6).
| |||
CONDITION (M15 entry): {in_zone, confirmation, as_of_bar} — the E-rule
| |||
output, re-evaluated each closed bar (fixes D-11 by exposing the
| |||
setup predicate explicitly).
| |||
| |||
Consumer contract (the rule that prevents the f7/f9/f18 bug class):
| |||
A consumer of an EVENT must apply its validity window.
| |||
A consumer of a ZONE must apply mitigation/invalidation.
| |||
A consumer of a STATE must use the as-of closed value.
| |||
A consumer of a SETUP must use the setup identity + lifecycle, never the
| |||
raw detector states.
| |||
```
| |||
| |||
---
| |||
| |||
## J. LEGACY vs CURRENT ANALYSIS (P3-S.9 §18)
| |||
| |||
| Aspect | Legacy v4.x (B) | Current Engine 2 (A) | Verdict for canonical |
| |||
|---|---|---|---|
| |||
| Setup gate chain | YES (institutional gate) | NO (fuzzy rule) | REUSE the gate semantics |
| |||
| Causal order sweep->CHoCH->zone | YES (SeqWindow=40) | NO (same-bar OR) | REUSE the ordering |
| |||
| Freshness windows | YES (SeqWindow=40) | NO | REUSE, split per stage |
| |||
| HTF gate | D1/H4/H1 align | none (vote only) | REUSE as H4/M30 context gates |
| |||
| M3 | not used | vote 0.15 | ADD as optional confirmation |
| |||
| Setup identity | none | none | NEW (design contract G) |
| |||
| Lifecycle | freshness only | none | NEW (state machine H) |
| |||
| Score threshold | 70/60 + ML blend | 0.20/0.50 vote | REDESIGN: score ranks, does not create |
| |||
| D1/H4/H1 MTF | yes | H4/M30/M15/M3 | DEPRECATE D1/H4/H1 for the agent path |
| |||
| Detectors | per-TF legacy | per-TF Engine 2 | RETAIN Engine 2 detectors (validated) |
| |||
| |||
Must NOT be copied: the legacy ML-score entanglement, the InpOBStyle
| |||
volume-OB, the D1/H4/H1 model, the "score>=threshold fires" pattern, the
| |||
single SeqWindow reuse for every stage.
| |||
| |||
---
| |||
| |||
## K. ARCHITECTURE OPTIONS
| |||
| |||
### OPTION A — Hard Sequential Setup State Machine
| |||
| |||
```text
| |||
H4 Narrative -> M30 Context -> Liquidity -> CHoCH -> OB/FVG Zone -> M15
| |||
Entry -> [M3 optional] -> ONE CANDIDATE SETUP (state machine, §H)
| |||
```
| |||
| |||
### OPTION B — Hierarchical Candidate + Optional Confirmations
| |||
| |||
```text
| |||
H4 Narrative -> M30 Context -> M15 Candidate Setup
| |||
├── required structural conditions (soft conjunction, same-bar)
| |||
└── optional confirmations -> M3
| |||
(closest to Definition A with explicit required conditions)
| |||
```
| |||
| |||
Evaluation (semantic criteria only — no performance):
| |||
| |||
| Criterion | Option A | Option B | Evidence basis |
| |||
|---|---|---|---|
| |||
| Semantic clarity | HIGH (causal chain) | MEDIUM (soft conjunction) | brief §9 causal order; legacy B precedent |
| |||
| Causality | HIGH (explicit order + windows) | LOW-MED (same-bar) | P3-S.3 A-2, P3-S.8 D-8 |
| |||
| Deduplication | BY CONSTRUCTION (one chain -> one setup) | needs machinery | P3-S.8 CS-T13/D-10 |
| |||
| Setup identity | DERIVABLE (chain timestamps) | needs machinery | P3-S.8 D-10 |
| |||
| Lifecycle clarity | HIGH (explicit states) | LOW (undefined) | P3-S.8 A-5..A-7 |
| |||
| MTF hierarchy | HIGH (true dependencies) | MEDIUM (labels) | P3-S.7 D-1/G |
| |||
| Compatibility with primitives | HIGH (all 9 have a role) | MEDIUM (M15-only core) | §E table |
| |||
| Testability | HIGH (deterministic gates) | MEDIUM | P3-S.8 CS-T01..T25 method |
| |||
| Runtime determinism | HIGH (closed-bar + windows) | HIGH | Engine 1 lock |
| |||
| Training compatibility | MEDIUM (event->outcome mapping) | MEDIUM | P3-S.7 D-5 |
| |||
| Explainability | HIGH | MEDIUM | reason = chain stages |
| |||
| Minimal change to validated parts | MEDIUM (aggregator semantics change) | HIGH (aggregator kept) | detectors kept in both; D-9/D-1 implicate the aggregator |
| |||
| |||
### OPTION C (rejected without justification) — "Best of both" grab-bag
| |||
```text
| |||
Any architecture that mixes vote permissiveness + gates + arbitrary SMC
| |||
theory without per-behavior source/reason/testability is rejected by §21
| |||
of the brief. Options A and B are the two evaluated; no third option is
| |||
introduced "because it backtests better".
| |||
```
| |||
| |||
---
| |||
| |||
## L. RECOMMENDED ARCHITECTURE
| |||
| |||
```text
| |||
RECOMMENDATION: OPTION A — Hard Sequential Setup State Machine, with M3
| |||
OPTIONAL (per S-P evidence) and the flat vote retained ONLY as a
| |||
signal-scoring layer on top of valid setups.
| |||
| |||
Rationale (evidence-based):
| |||
1. Option A matches the project's ONLY real setup implementation (legacy B)
| |||
and the brief's own causal order — it is not an imported theory.
| |||
2. Root causes A (event/state), C (duplicate emission), D (stale), I
| |||
(identity), J (lifecycle) are structurally solved by a state machine
| |||
with per-stage windows and an identity; Option B solves none of them
| |||
without additional machinery.
| |||
3. Root cause F (score as setup) and the P3-S.8 D-9 drift are solved by
| |||
making the setup the gate for entry signals.
| |||
4. Detectors (the validated part, P3-S.2..S.6) are RETAINED unchanged; only
| |||
the consumer/aggregation semantics change.
| |||
5. The MTF hierarchy question (Q: H4/M30/M15/M3 participation) is answered
| |||
with TRUE dependencies (F), satisfying P3-S.7's "hierarchy not
| |||
implemented" finding.
| |||
| |||
EXPLICIT RESERVATIONS (owner adjudication required before implementation):
| |||
OD-1 Override of P3-S.7 S-N/S-C permissiveness (H4/M30 become gates for
| |||
the SETUP layer).
| |||
OD-2 Canonical MTF model for training (H4/M30/M15/M3 vs D1/H4/H1).
| |||
OD-3 Validity-window VALUES (W_sweep, W_choch, W_setup) — the state
| |||
machine is defined; the constants are design decisions.
| |||
OD-4 Conflict policy values (context-compatible thresholds).
| |||
```
| |||
| |||
---
| |||
| |||
## M. CONSEQUENCES
| |||
| |||
```text
| |||
1. Engine 2 aggregator semantics change: a BUY/SELL entry signal is only
| |||
valid when bound to a CANDIDATE_SETUP (or M3_CONFIRMED) entity; the
| |||
flat vote becomes a scoring/ranking function (resolves D-1 partially,
| |||
D-9 fully).
| |||
2. The E-rule is re-scoped to the M15 ENTRY CONDITION inside the chain;
| |||
the "setup" name is no longer a fuzzy weight (resolves D-8/D-11).
| |||
3. f7/f8/f9/f18 consumers get a shared EVENT contract with validity windows
| |||
(resolves BUG-P3S2-001, BUG-P3S3-001, and the D stale class).
| |||
4. Engine-2 FVG/OB consumers get a ZONE contract with mitigation
| |||
(resolves BUG-P3S4-001, BUG-P3S5-001).
| |||
5. Training surface: future feature/target design may move from
| |||
"all bars -> outcome" to "candidate setups -> outcome/meta-label"
| |||
(§17). This is PLANNING ONLY; no ML change now.
| |||
6. Display: "TRADE SETUP" panel must render the setup entity (id, stages,
| |||
lifecycle) rather than the bare vote signal (resolves D-9 display side).
| |||
7. Legacy v4.x remains a reference; its semantics are extracted, its code
| |||
is not restored (D-14 documented).
| |||
```
| |||
| |||
---
| |||
| |||
## N. FUTURE IMPLEMENTATION PHASES (design only — NOT started)
| |||
| |||
```text
| |||
PHASE 1 — Contracts (foundation):
| |||
- Introduce EVENT/ZONE/STATE/ATTRIBUTE contract structs + validity
| |||
helpers; wire the ML-path f7/f8/f9/f18 consumers to the contracts.
| |||
- Tests first: port P3-S.2/S.3 synthetic tests to assert expiry in
| |||
f9/f18.
| |||
| |||
PHASE 2 — Zone contract in Engine 2:
| |||
- AF_FindFVG/AF_FindOrderBlock mitigation-aware (or a consumer-side
| |||
filter); unify formation timing (BUG-P3S4-002) and OB definition
| |||
(BUG-P3S5-002 adjudication).
| |||
- Tests: extend P3-S.4/S.5 suites with mitigation cases.
| |||
| |||
PHASE 3 — Setup entity + state machine (Option A):
| |||
- Setup struct with identity (G), lifecycle (H), per-stage windows;
| |||
M15 chain consumer; H4/M30 context gates.
| |||
- Aggregator re-scoped to signal scoring on valid setups.
| |||
- Tests: P3-S.8 CS-T01..T25 re-expressed against the entity semantics.
| |||
| |||
PHASE 4 — MTF/training alignment:
| |||
- Adjudicate OD-1..OD-4; align FEATURE_CONTRACT/training to the canonical
| |||
MTF model (or document the divergence as intentional).
| |||
| |||
PHASE 5 — Regression + parity:
| |||
- Re-run Engine 1/2/3 unit tests, ML parity (SB-06 class), rebuild the
| |||
setup dataset; preserve historical evidence (immutable checkpoints).
| |||
```
| |||
| |||
*Each phase: tests first, one repair family at a time, historical evidence
| |||
preserved. NO implementation was performed in P3-S.9.*
| |||
| |||
---
| |||
| |||
## OPEN DESIGN DECISIONS (feed the final status)
| |||
| |||
```text
| |||
OD-1 H4/M30 as hard context gates (overrides P3-S.7 S-N/S-C for the SETUP
| |||
layer; the vote remains for signal scoring).
| |||
OD-2 Canonical MTF model (H4/M30/M15/M3 for agent+setup; D1/H4/H1
| |||
deprecated for the agent path).
| |||
OD-3 Validity window values (W_sweep, W_choch, W_setup, zone max age).
| |||
OD-4 Conflict policy (context-compatible thresholds; M3 contrary handling).
| |||
OD-5 OB canonical definition (strong-move vs structure-break) and the
| |||
OB/displacement constant unification (1.5 vs 1.6).
| |||
```
| |||
| |||
---
| |||
| |||
## ARCHITECTURE STATUS
| |||
| |||
```text
| |||
B. DESIGN DECISION REQUIRED
| |||
| |||
The architecture review is COMPLETE and actionable (Option A recommended,
| |||
setup identity + lifecycle + contracts + repair plan defined), but the
| |||
final architecture cannot be locked because:
| |||
- OD-1 overrides a previously verified spec statement (P3-S.7 S-N/S-C);
| |||
- OD-2 conflicts two verified MTF models (D-5) that affect training;
| |||
- OD-3/OD-4 require value/threshold decisions;
| |||
- primitive semantics still conflict (two OB definitions, FVG gap
| |||
filters, sweep canonical TF) per root cause E.
| |||
Per the brief, these must NOT be resolved with performance; they require
| |||
explicit owner/design adjudication before the implementation phase may
| |||
start. Candidate Setup semantics are now EXPLICITLY DEFINED as a proposal
| |||
(D.1) — the ambiguity recorded in P3-S.8 is resolved at the design level;
| |||
what remains is the decision to adopt it.
| |||
```
| |||
| |||
*Provenance: Forge HEAD 533c8c6647a552d01a1a290cb2d0505f94887666 (P3-S.6);
| |||
P3-S.7/P3-S.8 artifacts intact (uncommitted). No production file modified.
| |||
Human verification CANCELLED.*
|