24 KiB
24 KiB
SMC MTF ALIGNMENT — PROJECT SEMANTIC SPECIFICATION v1
Status : PROJECT SEMANTIC SPECIFICATION (not "universal SMC ground truth")
Session : P3-S.7 — MTF Alignment semantic validation
Date : 2026-08-22
Scope : The multi-timeframe analysis model of the Algo Forge / SniperGold_ML
project: H4 Narrative -> M30 Context -> M15 Entry -> M3 Price Action.
Defines what each timeframe is ALLOWED to provide, how direction
propagates, the as-of timestamp contract, the aggregation semantics,
and the conflict policy. 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)
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.6 specs (reconciled)
Human verification : CANCELLED
This document ESTABLISHES the project's MTF semantics, derived from: (a) design intent (DESIGN.md Engines 1-3), (b) the current implementation (hardcoded agent timeframes AF_E2_TF_S1..S4, the four agents, the aggregator, the Engine-1 cache), (c) the Feature Contract MTF model, and (d) logical requirements (closed-bar / as-of, no look-ahead, no implicit TF substitution). It does NOT claim that MTF creates a trading edge.
1. THE FOUR TIMEFRAME ROLES (CORE)
The project assigns one semantic role per timeframe. The roles are implemented as four independent agents, each reading EXACTLY ONE Engine-1 slot:
H4 (AF_E2_TF_S1 = PERIOD_H4) -> S1 Narrative (N) "Which way is the market?"
M30 (AF_E2_TF_S2 = PERIOD_M30) -> S2 Context (C) "Which zone is price in?"
M15 (AF_E2_TF_S3 = PERIOD_M15) -> S3 Entry (E) "Is there entry confirmation?"
M3 (AF_E2_TF_S4 = PERIOD_M3) -> S4 PriceAction(P) "When to open?"
The intended reading order is top-down: H4 -> M30 -> M15 -> M3 (the ANALYSIS hierarchy). Whether the DECISION hierarchy is equally strict is defined in §5-§8.
Layer separation (reconciled from all sources):
INTENDED MTF SEMANTICS (DESIGN.md §8-9):
H4 Narrative : trend/structure (HH/HL/LH/LL), CHoCH/MSS, BOS, liquidity sweep,
premium/discount. Question: "Which way is the market?"
M30 Context : OB, FVG, S/R, premium/discount. Question: "Which zone is price in?"
M15 Entry : sweep, CHoCH, displacement, OB/FVG zones; ZONE + CONFIRMATION = setup.
Question: "Is there entry confirmation?"
M3 PA : engulfing, pin bar, inside bar, 2-bar momentum, close-in-range.
Question: "When to open?"
Aggregation : separate aggregator, weighted vote, dynamic weights + agreement boost.
LEGACY MTF SEMANTICS (v4.3/v4.4/v4.5):
v4.5: per-TF structure on D1/H4/H1 + chart M15; bias TFBias on D1/H4/H1;
MTF OB/FVG drawn per-TF. NO M30/M3 anywhere.
v4.4/v4.3: structure on chart TF (M15) only; TFBias D1/H4/H1; optional FVG HTF
projection. NO M30/M3.
CURRENT IMPLEMENTATION (Engine 2 + Engine 1):
Agents H4/M30/M15/M3, hardcoded macros; each agent one slot; stateless;
aggregator flat weighted vote (0.30/0.30/0.25/0.15) + 1.5x majority boost.
TRAINING SEMANTICS (FEATURE_CONTRACT + Python):
M15 chart + D1/H4/H1 HTF biases (f0-f2); f3-f18 all M15. NO M30, NO M3.
DISPLAY SEMANTICS (Engine 3):
Structure/zones on the display TF (default chart = M15); D1/W1 PDH/PDL/PWH/PWL
levels; agent biases (N/C/E/P) as dashboard text. H4/M30 structures not drawn.
2. H4 — NARRATIVE (S-N)
H4 is allowed to provide:
directional narrative : trend from HH/HL/LH/LL pivot sequence + clarity
market structure : CHoCH/MSS and BOS events on H4 bars
major liquidity : H4 liquidity sweep (AF_DetectSweep on the H4 slot)
trend regime : structure-vs-zone dynamic weights (clarity)
premium/discount : H4 range position (AF_RangeStat on the H4 slot)
major OB/FVG : NOT in the Narrative composition (N uses structure/
liquidity/zone, NOT OB/FVG)
macro context : implicit — the H4 narrative is the macro layer
Answers (project model):
Can H4 directly trigger an entry? -> YES (via the aggregator vote; the unit
test T6 explicitly asserts "N buy kuat saja -> BUY"). H4 is a 0.30-weight
vote, not a gate.
Can H4 produce an Entry signal? -> YES, in the sense of a final aggregated
BUY/SELL when the other agents are neutral (see MTF-T19).
Can H4 override M15? -> NO explicit override. When H4 and M15
disagree, the aggregator resolves by weighted average + majority boost
(H4 0.30 vs M15 0.25; the aligned side also gets 1.5x). No veto exists.
Can H4 invalidate M15? -> NO. No invalidation mechanism exists.
S-N verdict basis: the Narrative role is a directional vote, NOT a gate, NOT an override, NOT an invalidation source. Any stricter semantics is NOT in the project model (recorded as SPECIFICATION AMBIGUOUS for the conflict policy, §9).
3. M30 — CONTEXT (S-C)
M30 is allowed to provide:
refines H4 narrative : implicitly through its own vote (no direct H4 read)
confirms direction : via OB/FVG/S-R/premium-discount vote sign
identifies intermediate liquidity : not a distinct concept — M30 uses S/R pivots
identifies setup zones : OB and FVG membership (trap around zone +- 0.3 ATR)
filters M15 : NO direct filter — only via the aggregator vote
creates standalone entries: YES via the aggregator vote (0.30 weight, T6 class)
Answers:
Does M30 create a trade setup without H4/M15 support? -> YES via the vote; the
Context agent alone can produce a final BUY/SELL when others are neutral.
Is M30 a filter on M15? -> NO explicit filter; only
a weighted vote in the aggregator.
4. M15 — ENTRY (S-E)
M15 is the ENTRY layer. Meaning in the project model:
candidate setup : OB/FVG zone membership (ZONE)
entry structure : sweep / CHoCH / displacement (CONFIRMATION)
signal : ZONE + CONFIRMATION = setup rule (internal to the E agent)
trigger : the E agent vote contributes to the final aggregated signal
confirmation : the E agent's role question is "Is there entry confirmation?"
Answers:
Can M15 create a trade setup without H4/M30 support? -> YES. The E agent
computes ZONE + CONFIRMATION entirely from its own M15 slot; it never reads
H4 or M30 data. A final BUY/SELL can arise from the E vote alone (MTF-T20).
Can M15 contradict H4? -> YES, and the code does
not prevent it. Contradiction is resolved by the aggregator vote, not by a
policy (see MTF-T21).
What happens when M15 disagrees with H4/M30? -> The aggregate bias is a
weighted average; the majority side receives a 1.5x boost. There is NO
BLOCK/WAIT/CONFLICT state. The final direction may be BUY, SELL, or WAIT
purely from arithmetic, regardless of the M15 opinion.
5. M3 — PRICE ACTION (S-P)
M3 contributes:
micro-structure : candle patterns on M3 bars (engulfing, pin bar, inside
bar, 2-bar momentum, close-in-range)
entry confirmation : only as a vote (0.15 weight — the smallest)
rejection : reversal patterns (pin bar / engulfing) in ranging mode
micro BOS/CHoCH : NOT used — the P agent has no structure detector
execution timing : the P agent's question is "When to open?" (timing role)
liquidity sweep : NOT used in the P agent
FVG confirmation : NOT used in the P agent
Answers:
Can M3 create a setup by itself? -> YES via the vote (0.15 weight alone still
passes the 0.20/0.50 thresholds at conf>=~0.57 — MTF-T22).
Can M3 override M15? -> NO explicit override; only a weighted vote.
Can M3 reject an M15 setup? -> NO explicit rejection. A bearish M3 vote
can only reduce the aggregate buy support arithmetically.
Is M3 mandatory for entry? -> NO. Signals can fire with M3 neutral.
6. TOP-DOWN DEPENDENCY (S-H)
Intended dependency:
H4
|
v
M30
|
v
M15
|
v
M3
Stage classification (project model):
H4 Narrative : CONTEXT ONLY + VOTE (no gate)
M30 Context : CONTEXT ONLY + VOTE (no filter, no gate)
M15 Entry : ENTRY TRIGGER INPUT + VOTE (ZONE + CONFIRMATION internal rule;
no external gate from H4/M30)
M3 PriceAct. : CONFIRMATION + VOTE (timing role; not mandatory)
Aggregator : the ONLY place where the four votes meet (flat weighted vote)
The top-down order is an ANALYSIS/READING order (DESIGN.md §8 "analysis basis: H4 -> M30 -> M15 -> M3 top-down to the chart"). It is NOT a decision gate chain. This is a central finding: the DECISION model is a flat vote of four independent role-labeled agents; the DECISION hierarchy is not implemented.
REQUIRED : none of the four TFs is REQUIRED for a signal (any single agent
can produce a final direction).
OPTIONAL : all four (each contributes a vote; missing/insufficient data ->
agent neutral, vote weight 0).
FILTER : none of the four acts as a filter on another.
CONTEXT ONLY : H4 (Narrative), M30 (Context).
CONFIRMATION : M15 (Entry, internal ZONE+CONF rule), M3 (Price Action).
ENTRY TRIGGER: the aggregated final signal (AF_AGG_BUY_TH / AF_AGG_MIN_SUP).
7. DIRECTION PROPAGATION (S-D)
Direction propagation is defined as the aggregator arithmetic (spec formula):
pass 1: bias1 = SUM(baseW[i]*conf[i]*bias[i]) / SUM(baseW[i]*conf[i])
baseW = [N=0.30, C=0.30, E=0.25, P=0.15]
majDir = +1 if bias1 > 0.05, -1 if bias1 < -0.05, else 0
pass 2: effective weight w2[i] = baseW[i]*conf[i]*(1.5 if dir[i]==majDir else 1.0)
buy = SUM(w2[i]*buy[i])/SUM(w2[i]); sell analogously
bias = buy - sell; score = |bias|
final : dir = +1 if bias >= 0.20 AND buy >= 0.50
-1 if bias <= -0.20 AND sell >= 0.50
0 otherwise (WAIT)
Worked cases (spec truth; used in MTF-T01..T04/T19..T22):
H4=+1, M30=+1, M15=+1, M3=+1 (strong, conf 0.9) -> BUY (bias ~0.8+)
H4=+1, M30=-1 (strong, conf 0.9), others neutral -> BUY (H4 wins 0.30 vs 0.30
tie broken by the 1.5x majority boost on the pass-1 majority side; pass-1
bias = (0.3*0.9*0.8 - 0.3*0.9*0.8)/0.54 = 0.0 -> majDir=0 -> NO boost ->
bias = 0.0 -> WAIT. Exact tie => WAIT; any imbalance => majority boosted.)
H4=+1, M30=+1, M15=-1, M3=-1 (strong, conf 0.9) -> pass-1 bias =
(0.3*0.9*0.8 + 0.3*0.9*0.8 - 0.25*0.9*0.8 - 0.15*0.9*0.8)/0.9 =
(0.216+0.216-0.18-0.108)/0.9 = 0.144/0.9 = 0.16 -> majDir=+1 -> boost
N,C -> buy=(0.405*0.9+0.405*0.9+0.225*0.1+0.135*0.1)/1.17 =
(0.3645+0.3645+0.0225+0.0135)/1.17 = 0.765/1.17 = 0.654; sell analogous
0.346 -> bias 0.308 -> BUY. (H4+M30 dominate M15+M3 by weight+boost.)
Contradiction handling is arithmetic, not policy (see §9).
8. AS-OF TIMESTAMP CONTRACT (S-T) — MANDATORY
For a decision at M15 timestamp t (decision bar = newest CLOSED M15 bar):
H4_asof(t) : the newest CLOSED H4 bar with close_time <= t
M30_asof(t) : the newest CLOSED M30 bar with close_time <= t
M15_asof(t) : the newest CLOSED M15 bar with close_time <= t (= the decision bar)
M3_asof(t) : the newest CLOSED M3 bar with close_time <= t
Invariants (each must hold for every decision):
H4_close_time <= t
M30_close_time <= t
M15_close_time <= t
M3_close_time <= t
Mechanism: Engine 1 (AFEngine1MTF) closed-bar lock — cache holds ONLY closed
bars (IsBarClosed(barTime, tf, now): barTime + PeriodSeconds(tf) <= now; the
forming bar is dropped at Build). Refresh() re-reads a slot ONLY when
Bars(symbol, tf) changes. Therefore the cache at decision time t is exactly
the newest closed bars as of t for every registered TF. No partial/future HTF
candle can leak into an LTF decision (MTF-T10). This contract is enforced by
the cache, not by an explicit asof() function — the as-of correctness is
implicit but verifiable (MTF-T07/T08/T16).
Visibility rule for HTF closes (deterministic):
A new H4 bar (closed at 04:00) becomes visible to all consumers at the first
decision time t >= 04:00 (i.e., at the first M15 bar close at/after 04:00; on
a strict 15-min grid: 04:00). Before 04:00 (e.g., 03:59 or 03:45 on the M15
grid) the H4_asof is the PREVIOUS closed H4 bar. The transition is exact and
deterministic (MTF-T07).
9. CONFLICT POLICY (S-X)
Defined policy: NONE.
The project does not define BLOCK / WAIT / LOWER-TF-OVERRIDES /
HIGHER-TF-OVERRIDES / CONFLICT-STATE semantics. DESIGN.md describes the
aggregator as a weighted vote; no conflict branch exists in the code.
Actual behavior: arithmetic resolution via the weighted vote (pass 1 majority,
pass 2 boost). A contradiction is not flagged, not blocked, not waited out;
it simply lowers the aggregate bias.
Status: SPECIFICATION AMBIGUOUS for the conflict policy (the spec has no
policy; the code has no policy; they agree by absence).
10. AGGREGATION SEMANTICS (S-A)
The four timeframes are aggregated as SAME-LEVEL VOTES (weighted vote with
agreement boost), NOT as a hierarchical gate chain.
- base weights: N 0.30, C 0.30, E 0.25, P 0.15 (AF_AGG_W_*)
- pass 1 majority, pass 2 1.5x boost for agents aligned with the majority
- final direction: bias >= 0.20 (AF_AGG_BUY_TH) and support >= 0.50
(AF_AGG_MIN_SUP)
- the Entry levels (entry/SL/TP) are computed on the M15 slot (slotE) only —
the only place where M15 has a special role in the DECISION output.
If the intended model were a strict H4->M30->M15->M3 gate chain, the current
implementation would be classified as HIERARCHICAL-TO-VOTING DRIFT. Per the
project's own design documents, the model IS a vote; the drift label is
recorded as the difference between the session brief's strict-hierarchy
reading and the actual design (see conformance report §D-10).
11. CROSS-TIMEFRAME EVENT RELATIONSHIP (S-R)
Formal rule: NO lower-timeframe event may reference a higher-timeframe
structure. Each agent reads exactly ONE slot. There is no code path where an
M15 event consumes H4 liquidity, where M3 confirmation consumes M15 FVG, etc.
Examples that DO NOT exist in the project model:
M15 sweep of M30 liquidity : not implemented (no M30 read in E)
M15 CHoCH after H4 liquidity event: not implemented (no H4 read in E)
M3 confirmation inside M15 FVG : not implemented (no M15 read in P)
M3 entry into M15 OB : not implemented
Confluence is created ONLY at the aggregator (vote-level), never at the
structure level. This is the fundamental property that makes the model
"role-labeled per-TF votes" rather than "genuine multi-timeframe structural
analysis". Recorded as MTF ROLE DIVERGENCE: the roles differ by agent
composition and question, but the detectors are the same per-TF algorithms and
no structural cross-TF relationship exists.
12. NO IMPLICIT TIMEFRAME SUBSTITUTION (S-I)
Every agent slot has an explicit timeframe contract:
S1 = H4, S2 = M30, S3 = M15, S4 = M3 (AF_E2_TF_S1..S4, hardcoded).
All consumers (indicator AF_Engine3_Display, unit tests) register from the
same macros. There is no code path that substitutes M15->H1, M15->H4, or
M3->M15 for cache convenience.
Known seams (documented, not defects of the agent path):
* The ML/Feature-Contract path uses D1/H4/H1 HTF + M15 — a DIFFERENT MTF
model (see §14). This is not a substitution inside the agent path, but the
project as a whole hosts two MTF models.
* The display shows D1/W1 levels (PDH/PDL/PWH/PWL) — display-only TFs that
are NOT agent TFs (see §13).
* Runtime TF-identity is by convention: Register(tf) is idempotent per
(symbol, tf), and consumers pass slot indexes; nothing re-checks the TF at
consume time. A wrong TF injected into a slot would be silently consumed
(MTF-T11 — UNVERIFIABLE at runtime by design).
13. DISPLAY VS DECISION SEMANTICS (S-V)
Display (Engine 3) shows:
- structure (BOS/CHoCH), OB, FVG, premium/discount, EQH/EQL sweep on the
DISPLAY slot (default chart = M15)
- D1/W1 levels (PDH/PDL/PWH/PWL) from Engine-1 D1/W1 slots
- agent biases (N/C/E/P) as dashboard text with reason strings
- final aggregated signal + entry/SL/TP (computed on the M15 slot)
Decision (Engine 2) uses:
- H4/M30/M15/M3 agent votes (all four)
- M15 slot for entry/SL/TP levels
Inconsistencies (documented, NOT repaired):
V-1 Display shows D1/W1 levels that the decision engine does not use.
V-2 Display does NOT render H4 structure or M30 zones (the two top agent
TFs) — the dashboard shows only their biases.
V-3 The only structural MTF the display draws is the display TF (M15),
which coincides with the E agent TF by default, not by contract.
V-4 The display's non-repaint gate (new closed display bar) is independent
of the agent recompute cycle; within an M15 bar, agent outputs are
frozen on screen as expected (no stale re-render).
14. TRAINING / RUNTIME MTF PARITY (S-PR)
ML path (parity-verified in SB-06):
Runtime : EA AlgoForge_Backtest_Baseline (M15 + D1/H4/H1, E_ea as-of)
Training: train_model.build_features (M15 + D1/H4/H1, E_ea as-of)
Status : timestamp parity 14850/14850; per-feature parity verified after the
windowed fix; residual f18 B-formula differences documented.
-> ML path MTF semantics: M15 + D1/H4/H1. CONFORMING (parity-verified).
Agent path (Engine 2, H4/M30/M15/M3):
Runtime : AF_Engine2_Agents + Aggregator (H4/M30/M15/M3)
Training: NONE — the H4/M30/M15/M3 agent model has NO Python counterpart,
NO Feature Contract entry, NO training feature, NO parity target.
Status : PARITY = N/A BY ABSENCE (same class as displacement P3-S.6 S-14).
Contract mismatch (recorded as FEATURE_CONTRACT MTF MISMATCH):
FEATURE_CONTRACT HTF set = D1/H4/H1 (f0-f2) + M15 (f3-f18)
Engine 2 agent TF set = H4/M30/M15/M3
The two MTF models coexist; nothing in the repository reconciles them. The
"intended" H4/M30/M15/M3 hierarchy is NOT the trained/parity-verified model.
15. CROSS-CONCEPT TIMEFRAME CONSISTENCY (S-XC)
Reconciled canonical/role matrix (from P3-S.2..S.6 + this audit):
| Concept | Contract/ML canonical | Engine 2 agent use | Legacy v4.5 | H4 role | M30 role | M15 role | M3 role |
|---|---|---|---|---|---|---|---|
| Liquidity Sweep | M15 ONLY (f7) | per-TF (N,E); display M15 | per-TF D1/H4/H1 | N input | not in C | E input | not in P |
| CHoCH/MSS | M15 ONLY (f8/f9) | per-TF (N,E); display M15 | per-TF D1/H4/H1 | N input | not in C | E input | not in P |
| FVG | NOT in contract | per-TF (C lookback 40, E 20); display M15 | chart + D1/H4/H1 | not in N | C zone | E zone | not in P |
| OB | NOT in contract | per-TF (C,E); display M15 | chart + D1/H4/H1 | not in N | C zone | E zone | not in P |
| Displacement | NOT in contract | M15-only consumer (E); per-slot function | none | not in N | not in C | E confirmation | not in P |
Contradictions (documented, NOT resolved this session):
X-1 f7 sweep is M15-only (contract) while AF_DetectSweep runs per-TF in
Engine 2 (N on H4, E on M15, display on M15) — same detector, two
canonical scopes without an explicit reconciliation rule.
X-2 CHoCH is "M15 only" for f8/f9 (contract) while AF_DetectChoch runs per-TF
in Engine 2 and AF_BuildStructLines runs on the display TF — three
implementations with different TFs (already documented P3-S.3).
X-3 FVG/OB exist as multiple per-TF implementations (Engine 2 C/E, display,
legacy v4.5 MTF D1/H4/H1, legacy chart) with no single canonical TF.
X-4 Displacement is per-TF as a function but consumed ONLY on M15 (E) —
canonical timeframe AMBIGUOUS (P3-S.6 A-1).
X-5 The three layers (contract D1/H4/H1/M15, Engine 2 H4/M30/M15/M3, legacy
D1/H4/H1+M15) use DIFFERENT timeframe sets for the SAME concepts.
16. STALE-STATE AUDIT RESULT (S-ST)
Agent path: all four agents are stateless (pure functions of closed Engine-1
bars). There is no HTF event state that an LTF consumer could hold stale —
there is no cross-TF consumption at all. The f7/CHoCH/FVG/OB stale-consumer
bug class of the ML path (P3-S.0/P3-S.3) does NOT apply to the Engine-2 agent
path by construction (each agent recomputes from closed bars every bar).
ML path: the documented stale states (f9/f18 persistent choch without expiry,
f7 lifecycle fix applied) are M15-internal and out of the MTF hierarchy scope.
Conclusion: NO stale-HTf-state bug exists in the agent MTF path (MTF-T06
trivially conforms: an H4 event cannot be consumed after expiry because no
H4 event is ever consumed by an LTF agent).
17. SPEC DECISION SUMMARY (tabular)
| # | Aspect | Decision |
|---|---|---|
| S-N | H4 role | Narrative directional VOTE (0.30); CAN trigger entry alone; NO gate/override/invalidate |
| S-C | M30 role | Context zone VOTE (0.30); can trigger alone; NO filter on M15 |
| S-E | M15 role | Entry VOTE (0.25) with internal ZONE + CONFIRMATION rule; can trigger alone; contradiction NOT blocked |
| S-P | M3 role | Price Action VOTE (0.15); timing role; NOT mandatory; cannot override/reject explicitly |
| S-H | Hierarchy | Top-down ANALYSIS order only; DECISION = flat vote; no REQUIRED stage |
| S-D | Direction | Aggregator 2-pass weighted vote; majority boost 1.5x; thresholds 0.20/0.50 |
| S-X | Conflict | NO policy defined; arithmetic resolution (SPECIFICATION AMBIGUOUS) |
| S-T | As-of | Closed-bar lock per slot; H4/M30/M15/M3_asof(t) all <= t; deterministic HTF-close visibility |
| S-A | Aggregation | SAME-LEVEL VOTES; hierarchical gate NOT implemented (HIERARCHICAL-TO-VOTING DRIFT if strict hierarchy was intended) |
| S-R | Cross-TF refs | NONE — no LTF event references HTF structure; confluence only at vote level |
| S-I | TF substitution | Explicit TF contract per slot via macros; runtime TF-identity by convention (unverifiable) |
| S-V | Display | M15 structure + D1/W1 levels + agent biases; H4/M30 structure not drawn (V-1..V-4) |
| S-PR | Parity | ML path (D1/H4/H1/M15) parity-verified; agent path (H4/M30/M15/M3) N/A by absence; FEATURE_CONTRACT MTF MISMATCH |
| S-XC | Cross-concept | 5 concepts, 3 MTF models, no unified canonical TF (X-1..X-5) |
| S-ST | Stale state | Agent path stateless; no stale HTF consumption by construction |
18. RECORDED AMBIGUITIES
A-1 Conflict policy (S-X): the project defines no BLOCK/WAIT/OVERRIDE policy;
the aggregator resolves contradictions arithmetically. Whether this is
intended or a gap is NOT adjudicated.
A-2 Strict-hierarchy intent: the session brief posits "H4 Narrative -> M30
Context -> M15 Entry -> M3 Price Action" as a decision chain; DESIGN.md
describes a flat vote. The gap between the two readings is recorded as
HIERARCHICAL-TO-VOTING DRIFT (S-A), not resolved.
A-3 Canonical timeframe per concept (S-XC X-1..X-5): the project hosts three
MTF models; a single canonical timeframe per concept is not defined.
A-4 Runtime TF-identity enforcement (S-I): slot->TF mapping is by convention.
19. PROVENANCE & CHECKPOINT
Forge HEAD (audit) : 533c8c6647a552d01a1a290cb2d0505f94887666 (P3-S.6)
Branch / remote : main == origin/main (clean)
P3-S.6 artifacts : intact (verified at session start)
Reconciled sources : see docs/P3_S7_MTF_ALIGNMENT_CONFORMANCE.md §A
FEATURE_CONTRACT : unchanged (not modified by this session)
Human verification : CANCELLED
No production change : AF_Engine1_MTFData / AF_Engine2_Agents / Aggregator /
Display / AF_Engine3_Render / f7-f18 / FVG / OB /
CHoCH / Displacement / ML : NOT touched