# SMC MTF ALIGNMENT — PROJECT SEMANTIC SPECIFICATION v1 ```text 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: ```text 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): ```text 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: ```text 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): ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text H4 | v M30 | v M15 | v M3 ``` Stage classification (project model): ```text 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. ```text 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): ```text 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): ```text 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): ```text 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): ```text 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): ```text 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) ```text 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) ```text 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) ```text 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) ```text 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) ```text 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) ```text 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): ```text 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) ```text 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 ```text 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 ```text 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 ```