24 KiB
24 KiB
P3-S.9 CROSS-PRIMITIVE ARCHITECTURE REVIEW — SNIPERGOLD_ML
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
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):
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)
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:
- 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)
- 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)
- 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:
- 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)
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)
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)
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):
- 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
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
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
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
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
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
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)
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)
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
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 533c8c6647 (P3-S.6);
P3-S.7/P3-S.8 artifacts intact (uncommitted). No production file modified.
Human verification CANCELLED.