31 KiB
31 KiB
SMC CANDIDATE SETUP — PROJECT SEMANTIC SPECIFICATION v1
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):
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):
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)
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:
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)
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)
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)
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:
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)
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
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
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
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
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
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
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)
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
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
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
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
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
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
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):
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 |
| 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
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
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