forked from chiki2bum2/SniperGold_ML
654 lines
31 KiB
Markdown
654 lines
31 KiB
Markdown
# SMC CANDIDATE SETUP — PROJECT SEMANTIC SPECIFICATION v1
| |||
| |||
```text
| |||
Status : PROJECT SEMANTIC SPECIFICATION (not "universal SMC ground truth")
| |||
Session : P3-S.8 — Candidate Setup semantic validation
| |||
Date : 2026-08-22
| |||
Scope : What combination of market conditions constitutes ONE Candidate
| |||
Setup in SniperGold / Algo Forge, and how the concept is (or is not)
| |||
materialized in the current implementation. Defines the fundamental
| |||
distinction STATE vs EVENT vs ZONE vs CONFIRMATION vs CANDIDATE
| |||
SETUP vs ENTRY SIGNAL vs TRADE for this project. It is a
| |||
specification of the PROJECT model, NOT a claim of universal SMC
| |||
truth and NOT a performance claim.
| |||
Provenance : Forge HEAD 533c8c6647a552d01a1a290cb2d0505f94887666 (P3-S.6)
| |||
+ P3-S.7 artifacts (uncommitted, verified intact 2026-08-22)
| |||
DESIGN.md (Algo Forge), AF_Defines.mqh, AF_Engine1_MTFData.mqh,
| |||
AF_Engine2_Agents.mqh, AF_Engine2_Aggregator.mqh,
| |||
AF_Engine2_Display.mqh, AF_Engine3_Render.mqh,
| |||
FEATURE_CONTRACT.md, P3-S.2..P3-S.7 specs, legacy v4.3/v4.4/v4.5,
| |||
DESAIN_MTF_v45.md, P3.2 label forensics, P3.1c candidate-setup
| |||
audit (all reconciled)
| |||
Human verification : CANCELLED
| |||
```
| |||
| |||
> This document ESTABLISHES the project's Candidate Setup semantics, derived
| |||
> from (a) design intent (DESIGN.md Engines 1-3), (b) the current
| |||
> implementation (Engine 2 agents + aggregator), (c) the legacy v4.x signal
| |||
> implementation (the only code in the repository that materializes a
| |||
> hard-gated setup sequence), (d) the Feature Contract / training semantics,
| |||
> and (e) logical requirements (closed-bar / as-of, no look-ahead, no silent
| |||
> semantic collapse). It does NOT claim that Candidate Setups create a
| |||
> trading edge, and it does NOT invent rules where the project is silent.
| |||
| |||
---
| |||
| |||
## 1. THE FUNDAMENTAL DISTINCTION (CORE)
| |||
| |||
The project distinguishes seven concepts. They are NOT equivalent unless the
| |||
project explicitly makes them equivalent (this specification records where
| |||
that happens):
| |||
| |||
```text
| |||
MARKET STATE : a persistent property of price/structure at time t
| |||
(e.g., "H4 bullish", "M15 in discount", "M30 trend down").
| |||
Project carriers: H4 narrative bias, M30 context zone,
| |||
structure/trend labels, premium/discount position.
| |||
| |||
EVENT : a discrete, timestamped occurrence with an onset and a
| |||
(possibly bounded) validity window (e.g., a liquidity
| |||
sweep onset, a CHoCH break). Project carriers: sweep
| |||
(f7 / AF_DetectSweep), CHoCH (f8/f9 / AF_DetectChoch),
| |||
EQH/EQL swept (f10/f11), OB/FVG formations (zones).
| |||
| |||
ZONE : a bounded price region created by an event/formation
| |||
that remains relevant until filled/mitigated or
| |||
invalidated (e.g., an OB or FVG). Project carriers:
| |||
AF_FindOrderBlock / AF_FindFVG (Engine 2),
| |||
AF_CollectOBs / AF_CollectFVG (display), FindEntryOB /
| |||
FindEntryFVG (legacy v4.x).
| |||
| |||
CONFIRMATION : an additional condition that raises the meaning of a
| |||
zone/state from "present" to "actionable" (e.g., price
| |||
displacement, CHoCH after a sweep). Project carriers:
| |||
AF_DetectDisplacement, the E-agent confirmation legs
| |||
(sweep/CHoCH), the legacy "CHoCH after sweep" rule.
| |||
| |||
CANDIDATE SETUP : the project-specific combination of zone + confirmation
| |||
(see §4). This is the ONLY concept the project names
| |||
"setup" in its design documents.
| |||
| |||
ENTRY SIGNAL : the final aggregated decision to act (BUY/SELL/WAIT) —
| |||
in the current implementation a flat weighted vote; in
| |||
the legacy implementation a gated confluence score
| |||
passing a threshold.
| |||
| |||
TRADE : actual execution (order, SL/TP, lot, result). Carriers:
| |||
AlgoForge_Backtest_Baseline mode 1, legacy signal arrows.
| |||
Explicitly OUT of scope for setup validity in this spec.
| |||
```
| |||
| |||
Rules derived from the reconciliation (no silent collapse):
| |||
| |||
```text
| |||
R-1 A MARKET STATE is not an EVENT (a trend label does not fire an onset).
| |||
R-2 An EVENT is not a ZONE (a sweep onset is not an OB/FVG region), though
| |||
it may CREATE one in some methodologies — the project does not model
| |||
event->zone creation (sweep does not create the OB; CHoCH does not
| |||
create the FVG; zones are detected independently).
| |||
R-3 A ZONE alone is not a CANDIDATE SETUP (zone is only the ZONE leg of the
| |||
E-agent rule; confirmation is required by the rule).
| |||
R-4 A CANDIDATE SETUP is not an ENTRY SIGNAL (the E-agent rule contributes
| |||
to the E vote; the entry signal is the aggregator output, which can
| |||
exist without any setup — verified by unit test T6 and MTF-T19/T20/T22).
| |||
R-5 An ENTRY SIGNAL is not a TRADE (execution semantics are separate).
| |||
```
| |||
| |||
---
| |||
| |||
## 2. SOURCE RECONCILIATION — FIVE SEMANTIC LAYERS
| |||
| |||
### 2.1 INTENDED SETUP SEMANTICS (design documents)
| |||
| |||
```text
| |||
DESIGN.md §9 (E-agent) : "Sweep, CHoCH, displacement, OB/FVG zones; rule
| |||
ZONE + CONFIRMATION = setup".
| |||
DESIGN.md §14 : Dashboard element "trade setup" (final signal +
| |||
entry/SL/TP/R:R).
| |||
P3-S.7 spec §4 (S-E) : "candidate setup : OB/FVG zone membership (ZONE)";
| |||
"entry structure : sweep / CHoCH / displacement
| |||
(CONFIRMATION)"; "signal : ZONE + CONFIRMATION =
| |||
setup rule (internal to the E agent)".
| |||
P3-S.2..S.6 conformance : each concept ends with "-> ... -> Candidate Setup
| |||
(zone + confirmation = setup; DESIGN.md §9)".
| |||
```
| |||
| |||
### 2.2 LEGACY SETUP SEMANTICS (v4.3 / v4.4 / v4.5 — reference, not current engine)
| |||
| |||
The ONLY code that materializes a hard-gated Candidate Setup sequence:
| |||
| |||
```text
| |||
Inputs (v4.3:86-90, v4.4:95-98, v4.5:104-107):
| |||
InpRequireHTFAlign = true "All 3 HTFs must agree to allow a signal"
| |||
InpRequireSweep = true "Require a liquidity sweep before entry"
| |||
InpRequireCHoCH = true "Require a CHoCH after the sweep"
| |||
InpEntryOnFVGorOB = true "Entry must tap a fresh OB or FVG"
| |||
InpSeqWindow = 40 "Max bars: sweep -> CHoCH -> entry must chain"
| |||
| |||
Gate (v4.3:975-982, v4.4:1066-1073, v4.5:1010-1011):
| |||
buyGate = buyCtx && (!InpRequireSweep || sweepBull)
| |||
&& (!InpRequireCHoCH || chochBull)
| |||
&& (!InpEntryOnFVGorOB|| buyEntry) && !inPremium
| |||
sellGate = sellCtx && (!InpRequireSweep || sweepBear)
| |||
&& (!InpRequireCHoCH || chochBear)
| |||
&& (!InpEntryOnFVGorOB|| sellEntry) && !inDiscount
| |||
buyCtx = (g_bias>0) && alignBull (chart bias + 3-HTF stack)
| |||
sweepBull/Bear = g_swpDir==+/-1 && (curBar-g_swpBar)<=InpSeqWindow
| |||
chochBull/Bear = g_chochDir==+/-1 && g_chochBar>=g_swpBar
| |||
&& (curBar-g_chochBar)<=InpSeqWindow
| |||
buyEntry = price taps a fresh (unmitigated) OB or FVG on the bull side
| |||
| |||
Confluence score (only fired legs contribute; v4.3:990-1000):
| |||
align +25, discount/premium +15/-15, sweep +15, choch +15, OB tap +15,
| |||
FVG +10, EQH/EQL swept +5, delta +10.
| |||
Signal: buyGate && score >= InpSignalThreshold (70 v4.3 / 60 v4.4/v4.5 +
| |||
ML score blend) && score side wins.
| |||
Sequence state machine (signal notes): "Bullish HTF - waiting for sell-side
| |||
sweep" -> "Sweep done - waiting bullish CHoCH" -> "Confirmed - wait
| |||
pullback to bullish OB" -> signal.
| |||
```
| |||
| |||
### 2.3 CURRENT IMPLEMENTATION (Engine 2, Algo Forge — the audited runtime)
| |||
| |||
```text
| |||
AF_Engine2_Agents.mqh:
| |||
N (H4) : trend/CHoCH/BOS/sweep/premium-discount -> fuzzy vote.
| |||
C (M30) : OB/FVG/S-R/premium-discount zone membership -> fuzzy vote.
| |||
E (M15) : sweep/CHoCH/displacement + OB/FVG zone; rule
| |||
conf = max(sweep, choch); setupRule = min(zone, conf) * wSetup
| |||
(wSetup=0.30 normalized) -> fuzzy vote.
| |||
P (M3) : candle patterns -> fuzzy vote.
| |||
AF_Engine2_Aggregator.mqh: flat 2-pass weighted vote (0.30/0.30/0.25/0.15)
| |||
+ 1.5x majority boost; thresholds 0.20/0.50; entry/SL/TP on M15 slot.
| |||
NO setup identity, NO setup lifecycle, NO deduplication, NO SeqWindow,
| |||
NO hard gates, NO HTF-align gate.
| |||
```
| |||
| |||
### 2.4 TRAINING SEMANTICS (Feature Contract + Python)
| |||
| |||
```text
| |||
FEATURE_CONTRACT.md: 19 per-bar M15 features (+D1/H4/H1 biases f0-f2).
| |||
f7 sweep_dir with P3-S.0 lifecycle (onset..onset+SeqWindow=40).
| |||
f8 choch_dir persistent (no expiry). f9 choch_confirms (sweep+choch
| |||
same direction, no zone, no window). f18 confluence heuristic score.
| |||
NO feature named "setup"; NO setup unit; NO setup id.
| |||
Python P3.1c candidate_setup_audit.py (diagnostic ONLY, not promoted):
| |||
"candidate setup" strata = per-bar feature masks, e.g.
| |||
BUY_candidate = (f9==1)&(f7>0); BUY_strict = + (f18>=60).
| |||
Empirically median gap between candidate bars = 1 bar (no dedup).
| |||
```
| |||
| |||
### 2.5 DISPLAY / SCORING SEMANTICS (Engine 3)
| |||
| |||
```text
| |||
AF_Engine2_Display.mqh + AF_Engine3_Render.mqh:
| |||
"TRADE SETUP" panel (top-right) = aggregated signal dir + entry/SL/TP/R:R
| |||
(AF_Engine3_Render.mqh:272-278). It displays the FINAL VOTE SIGNAL, not a
| |||
setup entity. No setup count/identity/timestamp is rendered.
| |||
```
| |||
| |||
---
| |||
| |||
## 3. THE DUAL DEFINITION PROBLEM (RECORDED, NOT RESOLVED)
| |||
| |||
The reconciliation exposes TWO materially different Candidate Setup
| |||
definitions in the repository:
| |||
| |||
```text
| |||
DEFINITION A (current Engine 2 / DESIGN.md / P3-S.7 spec):
| |||
Candidate Setup = the per-bar E-agent (M15) rule
| |||
ZONE(OB or FVG membership, +/-0.3 ATR trap)
| |||
AND CONFIRMATION(max(sweep, choch)) [displacement only boosts weight]
| |||
at the SAME closed bar. It is a fuzzy contribution to the E vote, NOT a
| |||
discrete entity. No identity, onset, completion, expiry, dedup.
| |||
| |||
DEFINITION B (legacy v4.3/v4.4/v4.5, still present as reference):
| |||
Candidate Setup = a hard-gated causal sequence on M15
| |||
HTF-align (D1/H4/H1 agree + chart bias)
| |||
-> fresh liquidity sweep (age <= SeqWindow=40)
| |||
-> CHoCH AFTER the sweep (fresh <= SeqWindow=40)
| |||
-> price taps a fresh OB or FVG
| |||
-> not in premium/discount
| |||
-> confluence score >= threshold (this last step = ENTRY SIGNAL)
| |||
with an explicit sequence state machine and freshness window.
| |||
| |||
The two definitions disagree on the fundamental questions (see §5-§17).
| |||
Per P3-S.7 (S-H/S-A) the current project model is DEFINITION A; the legacy
| |||
model is reference material. The divergence itself is a finding
| |||
(SETUP-SEMANTIC DIVERGENCE, D-8), NOT silently resolved here.
| |||
```
| |||
| |||
---
| |||
| |||
## 4. FORMAL DEFINITION (PROJECT MODEL = DEFINITION A, with B recorded)
| |||
| |||
```text
| |||
CS-1 CANDIDATE SETUP (formal, Definition A):
| |||
At a closed M15 bar t, the E-agent rule fires with direction d iff
| |||
zone_d(t) > 0 AND conf_d(t) > 0
| |||
where
| |||
zone_d(t) = price inside a d-side OB or FVG zone (trap
| |||
[zoneLo-0.3*ATR, zoneHi+0.3*ATR]; AF_MF_Trap),
| |||
conf_d(t) = max(sweep_d(t), choch_d(t)) (same-bar values).
| |||
The rule contributes fuzzy weight wSetup (0.30, normalized) to the E
| |||
vote; it is the ONLY formal "setup" in the current project model.
| |||
| |||
CS-2 CANDIDATE SETUP (recorded, Definition B — legacy):
| |||
The ordered gate chain of §2.2 with default gates
| |||
{HTF-align, sweep, CHoCH, OB/FVG tap, not-premium/discount} all HARD
| |||
and a freshness window SeqWindow=40 for sweep/CHoCH. Setup onset =
| |||
the entry-tap bar; signal = score >= threshold on the same bar.
| |||
| |||
CS-3 Everywhere this spec says "setup" without a qualifier, it means
| |||
Definition A (the current model). Definition B is audited separately
| |||
in the conformance report as LEGACY SETUP SEMANTICS.
| |||
```
| |||
| |||
---
| |||
| |||
## 5. REQUIRED COMPONENTS
| |||
| |||
Per Definition A (current model — the audited runtime):
| |||
| |||
| Component | Classification (A) | Basis |
| |||
|----------------|--------------------|-------|
| |||
| H4 narrative | CONTEXT ONLY + VOTE (0.30); NOT required for a setup | S-N (P3-S.7); E-agent never reads H4 |
| |||
| M30 context | CONTEXT ONLY + VOTE (0.30); NOT required | S-C; no M30 read in E |
| |||
| Liquidity Sweep| CONFIRMATION (one of two OR legs of conf) — NOT individually required; conf = max(sweep, choch) | E-agent rule (AF_Engine2_Agents.mqh:647-651) |
| |||
| CHoCH/MSS | CONFIRMATION (the other OR leg) — NOT individually required | same |
| |||
| Order Block | ZONE (one of two OR zone legs) — NOT individually required; zone = max(OB, FVG) membership | E-agent rule |
| |||
| FVG | ZONE (the other OR leg) — NOT individually required | E-agent rule |
| |||
| Displacement | CONFIRMATION BOOST (OPTIONAL; raises wDisp x1.3; not a leg) | E-agent weights |
| |||
| M15 entry cond | TRIGGER (the rule itself: ZONE + CONFIRMATION) | CS-1 |
| |||
| M3 confirmation| CONFIRMATION + VOTE (0.15); NOT required (S-P) | P3-S.7 S-P |
| |||
| Direction | TRIGGER OUTPUT (side of the rule; final via vote) | CS-1, CS-6 |
| |||
| |||
Per Definition B (legacy — recorded, not the audited runtime):
| |||
| |||
| Component | Classification (B) | Basis |
| |||
|-----------------|--------------------|-------|
| |||
| HTF alignment | HARD REQUIREMENT (gate; toggleable, default ON) | InpRequireHTFAlign |
| |||
| Liquidity Sweep | HARD REQUIREMENT (gate; default ON) | InpRequireSweep |
| |||
| CHoCH/MSS | HARD REQUIREMENT (gate; default ON, must be AFTER sweep) | InpRequireCHoCH |
| |||
| OB or FVG | HARD REQUIREMENT (gate: entry must tap one; default ON) | InpEntryOnFVGorOB |
| |||
| Premium/Discount| FILTER (must NOT be in premium for buy / discount for sell) | buyGate/sellGate |
| |||
| Confluence score| SCORE + ENTRY TRIGGER (>= threshold) | InpSignalThreshold |
| |||
| M3 | NOT USED | no M3 in v4.x |
| |||
| |||
---
| |||
| |||
## 6. CAUSAL ORDER
| |||
| |||
```text
| |||
CS-4 Definition A (current): NO cross-bar causal order is required or
| |||
enforced. The rule is SAME-BAR: zone_d(t) and conf_d(t) must both be
| |||
true at t. What may happen in parallel: zone and confirmation are
| |||
evaluated from the same closed bar set. What may happen afterward:
| |||
the E vote is aggregated with N/C/P (same bar). The legacy notion
| |||
"CHoCH must occur after the sweep" does NOT exist in the E-agent rule
| |||
(AF_DetectChoch is a per-bar state detector; AF_DetectSweep likewise).
| |||
-> SPECIFICATION AMBIGUOUS for cross-bar order in Definition A.
| |||
| |||
CS-5 Definition B (legacy): REQUIRED order
| |||
HTF-align (context) -> Sweep -> CHoCH(after sweep) -> OB/FVG tap
| |||
-> premium/discount filter -> score threshold (signal).
| |||
All within InpSeqWindow=40 for the sweep/CHoCH legs.
| |||
| |||
CS-6 The project does NOT define "what must happen first" for Definition A
| |||
beyond the same-bar conjunction. Do not infer a sequence from source
| |||
order (AF_Engine2_Agents.mqh computes sweep, choch, disp, ob, fv in
| |||
code order; that is not a causal requirement).
| |||
```
| |||
| |||
---
| |||
| |||
## 7. SETUP ONSET
| |||
| |||
```text
| |||
CS-7 Definition A: NO discrete onset is defined. The E-rule is a per-bar
| |||
boolean-ish fuzzy contribution; it "fires" on any bar where the
| |||
conjunction holds and stops being counted on the next bar where it
| |||
does not. There is no onset timestamp, no formation bar, no event
| |||
object.
| |||
-> SPECIFICATION AMBIGUOUS (the project does not define onset).
| |||
| |||
CS-8 Definition B: onset = the entry-tap bar (the bar where the full gate
| |||
chain first passes). This is the only project code that has a setup
| |||
onset, and it is not part of the current Engine-2 runtime.
| |||
```
| |||
| |||
---
| |||
| |||
## 8. SETUP COMPLETION
| |||
| |||
```text
| |||
CS-9 Definition A: NO completion state. The rule either contributes at a
| |||
bar or it does not; there is no FORMING -> CANDIDATE -> CONFIRMED
| |||
transition. Entry signal (aggregator dir != 0) is a SEPARATE concept.
| |||
-> SPECIFICATION AMBIGUOUS (completion is not defined).
| |||
| |||
CS-10 Definition B: completion = all gates true AND score >= threshold on
| |||
the same bar -> signal (BUY/SELL). Candidate Setup != Entry signal in
| |||
B as well (a completed gate chain with score below threshold is a
| |||
"pending/confirmed" setup without a signal; see signal notes).
| |||
```
| |||
| |||
---
| |||
| |||
## 9. SETUP DIRECTION
| |||
| |||
```text
| |||
CS-11 Definition A: the E-rule side (bull/bear) sets the setup direction;
| |||
the FINAL direction is the aggregator vote, which can disagree with
| |||
the E-rule side (e.g., E bearish setup + N/C/P bullish -> BUY).
| |||
H4 does NOT determine direction; it is a 0.30 vote. M30 does NOT
| |||
confirm direction; it is a 0.30 vote. M15 determines the setup side
| |||
(E-rule). M3 does NOT confirm; it is a 0.15 vote.
| |||
Contradictions (H4 bull / M30 bear / M15 bull / M3 bull) are resolved
| |||
arithmetically (no conflict policy; P3-S.7 S-X).
| |||
| |||
CS-12 Definition B: direction = the chain side; HTF alignment (3 HTFs) must
| |||
agree with the chart bias (buyCtx/sellCtx) or the gate fails
| |||
(contradiction -> NO signal, not arithmetic compromise).
| |||
```
| |||
| |||
---
| |||
| |||
## 10. MTF ROLE IN CANDIDATE SETUP
| |||
| |||
```text
| |||
CS-13 Can H4 alone create a Candidate Setup?
| |||
A: NO (a setup requires the M15 E-rule; H4 is context/vote only).
| |||
H4 alone CAN create an ENTRY SIGNAL (flat vote, MTF-T19) — signal
| |||
without setup is possible by design (R-4).
| |||
B: NO (setup requires the M15 sweep/CHoCH/OB-FVG chain).
| |||
CS-14 Can M30 alone create a Candidate Setup?
| |||
A: NO (same reason). M30 alone can create an ENTRY SIGNAL (MTF-T20
| |||
class).
| |||
B: NO (M30 is not used by v4.x at all).
| |||
CS-15 Can M15 alone create a Candidate Setup?
| |||
A: YES — the E-rule is entirely M15-internal (zone + confirmation
| |||
from the M15 slot; MTF-T20 class). Whether that yields an entry
| |||
signal depends on the vote.
| |||
B: NO — the M15 chain requires the 3-HTF alignment gate (buyCtx).
| |||
CS-16 Can M3 alone create a Candidate Setup?
| |||
A: NO (P has no zone/confirmation; only candle patterns). M3 alone
| |||
can create an ENTRY SIGNAL (MTF-T22).
| |||
B: NO (M3 not used).
| |||
CS-17 Lower-TF requirements vs higher-TF states (hierarchy):
| |||
Definition A: NONE. No M15 condition requires an H4/M30 state; no M3
| |||
condition requires an M15 state (P3-S.7 S-R: no cross-TF refs).
| |||
Definition B: M15 chain requires the 3-HTF alignment gate.
| |||
```
| |||
| |||
---
| |||
| |||
## 11. REQUIRED RELATIONSHIPS BETWEEN PRIMITIVES
| |||
| |||
Per Definition A (current model):
| |||
| |||
| Relationship | Classification (A) | Evidence |
| |||
|---------------------|--------------------|----------|
| |||
| Liquidity -> CHoCH | INDEPENDENT (same-bar OR legs; no ordering) | conf = max(sweep, choch) |
| |||
| CHoCH -> OB | INDEPENDENT (no coupling) | separate detectors |
| |||
| CHoCH -> FVG | INDEPENDENT | separate detectors |
| |||
| Displacement -> OB | NOT USED (no displacement-zone coupling) | E-agent code |
| |||
| Displacement -> FVG | NOT USED | E-agent code |
| |||
| OB -> Entry | OPTIONAL (one of two zone legs; entry signal needs vote) | zone = max(OB, FVG) |
| |||
| FVG -> Entry | OPTIONAL (the other zone leg) | same |
| |||
| M15 -> M3 | INDEPENDENT (no M15 read in P; S-R) | agent code |
| |||
| M30 -> M15 | INDEPENDENT (no filter; only vote-level) | S-C / S-R |
| |||
| H4 -> M30 | INDEPENDENT (no coupling) | S-R |
| |||
| |||
Per Definition B (legacy):
| |||
| |||
| Relationship | Classification (B) |
| |||
|-------------------|--------------------|
| |||
| Liquidity -> CHoCH| REQUIRED (CHoCH must be after sweep, fresh) |
| |||
| CHoCH -> OB/FVG | REQUIRED (entry must tap a fresh zone) |
| |||
| OB/FVG -> Entry | REQUIRED (tap) |
| |||
| HTF -> M15 chain | REQUIRED (3-HTF align gate) |
| |||
| |||
---
| |||
| |||
## 12. ALTERNATIVE SETUP PATHS
| |||
| |||
```text
| |||
CS-18 Definition A explicitly permits four same-bar paths (alternatives):
| |||
P1 Sweep + OB zone
| |||
P2 Sweep + FVG zone
| |||
P3 CHoCH + OB zone
| |||
P4 CHoCH + FVG zone
| |||
(conf = max(sweep,choch); zone = max(OB,FVG) membership; displacement
| |||
may boost confirmation weight but never substitutes a leg).
| |||
NOT permitted by Definition A: "sweep OR OB OR FVG OR CHoCH" as
| |||
standalone alternatives — a setup needs BOTH a zone leg AND a
| |||
confirmation leg (min(zone,conf) = 0 otherwise).
| |||
| |||
CS-19 Definition B permits exactly one path (the gate chain), with only the
| |||
zone leg OR-ed (OB or FVG tap).
| |||
```
| |||
| |||
---
| |||
| |||
## 13. CONFLUENCE VS REQUIREMENT (CRITICAL)
| |||
| |||
```text
| |||
CS-20 Definition A (current model):
| |||
HARD REQUIREMENTS (for the E-rule to be a setup): zone_d>0 AND
| |||
conf_d>0 at the same M15 bar. There are NO other hard requirements.
| |||
SCORE CONTRIBUTIONS (everything else): H4 vote, M30 vote, M3 vote,
| |||
E vote, aggregator bias/support — all contribute to the ENTRY SIGNAL,
| |||
not to setup existence.
| |||
A Candidate Setup must NOT emerge merely because unrelated scores add
| |||
up: the aggregator can produce BUY with zero setup contribution
| |||
(e.g., N+C+P strong, E neutral) — that is an ENTRY SIGNAL WITHOUT a
| |||
CANDIDATE SETUP (allowed by R-4, but see D-9).
| |||
| |||
CS-21 Definition B (legacy):
| |||
HARD REQUIREMENTS: HTF-align, sweep, CHoCH-after-sweep, OB/FVG tap,
| |||
not-premium/discount (all default ON).
| |||
SCORE CONTRIBUTIONS: confluence legs + threshold -> signal.
| |||
```
| |||
| |||
---
| |||
| |||
## 14. CANDIDATE SETUP VS SCORE
| |||
| |||
```text
| |||
CS-22 The aggregator (AF_Engine2_Aggregator.mqh) outputs direction + buy/
| |||
sell/bias/score/confidence + levels. It NEVER outputs a setup object.
| |||
A high score (|bias|, confidence) is NOT equivalent to a valid
| |||
Candidate Setup: the score can be high with the E-agent neutral or
| |||
with no zone/confirmation anywhere (single-TF permissiveness).
| |||
The display "TRADE SETUP" panel renders the SCORE/SIGNAL, not a setup.
| |||
-> SETUP-CONSTRUCTION DRIFT (D-9): the runtime can emit BUY/SELL
| |||
without the E-rule setup; the "setup" label in the dashboard refers
| |||
to the aggregated signal. Documented, not repaired.
| |||
```
| |||
| |||
---
| |||
| |||
## 15. SETUP DEDUPLICATION
| |||
| |||
```text
| |||
CS-23 Definition A: NO deduplication. The E-rule is per-bar and stateless;
| |||
it can fire on consecutive bars, and each bar contributes a fresh E
| |||
vote. There is no setup identity, no setup_id, no formation
| |||
timestamp, no originating liquidity event, no originating zone field.
| |||
-> SETUP-IDENTITY GAP (D-10).
| |||
CS-24 Definition B: freshness is enforced only by the SeqWindow age bound on
| |||
sweep/CHoCH; the same gate can pass on consecutive bars (no identity).
| |||
Zone dedup exists only in the display collector
| |||
(AF_CollectOBs dedupe 0.5 ATR), not in the signal path.
| |||
CS-25 The project semantics do not support an arbitrary setup_id; the spec
| |||
records the absence rather than inventing an identifier.
| |||
```
| |||
| |||
---
| |||
| |||
## 16. SETUP LIFECYCLE
| |||
| |||
```text
| |||
CS-26 Definition A: NO lifecycle states. NOT_PRESENT/FORMING/CANDIDATE/
| |||
CONFIRMED/EXPIRED/INVALIDATED/CONSUMED do not exist in Engine 2.
| |||
The E-rule is a per-bar function of closed bars. There is no state
| |||
to expire, invalidate, reactivate, or consume; no multiple-entry
| |||
question arises at the setup layer (multiple entry signals can arise
| |||
from the vote, one per bar, with no identity to link them).
| |||
-> SPECIFICATION AMBIGUOUS (lifecycle not defined for A).
| |||
CS-27 Definition B: implicit freshness lifecycle only: sweep/CHoCH active
| |||
while age <= SeqWindow=40; entry zones "fresh" = unmitigated
| |||
(FindEntryOB/FVG). No EXPIRED/INVALIDATED/CONSUMED states; no
| |||
reactivation rule.
| |||
```
| |||
| |||
---
| |||
| |||
## 17. SETUP WINDOW
| |||
| |||
```text
| |||
CS-28 InpSeqWindow = 40 governs, in the whole repository:
| |||
1. f7 sweep event validity in the ML path
| |||
(EA AlgoForge_Backtest_Baseline.mq5: "sweep -> CHoCH -> entry
| |||
chain window = event validity/expiry for f7"; v4.4:963; v4.5:923;
| |||
P3-S.0 f7 lifecycle fix: onset..onset+40).
| |||
2. The legacy v4.x signal gates sweepBull/Bear and chochBull/Bear
| |||
freshness (v4.3:958-961, v4.4:1049-1052, v4.5:998-1001).
| |||
It does NOT govern: Engine 2 (no SeqWindow constant exists in
| |||
AF_Defines.mqh), the E-rule (no age bound), the aggregator (no
| |||
window), or the display.
| |||
| |||
CS-29 Per-window intervals (recorded):
| |||
Sweep -> CHoCH allowed interval : legacy only, both within 40 bars,
| |||
CHoCH bar >= sweep bar.
| |||
CHoCH -> zone allowed interval : legacy only, zone tap must be on a
| |||
fresh (unmitigated) zone; no age
| |||
bound in Engine 2.
| |||
zone -> entry allowed interval : same-bar in A (rule), tap in B.
| |||
entry -> M3 confirmation interval: NOT DEFINED (M3 is an independent
| |||
vote; no interval exists).
| |||
```
| |||
| |||
---
| |||
| |||
## 18. CLOSED-BAR / CAUSALITY CONTRACT
| |||
| |||
```text
| |||
CS-30 For any decision at timestamp t:
| |||
H4_asof(t) <= t, M30_asof(t) <= t, M15_asof(t) <= t, M3_asof(t) <= t
| |||
(Engine 1 closed-bar lock; P3-S.7 S-T). The E-rule, the agents, and
| |||
the aggregator consume only Engine-1 closed bars. No future
| |||
confirmation may be used. Synthetic tests mutate future bars and
| |||
verify past setup decisions do not change (CS-T17).
| |||
```
| |||
| |||
---
| |||
| |||
## 19. CANDIDATE SETUP VS TRADE EXECUTION
| |||
| |||
```text
| |||
CS-31 The Candidate Setup specification is deliberately free of risk/
| |||
execution semantics: lot size, SL/TP distance, spread, execution,
| |||
trade result are NOT part of setup validity. Entry/SL/TP levels in
| |||
AFAggOut are a POST-SETUP convenience (computed on the M15 slot when
| |||
dir != 0), not setup requirements. The legacy v4.x signal carries
| |||
entry/SL/TP as exploitation data, not as setup validity inputs.
| |||
```
| |||
| |||
---
| |||
| |||
## 20. CROSS-PRIMITIVE CONSISTENCY MATRIX
| |||
| |||
| Concept | Role in Candidate Setup (A) | Required? (A) | Produces Event? | Produces Zone? | Confirmation? |
| |||
|-----------------|-----------------------------|---------------|-----------------|----------------|---------------|
| |||
| Liquidity Sweep | confirmation leg (OR) | no (with CHoCH alt.) | YES (per-bar state; f7 onset+window in ML path) | NO | YES (one leg) |
| |||
| CHoCH/MSS | confirmation leg (OR) | no (with sweep alt.) | YES (per-bar state; f8 persistent) | NO | YES (one leg) |
| |||
| FVG | zone leg (OR) | no (with OB alt.) | YES (formation) | YES | NO |
| |||
| OB | zone leg (OR) | no (with FVG alt.) | YES (formation) | YES | NO |
| |||
| Displacement | confirmation boost | no | YES (per-bar candle attr) | NO | PARTIAL (boost only) |
| |||
| H4 | context + vote (0.30) | no | (structure events per-TF) | NO | NO (vote) |
| |||
| M30 | context + vote (0.30) | no | (zones per-TF) | YES (OB/FVG/S-R context) | NO (vote) |
| |||
| M15 | the setup layer (E-rule) | YES (zone+conf) | YES | YES (OB/FVG) | YES (the rule) |
| |||
| M3 | confirmation + vote (0.15) | no | (candle patterns) | NO | NO (vote only) |
| |||
| |||
Contradiction flags (recorded, NOT resolved):
| |||
| |||
```text
| |||
X-6 Liquidity Sweep: ML contract = M15-only EVENT with 40-bar expiry;
| |||
Engine 2 = per-TF stateless state detector (H4 N, M15 E) with no
| |||
expiry. Two event semantics for the same concept (carried from D-6).
| |||
X-7 CHoCH: legacy B REQUIRES sweep-before-CHoCH; Definition A treats them
| |||
as OR alternatives. Conflicting causal requirements.
| |||
X-8 OB/FVG: legacy B REQUIRES a zone tap for the setup; Definition A makes
| |||
the zone one leg of a same-bar conjunction; the ML path has NO zone
| |||
requirement at all (f9 needs no zone). Three different zone roles.
| |||
X-9 Displacement: Engine 2 = confirmation weight boost (never a leg);
| |||
P3-S.6 = E-agent confirmation input. Label conflict recorded.
| |||
X-10 M3: P3-S.7 = price-action vote, NOT a confirmation; this spec records
| |||
the same. No project document makes M3 a setup requirement.
| |||
```
| |||
| |||
---
| |||
| |||
## 21. SPEC DECISION SUMMARY
| |||
| |||
| # | Aspect | Decision |
| |||
|---|--------|----------|
| |||
| CS-1 | Setup definition (A) | E-agent M15 rule: ZONE(OB/FVG membership) AND CONFIRMATION(max(sweep,choch)) at the same closed bar -> fuzzy contribution to E vote |
| |||
| CS-2 | Setup definition (B, legacy) | Hard-gated chain: HTF-align -> sweep -> CHoCH(after) -> OB/FVG tap -> not-premium -> score>=threshold |
| |||
| CS-3 | Canonical for audit | Definition A (current Engine 2); B audited as legacy |
| |||
| CS-4 | Causal order (A) | SAME-BAR only; no cross-bar order enforced/defined |
| |||
| CS-5 | Causal order (B) | Ordered chain within SeqWindow=40 |
| |||
| CS-7 | Onset (A) | NOT DEFINED (SPECIFICATION AMBIGUOUS) |
| |||
| CS-8 | Onset (B) | entry-tap bar (defined) |
| |||
| CS-9 | Completion (A) | NOT DEFINED (SPECIFICATION AMBIGUOUS) |
| |||
| CS-10 | Completion (B) | gates pass + score>=threshold -> signal |
| |||
| CS-11 | Direction (A) | E-rule side = setup side; final = flat vote; arithmetic conflict resolution |
| |||
| CS-12 | Direction (B) | chain side; HTF-align gate; conflict -> no signal |
| |||
| CS-13..16 | MTF roles | H4/M30/M3 alone: NO setup (A and B); M15 alone: setup YES (A), NO (B, needs HTF gate) |
| |||
| CS-17 | Hierarchy | A: no cross-TF requirement; B: HTF gate required |
| |||
| CS-18 | Alternative paths (A) | P1-P4: {sweep|choch} x {OB|FVG}, same bar |
| |||
| CS-19 | Alternative paths (B) | one chain; zone leg OR-ed |
| |||
| CS-20 | Hard requirements (A) | zone>0 AND conf>0 (same bar); nothing else |
| |||
| CS-21 | Hard requirements (B) | HTF-align, sweep, CHoCH, OB/FVG tap, not-premium |
| |||
| CS-22 | Setup vs score | score != setup; aggregator has no setup object |
| |||
| CS-23 | Dedup | NONE in A (per-bar); no setup_id (SETUP-IDENTITY GAP) |
| |||
| CS-26 | Lifecycle (A) | NONE (SPECIFICATION AMBIGUOUS) |
| |||
| CS-27 | Lifecycle (B) | freshness window only (SeqWindow=40) |
| |||
| CS-28 | SeqWindow scope | f7 expiry (ML) + legacy gates; NOT Engine 2 |
| |||
| CS-30 | Causality | closed-bar lock; as-of <= t; future mutation cannot change past |
| |||
| CS-31 | Setup vs trade | execution semantics excluded from setup validity |
| |||
| CS-32 | State vs setup | states/events/zones alone do NOT constitute a setup; only the E-rule conjunction does (Definition A) |
| |||
| |||
---
| |||
| |||
## 22. RECORDED AMBIGUITIES
| |||
| |||
```text
| |||
A-5 Setup onset (CS-7): Definition A defines no onset timestamp.
| |||
A-6 Setup completion (CS-9): Definition A defines no completion state.
| |||
A-7 Setup lifecycle (CS-26): Definition A defines no lifecycle.
| |||
A-8 Cross-bar causal order (CS-4): Definition A defines none.
| |||
A-9 Which definition is canonical: P3-S.7 says the Engine-2 flat-vote model
| |||
IS the design; the legacy gate chain is reference. Whether the legacy
| |||
gate chain was intended to survive the refactor is NOT adjudicated.
| |||
A-10 Setup identity (CS-23): whether a setup_id is needed is not decided.
| |||
```
| |||
| |||
---
| |||
| |||
## 23. PROVENANCE & CHECKPOINT
| |||
| |||
```text
| |||
Forge HEAD (audit) : 533c8c6647a552d01a1a290cb2d0505f94887666 (P3-S.6)
| |||
P3-S.7 artifacts : intact (uncommitted; verified at session start)
| |||
Branch / remote : main == origin/main (SniperGold_ML.git)
| |||
Reconciled sources : docs/P3_S8_CANDIDATE_SETUP_CONFORMANCE.md §A
| |||
FEATURE_CONTRACT : unchanged
| |||
Human verification : CANCELLED
| |||
No production change : AF_Engine1_MTFData / AF_Engine2_Agents /
| |||
AF_Engine2_Aggregator / AF_Engine2_Display /
| |||
AF_Engine3_Render / f7-f18 / FVG / OB / CHoCH /
| |||
Displacement / ML / legacy v4.x : NOT touched
| |||
```
|