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
|
||
|
|
```
|