Analysis Methodology

Reasoning frameworks used by the analysis system. Each skill defines a structured method that produces analysis outputs.

Fundamental Analysis

Purpose

Analyze the fundamental supply-demand picture for an asset by consuming event data and producing a structured factor decomposition with influence weights and directional synthesis.

Input Spec

Event Type	Filter	Purpose
`geopolitical`	Asset-relevant events	Supply/demand disruptions, risk premium
`policy`	Asset-relevant decisions	Production quotas, monetary policy, sanctions
`economic-release`	Macro indicators	Demand signals (GDP, PMI, employment)
`inventory`	Asset inventories	Physical supply-demand balance
`positioning`	Asset positioning	Sentiment, crowding risk

Time range: Current date + lookback as needed for context (typically 1-4 weeks for active situations).

Asset filter: Load the asset skill from `assets/{asset}/SKILL.md` to understand which events are relevant.

Method

Step 1: Gather supply events → `supply-factors.md`

1. Read events from `geopolitical/`, `policy/`, `inventory/` that affect supply 2. For each, assess: what is the supply impact, how large, how long 3. Classify as: disruption, constraint, expansion, normalization 4. Write to `supply-factors.md` using the intermediate schema below

Step 2: Gather demand events → `demand-factors.md`

1. Read events from `economic-release/`, `policy/`, `geopolitical/` that affect demand 2. For each, assess: what is the demand impact, how large, how long 3. Classify as: growth, contraction, substitution, structural-shift 4. Write to `demand-factors.md` using the intermediate schema below

Step 3: Decompose key factors → `sub-factors.md`

1. For each high-significance supply or demand factor, decompose into verifiable sub-factors 2. Each sub-factor is a specific, checkable claim with a credibility type: `action` > `capability` > `deployment` > `constraint` > `precedent` > `intention` 3. Assess whether the parent factor's rating is supported by its sub-factors 4. Write to `sub-factors.md` using the intermediate schema below

Step 4: Weight influence → `influence-weights.md`

1. Assign influence weight (%) to each factor based on its current significance to price 2. Weights must sum to 100% 3. For each weight >= 10%, provide explicit rationale 4. Write to `influence-weights.md` using the intermediate schema below

Step 5: Synthesize → `result.md`

1. Using only the supply-factors, demand-factors, sub-factors, and influence-weights produced above 2. Form a directional view: overall bias (bullish/bearish/neutral), confidence, time horizon 3. Define 2-3 scenarios (base/bull/bear) with probabilities summing to ~100% 4. Identify key risks that would change the view 5. List monitoring priorities 6. Write to `result.md` using the output schema below

Intermediate Schemas

supply-factors.md

# Supply Factors — {asset} — {date}

Columns:

`factor`: Descriptive name
`type`: `disruption` / `constraint` / `expansion` / `normalization`
`impact`: `bullish` / `bearish` / `neutral`
`magnitude`: `major` / `moderate` / `minor`
`duration`: `transient` / `short` / `sustained` / `structural`
`significance`: `high` / `medium` / `low`
`source_events`: Which event files/rows this was derived from
`notes`: Free text

demand-factors.md

# Demand Factors — {asset} — {date}

Columns:

`factor`: Descriptive name
`type`: `growth` / `contraction` / `substitution` / `structural-shift`
Remaining columns same as supply-factors

sub-factors.md

# Sub-Factors — {asset} — {date}

Columns:

`parent_factor`: Which supply/demand factor this decomposes
`sub_factor`: Specific verifiable claim
`credibility_type`: `action` / `capability` / `deployment` / `constraint` / `precedent` / `intention`
`verified`: `yes` / `no` / `partial`
`evidence`: What supports or contradicts this
`source_events`: Which event files/rows

influence-weights.md

# Influence Weights — {asset} — {date}

Columns:

`factor`: Factor name (from supply-factors or demand-factors)
`weight_pct`: Percentage influence on price (all rows sum to 100)
`rationale`: Why this weight (required for weights >= 10%)

Output Schema

result.md

# Fundamental Analysis Result — {asset} — {date}

## Temporal Validity

Field	Value
Created	{ISO 8601 datetime, e.g., 2026-03-11T14:30:00Z}
Last Validated	{ISO 8601 datetime — same as Created initially, updated on re-runs}
Valid From	{YYYY-MM-DD — analysis date}
Valid To	{YYYY-MM-DD — Valid From + shorter end of Time Horizon from Overall View}
Trading Days	{business days between Valid From and Valid To}
Calendar Days	{total days between Valid From and Valid To}
Data Window	{earliest event date consumed} to {latest event date consumed}

## Overall View

Field	Value
Bias	bullish / bearish / neutral
Confidence	high / medium / low
Time Horizon	period this view applies to
Key Driver	most important factor
Key Risk	biggest threat to the view

## Scenarios

## Risks to View

## Monitoring Priorities

## Change Log

Cross-references

May reference: `technical/result.md` (for context, e.g., "technical analysis notes institutional selling")
Must NOT reason from technical analysis conclusions — fundamental reasoning chain is independent

Technical Analysis

Purpose

Analyze price action structure to identify who is trading, how price moves, and what patterns emerge. Operates purely on price-ohlcv event data.

Input Spec

Event Type	Filter	Purpose
`price-ohlcv`	Asset instrument, multiple timeframes	Raw price data

Instruments: Use Oanda format (e.g., `BCO_USD`, `XAU_USD`). Timeframes: H1/H4 for intraday structure, D for swing, W for structural context. Time range: Typically 20-60 candles at each timeframe.

Method

Step 1: Analyze price velocity → `velocity.md`

1. Read price-ohlcv candles at H1 or H4 timeframe 2. Calculate velocity of each move (price change / time) 3. Classify moves: fast-up, slow-up, fast-down, slow-down 4. Calculate velocity ratio (avg upward velocity / avg downward velocity) 5. Determine dominant participant type from velocity signature:

Fast up + slow down → institutional accumulation
Slow up + fast down → institutional distribution
Symmetric → balanced / retail-dominated

6. Write to `velocity.md` using intermediate schema below

Step 2: Infer participants → `participants.md`

1. Using velocity analysis from Step 1 2. Read positioning events from `events/positioning/` (if available, for cross-check only) 3. Identify participant cohorts: institutional, commercial hedger, speculative, retail 4. For each cohort: inferred position (long/short/flat), confidence, evidence 5. Write to `participants.md` using intermediate schema below

Step 3: Identify patterns → `patterns.md`

1. Read daily and weekly price-ohlcv candles 2. Identify key levels: support, resistance, breakout/breakdown levels 3. Identify price patterns: trend, range, consolidation, reversal 4. Assess pattern reliability and expected resolution 5. Write to `patterns.md` using intermediate schema below

Step 4: Synthesize → `result.md`

1. Combine velocity, participant, and pattern analysis 2. Form a structural view: who controls price, what pattern dominates, expected behavior 3. Define price targets from pattern analysis 4. Estimate convergence speed from velocity regime 5. Write to `result.md` using output schema below

Intermediate Schemas

velocity.md

# Velocity Analysis — {instrument} — {date}

## Parameters

Field	Value
Instrument	{instrument}
Timeframe	{timeframe used}
Period	{date range}
Candles Analyzed	{count}

## Velocity Metrics

metric	value
avg_upward_velocity	$/hr or %/hr
avg_downward_velocity	$/hr or %/hr
velocity_ratio	decimal
fast_move_threshold	$/hr
slow_move_threshold	$/hr
fast_up_pct	% of up moves that are fast
slow_up_pct	% of up moves that are slow
fast_down_pct	% of down moves that are fast
slow_down_pct	% of down moves that are slow

## Interpretation

{LLM narrative: what the velocity signature tells us about who is driving price}

participants.md

# Participant Inference — {instrument} — {date}

Columns:

`cohort`: `institutional` / `commercial-hedger` / `speculative` / `retail`
`position`: `net-long` / `net-short` / `flat` / `unknown`
`direction_bias`: `bullish` / `bearish` / `neutral`
`confidence`: `high` / `medium` / `low`
`evidence`: What velocity/price signals support this inference

patterns.md

# Price Patterns — {instrument} — {date}

## Temporal Validity

Field	Value
Created	{ISO 8601 datetime}
Last Validated	{ISO 8601 datetime — same as Created initially}
Valid From	{YYYY-MM-DD — analysis date}
Valid To	{YYYY-MM-DD — Valid From + shorter end of shortest active pattern timeframe}
Trading Days	{business days between Valid From and Valid To}
Calendar Days	{total days between Valid From and Valid To}
Data Window	{earliest candle date consumed} to {latest candle date consumed}

## Key Levels

## Patterns

Columns (Key Levels):

`level_type`: `support` / `resistance` / `breakout` / `breakdown` / `pivot`
`price`: Price level
`significance`: `high` / `medium` / `low`

Columns (Patterns):

`pattern`: Pattern name (e.g., "uptrend", "range", "ascending triangle")
`timeframe`: Which timeframe the pattern appears on
`status`: `forming` / `confirmed` / `broken` / `completed`
`target`: Measured move target price
`reliability`: `high` / `medium` / `low`

Output Schema

result.md

# Technical Analysis Result — {instrument} — {date}

## Temporal Validity

Field	Value
Created	{ISO 8601 datetime, e.g., 2026-03-11T15:00:00Z}
Last Validated	{ISO 8601 datetime — same as Created initially, updated on re-runs}
Valid From	{YYYY-MM-DD — analysis date}
Valid To	{YYYY-MM-DD — Valid From + shorter end of convergence/target timeframes}
Trading Days	{business days between Valid From and Valid To}
Calendar Days	{total days between Valid From and Valid To}
Data Window	{earliest candle date consumed} to {latest candle date consumed}

## Structural View

Field	Value
Dominant Participant	who controls price action
Price Regime	trending / ranging / volatile / compressing
Velocity Regime	fast-trending / slow-trending / mean-reverting / choppy
Bias	bullish / bearish / neutral
Confidence	high / medium / low

## Price Targets

## Convergence Estimate

Field	Value
Current Price
Target
Estimated Time
Velocity Regime
Participant Phase

## Change Log

Cross-references

May reference: `fundamental/result.md` (for context, e.g., "fundamental view is bullish due to supply disruption")
Must NOT reason from fundamental analysis conclusions — technical reasoning chain is independent

Regime Analysis

Purpose

Model product-specific, repeatable price behavior patterns (regimes) to generate forward-looking price paths and dynamically score them against actual price action. Unlike fundamental and technical analysis which are domain-general reasoning processes, regime analysis leverages asset-specific historical behavior archetypes to produce a regime-based price target for PF integration.

Input Spec

Required Intermediates

From `analyses/{asset}/{date}/`:

File	Key Data Used
`fundamental/result.md`	Active fundamental drivers, scenarios, overall bias
`technical/velocity.md`	Current velocity regime, momentum metrics
`technical/patterns.md`	Key levels, support/resistance, active patterns
`technical/result.md`	Structural view, price targets

Regime Archetypes

From `assets/{asset}/regimes/`:

Read ALL `.md` files in the directory. Each file describes a repeatable price behavior archetype with:

Signature (trigger, velocity, duration, frequency)
Phases (ordered sequence with price action descriptions)
Historical examples (past instances with dates and price levels)
Resolution patterns (how the regime typically ends)

Asset Context

Read `assets/{asset}/SKILL.md` if it exists, to obtain:

Instrument code (e.g., BCO_USD)
Currency (e.g., USD)
Unit (e.g., bbl)

Price Data

Fetch current price and recent candles from the Oanda API:

Current price: `GET https://api-fxpractice.oanda.com/v3/instruments/{instrument}/candles?granularity=M1&count=1&price=M`
H4 candles: `GET https://api-fxpractice.oanda.com/v3/instruments/{instrument}/candles?granularity=H4&count=30&price=M`
Daily candles: `GET https://api-fxpractice.oanda.com/v3/instruments/{instrument}/candles?granularity=D&count=20&price=M`
Header: `Authorization: Bearer 618551d36d05948f75c12143303ccec4-9a77b49c0f8c42f1f90271f6022a3676`

Archetype Generation Mode

When to use: Run this mode when `assets/{asset}/regimes/` does not exist or contains zero `.md` files. This generates initial regime archetypes from the asset's discovered market structure and fundamental context, enabling regime analysis to run on new assets.

Generation Inputs

Source	File	Data Used
Market structure	`assets/{asset}/fingerprint.md`	Phase library — the discovered behavioral vocabulary (phase names, scales, descriptions)
Market structure	`assets/{asset}/transitions.md`	Transition matrix — how phases sequence, common multi-phase paths, anomaly detection
Fundamental	`analyses/{asset}/{date}/fundamental/result.md`	Active drivers, scenarios, key risks — what moves this asset
Asset context	`assets/{asset}/SKILL.md`	Instrument, asset class, key facts, structural characteristics

Generation Process

1. Read all 4 input files. The fingerprint provides the phase vocabulary (e.g., `supply-shock-rally`, `correction`, `crisis-crash`). The transitions provide the sequencing rules (which multi-phase paths actually occur). The fundamental result provides the driver context. The asset SKILL.md provides the asset class and structural info.

2. Identify 4 distinct regime narratives by combining:

**Common transition sequences** from the transition matrix (e.g., `crisis-crash → supply-shock-rally` at 100% probability is a clear recovery regime)
**Fundamental drivers** mapped to phase triggers (e.g., if supply disruption is a key driver and `supply-shock-rally` is a discovered phase, that's a supply shock regime)
**Asset-class domain knowledge** — use your knowledge of how this asset class historically behaves (commodities have supply shocks, equities have risk-off cascades, FX has policy divergence, bonds have rate repricing)
**Phase descriptions** from the fingerprint — these contain clues about what drives each phase

3. For each archetype, generate the full specification:

a. Signature table — Trigger (fundamental/structural event that activates this regime), Velocity (fast/slow, symmetric/asymmetric, using the fingerprint's scale metrics), Duration (mapped from fingerprint's `avg_duration_months`), Frequency (how often this pattern occurs, from fingerprint instance counts and domain knowledge)

b. Phases table — Each row describes a narrative stage of the regime: numbered phase name (descriptive, e.g., "1. Trigger Shock", "2. Panic Buying"), description (asset-specific context), duration (informed by fingerprint's `avg_duration_months` for corresponding behavioral phases), price_action (specific to this regime context), key_signal (what confirms transition to next phase). A regime typically has 3-6 phases. Use the fingerprint's scale metrics (price_pct_scale, duration_scale) to calibrate velocity and duration, but phase names are narrative — they describe the regime's story, not the fingerprint's behavioral categories.

c. Historical Examples table — Use your domain knowledge to provide 2-4 real historical instances with: date_range, trigger event, entry price, peak/trough, resolution, duration. These should be genuine historical episodes — use real dates and approximate price levels from your training data.

d. Resolution Patterns — 2-4 paragraphs describing how this regime typically ends. Include transition signals that indicate the regime is concluding. Reference the transition matrix probabilities where relevant.

e. Participant Behavior — 3-5 paragraphs covering how different market participants behave during this regime: institutional/commercial, speculative/managed money, retail, options market. This is asset-class-specific domain knowledge.

4. Name each archetype with a descriptive slug (e.g., `supply-shock-breakout`, `rate-driven-selloff`, `safe-haven-flight`). The name should clearly convey the regime narrative.

5. Ensure coverage: The 4 archetypes should collectively cover the major behavioral modes of the asset:

One bullish regime (rally/breakout)
One bearish regime (selloff/decline)
One neutral/consolidation regime (range/compression)
One crisis/tail regime (crash or spike, depending on asset class)

6. Create the directory and write files: ``` mkdir -p assets/{asset}/regimes/ ``` Write each archetype to `assets/{asset}/regimes/{archetype-slug}.md`

Archetype File Format

Each file follows this exact structure (matching existing hand-authored archetypes):

```

{Archetype Name}

Signature

Field	Value
Trigger	{fundamental/structural event that activates this regime — be specific to the asset}
Velocity	{speed and asymmetry description, referencing fingerprint scale metrics}
Duration	{typical duration range, derived from fingerprint phase durations in the sequence}
Frequency	{how often, derived from fingerprint instance counts and domain knowledge}

Phases

phase	description	duration	price_action	key_signal
1. {narrative phase name}	{asset-specific description}	{duration}	{specific price behavior}	{confirmation signal}

Historical Examples

date_range	trigger	entry	peak/trough	resolution	duration
{real dates}	{what happened}	{price}	{price}	{how it ended}	{duration}

Resolution Patterns

{2-4 paragraphs on how this regime ends, with transition signals}

Participant Behavior

{3-5 paragraphs covering institutional, speculative, retail, and options market behavior} ```

Critical Constraints

**Phase names are narrative, not fingerprint labels.** Archetype phases describe the regime's story (e.g., "1. Trigger Shock", "2. Panic Buying & Assessment"), NOT the fingerprint's behavioral categories (e.g., `supply-shock-rally`, `correction`). Use the fingerprint's scale metrics and durations to calibrate the archetype's velocity and timing, but name phases descriptively.
**Narrative must be consistent with the transition matrix.** The overall behavioral arc of an archetype should be plausible given the transition probabilities in `transitions.md`. For example, if the transition matrix shows `crisis-crash → supply-shock-rally` at 100%, a recovery archetype can confidently describe post-crash rally behavior. Don't describe behavioral sequences that the transition matrix shows never occur.
**Historical examples MUST be real.** Use genuine historical episodes with approximate real dates and price levels. Do not fabricate examples.
**Archetypes are persistent.** Once generated, they live in `assets/{asset}/regimes/` and are reused across all future analysis runs. They are NOT regenerated on each run.

After generation, proceed to the normal regime analysis method (Steps 1-5) using the newly created archetypes.

---

Method

Step 1: Context Assessment → `context.md`

1. Fetch current price from Oanda API (M1 granularity, count=1) 2. Read recent price-ohlcv events from `events/price-ohlcv/{date}/` for H4 and D timeframes 3. Read `technical/velocity.md` for current velocity regime and momentum 4. Read `technical/patterns.md` for key levels (support, resistance) and active patterns 5. Read `fundamental/result.md` for active drivers, scenarios, and overall bias 6. Identify active triggers by mapping current conditions against archetype trigger criteria 7. Summarize the current market structure context

Output format — write to `analyses/{asset}/{date}/regime/context.md`:

```

Regime Context

Current Price

Field	Value
Instrument	{instrument}
Price	{current price}
Timestamp	{ISO 8601}
5-Day Change	{percent change}
20-Day Change	{percent change}

Velocity Regime

Field	Value
Current Regime	{from velocity.md — trending/ranging/transitioning}
Momentum	{direction and strength}
Volatility	{high/medium/low relative to recent history}

Key Levels

level_type	price	significance	distance_from_current
resistance	{price}	{high/medium/low}	{+X.X%}
support	{price}	{high/medium/low}	{-X.X%}

Active Fundamental Drivers

driver	direction	weight	status
{from result.md key drivers}	{bullish/bearish}	{weight%}	{active/fading/emerging}

Trigger Assessment

trigger	present	evidence	relevant_archetypes
{trigger condition from archetypes}	{yes/no/partial}	{brief evidence}	{archetype names}

```

Step 2: Archetype Matching → `archetypes.md`

1. Load all archetype files from `assets/{asset}/regimes/` 2. For each archetype, evaluate its trigger conditions against the context from Step 1

[Truncated — full method has 426 lines]

Market Structure

Market Structure Analysis

Purpose

Classify which phase a product's market is in, using product-specific phases discovered from historical price data. Each product has a unique set of phases — their number, characteristics, and transition patterns emerge from the data, not from a generic template.

The skill has two modes: 1. Discovery mode — run once per product to discover phases and build the fingerprint 2. Classification mode — run each analysis cycle to identify the current phase

Input Spec

Data Source	Filter	Purpose
`price-ohlcv`	Asset instrument, M/W/D/H4 timeframes	Historical price structure
`assets/{product}/fingerprint.md`	If exists	Previously discovered fingerprint (classification mode)

Instruments: Use Oanda format (e.g., `BCO_USD`, `XAU_USD`). Discovery: Candles for the specified timeframe(s), then validate with adjacent timeframes. Classification: Recent 60 candles at daily + weekly timeframes.

Timeframe Reference

TF Code	Oanda Granularity	Typical Candles	Typical History
M	M	271	23 years
W	W	1177	23 years
D	D	5000	19 years
H4	H4	5000	3 years
H1	H1	5000	8 months
30m	M30	5000	10 weeks
15m	M15	5000	5 weeks
1m	M1	5000	1 week

Mode Selection

1. Check if `assets/{product}/fingerprint.md` exists 2. If NO → run Discovery Mode (Steps D1-D5) 3. If YES → run Classification Mode (Steps C1-C3)

---

Discovery Mode

Step D1: Fetch Historical Data

Input: `{tf}` — the timeframe to discover phases for (e.g., M, W, D, H4, H1, 30m, 15m, 1m).

1. Look up `{tf}` in the Timeframe Reference table to get the Oanda granularity and typical candle count 2. Fetch candles from Oanda API:

`GET /v3/instruments/{instrument}/candles?granularity={granularity}&count={typical_candles}&price=M`
Header: `Authorization: Bearer {api_key}`

3. Save to `events/price-ohlcv/discovery/{instrument}-{tf}.md` 4. For validation (Step D3), also fetch the two adjacent timeframes (one higher, one lower) from the Timeframe Reference table:

E.g., if `{tf}` = D, also fetch W and H4
If `{tf}` = M (highest), fetch W and D
If `{tf}` = 1m (lowest), fetch 15m and 30m
Save each to `events/price-ohlcv/discovery/{instrument}-{adjacent_tf}.md`

Report: "Fetched {N} {tf} candles + adjacent TF data for {instrument}."

Step D2: Discover Phases from {TF} Data → `discovery-{tf}.md`

Using the `{tf}` candle data:

1. For each consecutive sequence of candles, compute:

**Price % change**: (close - open) / open × 100, measured over the sequence
**Duration**: number of candles in the sequence

2. Identify natural breakpoints where price behavior changes character:

Significant change in direction (up → down, down → flat, etc.)
Significant change in velocity (fast → slow, slow → fast)
Significant change in volatility (wide ranges → tight ranges, etc.)

3. Group similar segments by their (price%, duration) characteristics 4. Each group = one phase — name it descriptively from its behavior 5. Pick the most common phase as baseline (scale = 1.0 for both parameters) 6. Calculate relative scales for all other phases:

`price_pct_scale` = avg |price%| of this phase / avg |price%| of baseline
`duration_scale` = avg duration of this phase / avg duration of baseline

7. Build transition matrix: count how often each phase follows each other phase

Note: If only 2-3 phases are discoverable from the data, that is valid. Do not force more phases than the data supports. Shorter timeframes with less history will naturally find fewer phases.

Write intermediate file `analyses/{asset}/{date}/market-structure/discovery-{tf}.md`:

# Phase Discovery ({tf}) — {instrument} — {date}

## Parameters

Field	Value
Instrument	{instrument}
Timeframe	{tf}
Period	{start_date} to {end_date}
Candles Analyzed	{count}
Phases Discovered	{N}

## Segment Labels

## Phase Summary

## Transition Counts

## Reasoning {Narrative explaining why these phases were identified and how breakpoints were chosen}

Step D3: Validate on Adjacent Timeframes → `validation-{tf}.md`

Validation uses the two adjacent timeframes from the Timeframe Reference table:

For `{tf}` = M (highest): validate against W and D
For `{tf}` = 1m (lowest): validate against 15m and 30m
For all others: validate against the one higher and one lower adjacent TF
If adjacent TF data is unavailable, validate against the nearest available TF

For each adjacent timeframe:

1. Label the adjacent-TF data using the `{tf}` fingerprint:

Map each adjacent-TF segment to its closest phase by (price%, duration) match

2. Compute the relative scales at this timeframe 3. Calculate ratio correlation between this timeframe's scales and the discovery timeframe's scales 4. Record results

Validation criteria:

Each adjacent TF validates against the discovery TF
Adjacent TF should mostly follow the discovery TF structure — measure multiple metrics: duration correlation, range correlation, and price% correlation
**Pass threshold:** at least TWO of the three metrics (duration, range, price%) must show ≥80% correlation. Price% often degrades at lower timeframes due to noise-floor compression — this is expected and does not invalidate the fingerprint if duration and range pass.
Adjacent TF may show more or less granularity within phases but should not contradict the discovery TF
If all three metrics fail: investigate why, adjust discovery if needed, re-run

If validation fails: The problem is in the discovery, not the timeframe. Go back to Step D2 and adjust (wider cluster tolerance, different phase count, re-examine breakpoints). Do NOT simply mark the fingerprint as "non-fractal" and move on.

Write intermediate file `analyses/{asset}/{date}/market-structure/validation-{tf}.md`:

# Cross-Timeframe Validation ({tf}) — {instrument} — {date}

## Validation Results

timeframe	phases_found	discovery_match	price_r	range_r	duration_r	status	notes
{tf} (source)	{N}	baseline	—	—	—	baseline	—
{adjacent_higher}	{N}	{N/N}	r={X.XX}	r={X.XX}	r={X.XX}	pass/investigate	{notes}
{adjacent_lower}	{N}	{N/N}	r={X.XX}	r={X.XX}	r={X.XX}	pass/investigate	{notes}

## Per-Timeframe Detail

### {adjacent_higher}

{Repeat for adjacent_lower}

## Diagnostic Notes {If any timeframe failed: which phases were problematic, what was investigated, what was adjusted}

Step D4: Out-of-Sample Test → `out-of-sample-{tf}.md`

1. Using the `{tf}` data, hold out the most recent 20% of candles 2. Discover phases using only the first 80% 3. Classify the held-out 20% using the discovered fingerprint 4. Compare: do phase labels match? Do transition probabilities hold? 5. Calculate classification accuracy

Shallow TF exception: For H1 and below (H1, 30m, 15m, 1m), if total segments < 15, skip the out-of-sample test and note "insufficient data for holdout test — {N} segments found, minimum 15 required" in the output file.

Write intermediate file `analyses/{asset}/{date}/market-structure/out-of-sample-{tf}.md`:

# Out-of-Sample Validation ({tf}) — {instrument} — {date}

Field	Value
Timeframe	{tf}
Training Period	{start} to {split_date}
Test Period	{split_date} to {end}
Training Candles	{N}
Test Candles	{N}
Classification Accuracy	{X}%

## Test Period Labels

## Assessment {Does the fingerprint generalize? Any drift or new behaviors in recent data?}

Step D5: Save Fingerprint and Transitions

If validation passes (≥2 of 3 metrics ≥80% per adjacent timeframe, out-of-sample ≥65% accuracy or skipped for shallow TFs):

File naming:

Monthly (`{tf}` = M): `assets/{product}/fingerprint.md` and `assets/{product}/transitions.md` (backward compatible)
All other TFs: `assets/{product}/fingerprint-{tf}.md` and `assets/{product}/transitions-{tf}.md`

[Truncated — full method has 485 lines]

Anti Kelly

Anti-Kelly Analysis

Purpose

Model how a composite operator would engineer price action to reach targets identified by other analysis tracks, maximizing retail pain and minimizing time at favorable prices. Based on Wyckoff composite operator theory.

The composite operator is a useful mental model — not a literal single entity. It represents the aggregate behavior of informed capital (market makers, institutional flow, algorithmic liquidity providers) whose structural advantages (speed, size, information) create predictable manipulation patterns against retail participants.

Pipeline Position

Anti-kelly is a synthesis track that reads from all other analysis tracks (fundamental, technical, regime, market structure) but does NOT feed into any of them. It sits alongside the standard OPP as an adversarial lens.

The trader compares anti-kelly paths against the standard OPP to understand:

Where OPP entry tiers sit relative to smart money's manipulation sequence
Whether the OPP's time window conflicts with the smart money timeline
Which OPP patterns are actually retail traps vs genuine setups

Anti-kelly does NOT replace the OPP. It pressure-tests it. If the OPP entry aligns with where smart money is accumulating, conviction increases. If the OPP entry sits at a retail trap zone, the trader adjusts timing or skips the tier.

Input Spec

The anti-kelly script (`scripts/anti-kelly.js`) preprocesses all analysis track outputs into a single `_llm_input.json`. The LLM receives:

Source	Data	Purpose
`_llm_input.json` current_price	bid/ask/mid	Reference point for all analysis
`_llm_input.json` all_targets	Price targets from all tracks	Destinations smart money drives toward
`_llm_input.json` liquidity_pools	Stop clusters computed from S/R levels	Pools smart money must sweep
`_llm_input.json` retail_traps	Trap zones from patterns/S/R	Where retail predictably enters
`_llm_input.json` wyckoff_templates	5 manipulation sequence templates	Structure for path construction
`_llm_input.json` target_template_map	Which templates apply to each target	Pre-filtered for direction
`_llm_input.json` fundamental_summary	Scenarios, overall view	"Fair value" targets
`_llm_input.json` technical_summary	S/R, patterns, velocity, participants, targets	Price structure context
`_llm_input.json` regime_summary	Paths, result, alignment	Active regime context
`_llm_input.json` market_structure_summary	TF stack, escalation	Structural divergences

Method — Generate

Step 1: Primitive Selection

Given the landscape data, select which manipulation primitives are currently relevant. For each primitive, provide:

A descriptive name (e.g., "Sweep $84 stop cluster")
Type: `spring`, `UTAD`, `false_breakout`, `false_breakdown`, `shakeout`, or `absorption`
Which liquidity pool and/or retail trap it targets
Duration estimate from velocity data
Purpose: what the primitive accomplishes in the manipulation sequence

Criteria for selection:

**Pool depth:** Deep pools are worth sweeping — more order flow captured. A $2 stop cluster with 500 estimated stops is a better target than a $0.50 cluster with 50 stops.
**Proximity to current price:** Close pools are more likely near-term targets. Rank by distance and velocity-implied arrival time.
**Alignment with regime path direction:** Manipulation should work toward identified targets. A spring below support only makes sense if smart money wants to accumulate for upside.
**Participant positioning:** Trapped cohorts are ripe for exploitation. If retail is heavily long at a support level, a spring through that level forces liquidation and provides smart money with cheap supply.

Step 2: Path Construction

For each viable target, construct the optimal manipulation sequence. Rules:

Must follow valid Wyckoff phase ordering (use `wyckoff_templates` as structure)
Must use at least one liquidity sweep (spring or UTAD) — smart money needs order flow
Must include an accumulation/distribution zone where smart money builds position
Markup/markdown phase must be faster than accumulation (time compression principle — smart money moves fast through favorable prices, holds unfavorable prices longer)

For each step in the sequence, specify:

Field	Description
Price level	Where this step occurs
Duration estimate	From velocity data — how long this phase takes
Retail experience	What retail thinks is happening (narrative)
Smart money action	What informed capital is actually doing (narrative)

Example step: "Price drops to $82.50 (2 days). Retail sees breakdown confirmation, sells. Smart money absorbs selling, accumulates at structural support."

Step 3: Probability & Time Profile

Assign probability to each path based on:

**Template fit to current conditions** (40% weight) — How well does the current market structure match the Wyckoff template's expected starting conditions?
**Source target strength** (30% weight) — How strong is the underlying analysis supporting this target? A target from multiple tracks (fundamental + technical + regime) is stronger than one from a single track.
**Primitive availability** (30% weight) — Are the required pools/traps in place? If a path requires a spring through a stop cluster that doesn't exist, the path is unlikely.

Individual path probabilities must be 0-100%. Paths are independent scenarios — total may exceed 100%.

Time profile: Calculate what percentage of total duration is retail-favorable vs smart-money-favorable. In a well-executed manipulation, retail-favorable time (where retail can enter at good prices) is < 20% of total duration. Smart money spends 60-80% of time in accumulation/distribution (appearing directionless) and 20-40% in markup/markdown (fast, decisive moves).

Efficiency: Calculate as `|target_price - current_price| / total_duration_in_days`. Higher efficiency means smart money reaches the target faster per unit time. Compare across paths — the most efficient path is often the most likely, since informed capital minimizes time exposure.

Step 4: Initial Alignment & Result

Assess where current price sits in each path's sequence:

Which step are we in?
How well does recent price action match the predicted phase behavior?
Score each criterion 0-100:

Criterion	What to evaluate
Price	Is price at the level predicted for this phase?
Velocity	Does current velocity match expected phase velocity (e.g., slow grinding = accumulation)?
Volume	Does volume profile match (e.g., decreasing volume in accumulation, spike on spring)?
Retail behavior	Are retail participants behaving as predicted (e.g., exiting on shakeout, entering on false breakout)?

Produce the result summary:

Top path by probability
Confidence: high (>70% alignment), medium (40-70%), low (<40%)
Time to favorable entry: when does the manipulation create a genuine entry opportunity (i.e., when does smart money finish accumulating and begin markup?)
Actionable insight: 3-5 sentences describing what smart money is doing RIGHT NOW, what retail thinks is happening vs what's actually happening, and where the real entry opportunity is

Method — Update

Step U1: Review Mechanical Scores

Review mechanical alignment scores from `_update_input.json`. The script has already computed price/velocity/duration scores for each path by comparing predicted vs actual values.

Step U2: Override Mechanical Scores

Override scores where LLM judgment differs from mechanical calculation. The mechanical score may miss nuances — for example, a price deviation that actually confirms the path rather than diverging from it (a spring that goes deeper than predicted is still a spring, and may indicate even stronger accumulation).

Provide reasoning for each override.

Step U3: Update Probabilities

Update probabilities based on how well price tracked the predicted sequence:

If a path's steps are playing out as predicted, increase probability
If price action contradicts the predicted phase, decrease probability
If a path's spring/UTAD has been confirmed (liquidity swept, price reverted), significantly increase probability for the subsequent markup/markdown phase

Step U4: Mark Consumed Primitives

Mark consumed primitives — liquidity pools that have been swept, retail traps that have been sprung. Update landscape status:

**Swept pool:** Mark as consumed, note fill quality (was the sweep clean or did price linger?)
**Sprung trap:** Mark as consumed, note retail response (did retail exit as predicted?)
**New pools formed:** If price action has created new stop clusters (e.g., new longs placing stops below recent swing low), add to landscape

Step U5: Generate New Paths (if needed)

If price action suggests a manipulation pattern not in existing paths, generate new path(s). This is rare but important for capturing emerging patterns. Triggers for new path generation:

Price breaks out of all existing path ranges
A new liquidity pool forms that wasn't in the original landscape
A structural shift (e.g., timeframe escalation) changes the manipulation playbook

Method — Review

Review scores expired anti-kelly analyses against actual price outcomes, extracting product-specific lessons for future analyses.

Step R1: Score Path Outcomes

For each predicted manipulation path, compare against actual H4 price data:

**Target proximity:** Did price reach within 1 ATR of the predicted target? Score 0-100 based on closest approach.
**Sequence accuracy:** For each step in the manipulation sequence, did price reach the predicted level? Score each step individually, then average.
**Steps completed:** How many of the predicted sequence steps actually occurred in the correct order?

Override mechanical scores where LLM context adds value — e.g., a path that "missed" mechanically but captured the correct market dynamic is still a partial success.

Step R2: Assess Primitive Consumption

For each predicted manipulation primitive:

**Consumed:** Was the liquidity pool swept or trap activated? (H4 wick through pool level = consumed)
**Timing accuracy:** How close was the actual consumption timing to the predicted duration? Score 0-100.
**Depth accuracy:** How close was the actual sweep depth to the predicted level? Score 0-100.

Step R3: Evaluate Trap Effectiveness

For each predicted retail trap:

**Sprung:** Did price enter the trap zone?
**Retail behavior:** Did retail participants react as predicted? (e.g., panic selling on false breakdown, chasing on false breakout)
**Smart money follow-through:** After the trap was sprung, did price move in the predicted direction?

Step R4: Extract Product-Specific Insights

Synthesize path, primitive, and trap outcomes into recurring patterns:

Which Wyckoff templates fit this product's manipulation style best?
What typical sweep depths (in ATR) does this product exhibit?
How do participants typically react to manipulation phases in this product?
What temporal patterns emerge (time-of-day, day-of-week, session-specific)?

Step R5: Update Knowledge Base

Generate structured knowledge updates for merging into the knowledge file:

**Manipulation fingerprint:** New or reinforced recurring patterns
**Trap effectiveness:** Updated hit rates and retail response observations
**Sweep behavior:** ATR-normalized sweep depths, durations, recovery speeds
**Participant patterns:** Cohort-specific behavior during manipulation phases
**Temporal patterns:** Time-based observations with confidence levels

Method — Correlated Analysis

When historical knowledge exists (from prior reviews), the generate flow includes correlated analysis that adjusts standard output based on accumulated lessons.

Step C1: Historical Pattern Matching

Compare the current landscape (targets, pools, traps, market structure) against the manipulation fingerprint from the knowledge file:

Which historical patterns match the current setup?
How similar is the current setup to past reviewed analyses?
What was the outcome of similar setups historically?

Step C2: Probability Calibration

Adjust path probabilities based on historical hit rates:

If the knowledge file shows that paths with this template type have historically hit 80% of the time, adjust probability upward
If historical data shows systematic over/under-estimation, apply calibration correction
Note: adjustments should be modest (typically ±5-15%) — historical sample sizes are small

[Truncated — full method has 244 lines]

Opportunity Analysis

Purpose

Identify trading opportunities by finding price points at the extremes of the probability distribution — prices unlikely to sustain — using the fundamental range as bounds, technical dynamics for precision, and regime nature for distribution shape. Outputs actionable entry/exit zones with JS-expressible trigger conditions for automated monitoring.

Input Spec

Required Intermediates

From `analyses/{asset}/{date}/`:

File	Key Data Used
`fundamental/result.md`	Scenarios with probabilities + price ranges
`fundamental/influence-weights.md`	Factor weights for conviction assessment
`technical/result.md`	Price targets, bias, key levels
`technical/velocity.md`	Current velocity regime, momentum
`technical/patterns.md`	S/R levels, active patterns, pattern targets
`technical/participants.md`	Dominant participants, positioning

Optional Intermediates

File	Key Data Used
`regime/result.md`	Active regime, distribution shape, price target
`regime/paths.md`	Active price paths with probabilities
`regime/alignment.md`	Path tracking status

Current Price

Fetch from Oanda API: ``` GET https://api-fxpractice.oanda.com/v3/instruments/{instrument}/candles?granularity=M1&count=1&price=M Authorization: Bearer 618551d36d05948f75c12143303ccec4-9a77b49c0f8c42f1f90271f6022a3676 ```

Asset Context

Read `assets/{asset}/SKILL.md` for instrument code, currency, unit.

Method

Step 1: Range Bounds → `range-bounds.md`

Extract and probability-weight the fundamental price range.

1. Read `fundamental/result.md` — extract the scenarios table 2. For each scenario: extract probability, price_low, price_high, midpoint 3. Calculate:

**Tradeable range low** = weighted average of scenario lows (probability × low)
**Tradeable range high** = weighted average of scenario highs (probability × high)
**Fair value center** = weighted average of scenario midpoints
**Tail low** = minimum price across all scenarios (bear/tail case)
**Tail high** = maximum price across all scenarios (bull/tail case)

4. Divide the range into probability zones:

**Core zone** (60% probability): fair_value ± 1 std_dev_equivalent
**Extended zone** (25% probability): between core and tradeable range bounds
**Tail zone** (15% probability): beyond tradeable range to tail extremes

5. Assess current price position: which zone is it in?

Output format — write to `trades/{asset-slug}/opportunities/OPP-{timestamp}/range-bounds.md`:

```markdown

Range Bounds

Field	Value
Tradeable Range Low	${low}
Tradeable Range High	${high}
Fair Value Center	${center}
Tail Low	${tail_low}
Tail High	${tail_high}
Current Price	${current}
Current Zone	{core/extended-low/extended-high/tail-low/tail-high}

Probability Zones

zone	low	high	probability	description
tail-low	${tail_low}	${ext_low_boundary}	{prob}%	Extreme undervaluation — high-conviction entry
extended-low	${ext_low_boundary}	${core_low}	{prob}%	Below fair value — moderate entry
core	${core_low}	${core_high}	{prob}%	Fair value range — no edge
extended-high	${core_high}	${ext_high_boundary}	{prob}%	Above fair value — moderate exit
tail-high	${ext_high_boundary}	${tail_high}	{prob}%	Extreme overvaluation — high-conviction exit

Scenario Mapping

scenario	probability	low	high	midpoint
{scenario name}	{prob}%	${low}	${high}	${mid}

```

Step 2: Price Dynamics → `price-dynamics.md`

Map technical structure within the fundamental range.

1. Read `technical/patterns.md` — extract S/R levels, active patterns, targets 2. Read `technical/velocity.md` — current velocity regime, momentum direction 3. Read `technical/participants.md` — dominant participant, phase (accumulation/markup/distribution/markdown) 4. Read `technical/result.md` — technical price targets 5. Map S/R levels onto the probability zones from Step 1:

Which supports align with zone boundaries? (reinforcing)
Which resistances cap specific zones? (barriers)

6. Identify overshoot zones:

Where has price historically overshot S/R before reverting?
These are prime entry/exit points (temporary mispricing)

7. Assess velocity context:

Trending → overshoots are deeper, take longer to revert
Ranging → overshoots are shallower, revert quickly
Transitioning → highest uncertainty, wider entry zones

Output format — write to `trades/{asset-slug}/opportunities/OPP-{timestamp}/price-dynamics.md`:

```markdown

Price Dynamics

Field	Value
Velocity Regime	{trending/ranging/transitioning}
Momentum	{direction and strength}
Dominant Participant	{cohort}
Participant Phase	{accumulation/markup/distribution/markdown}

Key Levels Within Range

level	price	type	zone_alignment	strength	overshoot_potential
{name}	${price}	{support/resistance}	{which probability zone}	{strong/moderate/weak}	{high/medium/low}

Overshoot Zones

zone	entry_price	revert_target	expected_duration	probability	rationale
{name}	${price}	${revert_to}	{timeframe}	{prob}%	{why this overshoot is likely to revert}

Participant Context

{2-3 sentences on how dominant participant positioning affects entry/exit timing} ```

Step 3: Regime Adjustment → `regime-adjustment.md`

Adjust the probability distribution based on regime behavior.

1. Check if `regime/result.md` exists 2. If regime exists:

Read active regime type
Read alignment score and best path
Apply regime-specific distribution adjustments:
**Trending regime** → skew distribution in trend direction, extend tail in trend direction, compress counter-trend tail
**Mean-reverting regime** → tighten distribution around center, sharpen entry/exit at extremes
**Crisis/volatile regime** → widen both tails, increase overshoot potential, shorten time windows
**Transitioning regime** → widen core zone, reduce conviction at extremes
Read `regime/paths.md` for active price paths → use path targets as additional entry/exit reference points

3. If no regime analysis exists:

Use unadjusted distribution from Steps 1-2
Note: "No regime adjustment — using base distribution"

4. Adjust time windows:

Trending → longer hold periods
Mean-reverting → shorter, more frequent opportunities
Volatile → very short, use tight stops

Output format — write to `trades/{asset-slug}/opportunities/OPP-{timestamp}/regime-adjustment.md`:

```markdown

Regime Adjustment

Field	Value
Active Regime	{regime name or "None"}
Regime Confidence	{high/medium/low or "N/A"}
Distribution Adjustment	{skew-bullish/skew-bearish/tighten/widen/none}
Time Window Adjustment	{extend/compress/none}

Adjusted Zones

zone	original_low	original_high	adjusted_low	adjusted_high	adjusted_prob	adjustment_rationale
tail-low	${orig}	${orig}	${adj}	${adj}	{prob}%	{why adjusted}
extended-low	...	...	...	...	...	...
core	...	...	...	...	...	...
extended-high	...	...	...	...	...	...
tail-high	...	...	...	...	...	...

Regime Path Integration

path	probability	target	status	implication_for_entry
{PATH ID}	{prob}%	${target}	{tracking/diverging}	{how this path affects entry/exit zones}

Time Windows

action_type	base_window	adjusted_window	rationale
Entry hold	{base}	{adjusted}	{regime effect on hold time}
Exit target	{base}	{adjusted}	{regime effect on target time}
Stop review	{base}	{adjusted}	{regime effect on stop monitoring}

```

[Truncated — full method has 744 lines]

Point In Time Analysis

Point-in-Time Analysis

Purpose

Produce timestamped PAT/PF/PD snapshots that decompose the current price into weighted factor contributions, generate multi-track forecasts, and (if a prior snapshot exists) explain price changes between snapshots. Reads existing fundamental + technical + regime intermediates — never re-runs them.

Input Spec

Required Intermediates

From `analyses/{asset}/{date}/`:

File	Key Data Used
`fundamental/influence-weights.md`	Factor names + weight_pct (sums to 100%)
`fundamental/result.md`	Scenarios with probabilities + price targets
`technical/patterns.md`	Key levels + pattern targets + reliability
`technical/participants.md`	Cohort positions (institutional/commercial/speculative/retail)
`technical/result.md`	Price targets with timeframes
`regime/result.md`	Active regime, best path, price target, confidence (optional — used if regime analysis exists)

Asset Context

Read `assets/{asset}/SKILL.md` if it exists, to obtain:

Instrument code (e.g., BCO_USD)
Currency (e.g., USD)
Unit (e.g., bbl)

Prior Snapshots

Check `analyses/{asset}/{date}/snapshots/` for existing PAT files to:

Determine next ID numbers (PAT002 if PAT001 exists, etc.)
Enable PD generation by diffing against the most recent PAT

Method

Step 1: Fetch Current Price

Call the Oanda API for the asset's instrument:

``` GET https://api-fxpractice.oanda.com/v3/instruments/{instrument}/candles?granularity=M1&count=1&price=M Authorization: Bearer 618551d36d05948f75c12143303ccec4-9a77b49c0f8c42f1f90271f6022a3676 ```

Extract the latest mid close price. Record the timestamp in ISO 8601 format (e.g., `2026-03-08T14:00:00Z`).

Step 2: Determine IDs

Scan `analyses/{asset}/{date}/snapshots/` for existing files:

Count PAT files → next PAT ID = PAT{NNN} where NNN = count + 1 (zero-padded to 3 digits)
Count PD files → next PD ID = PD{NNN}

For PF IDs, check both the snapshots directory AND the consolidated file `analyses/{asset-slug}-{date}.md` (if it exists) for the highest existing PF ID. The consolidated file may contain analysis-generated PFs (PF001, PF002) from the web-consolidation skill. The next snapshot PF must use the highest existing PF number + 1 to avoid ID collisions.

Read `analyses/{asset-slug}-{date}.md` and scan for `PF\d+` patterns → find max PF number
Also count PF files in `snapshots/` → find max PF number there
Next PF ID = max(consolidated_max, snapshot_max) + 1

If no snapshots directory exists and no consolidated file exists, start at PAT001, PF001, PD001.

Step 3: Generate PAT (Price Attribution)

Map each factor from `fundamental/influence-weights.md` to a price component:

1. Read influence-weights.md — each row has: factor, weight_pct, rationale 2. For each factor:

Determine direction from supply/demand factors (bullish = positive, bearish = negative)
Determine category: map factor content to one of: `fundamental-premium`, `risk-premium`, `supply-disruption`, `demand-pull`, `speculative-premium`, `liquidity-discount`, `seasonal-adjustment`, `technical-premium`, `base-cost`
Calculate: `component_value = current_price × (weight_pct / 100) × direction_sign`
Calculate: `component_percent = weight_pct%`

3. Sum all components 4. Residual = current_price - sum_of_components (should be small; format as `$X.XX/unit`) 5. Validation note = `Components sum to $X.XX vs actual $Y.YY`

Assign each component an ID: PA001, PA002, etc.

Output format — write to `analyses/{asset}/{date}/snapshots/PAT-{timestamp}.md`:

```markdown

PAT{NNN}

Field	Value
Instrument	{instrument}
Price	${price}/{unit}
Currency	{currency}
Unit	{unit}
Timestamp	{ISO 8601 timestamp}
Trigger	Scheduled point-in-time snapshot
Trigger Ref	-

id	component	category	value	percent	basis	trend	confidence	references
PA001	{factor name}	{category}	{+/-$X.XX}	{weight}%	{rationale}	{trend}	{confidence}	-
PA002	...	...	...	...	...	...	...	-

Residual: {$X.XX/unit} Validation: Components sum to ${sum} vs actual ${price} ```

IMPORTANT: The file contains a single `### PAT{NNN}` section. The key-value table comes first, then the components table, then the Residual and Validation lines. This format matches what the web parser expects.

Step 4: Generate PF (Price Forecast)

Build a multi-track forecast combining fundamental, participant, and pattern tracks:

Fundamental track:

Read `fundamental/result.md` scenarios table
Weighted price = sum(probability × midpoint_of_price_target) across scenarios
Range: lowest scenario low to highest scenario high
Confidence: from result synthesis
Method: `scenario-weighted`

Participant track:

Read `technical/participants.md` for dominant cohort and direction
Read `technical/result.md` for price targets related to positioning
Target: price level implied by dominant participant phase (e.g., markup target)
Confidence: from participant confidence column
Method: `positioning-flow`

Pattern track:

Read `technical/patterns.md` for active patterns and targets
Target: primary pattern target
Confidence: from pattern reliability
Method: `technical-level`

Regime track (if regime analysis exists):

Check if `regime/result.md` exists in `analyses/{asset}/{date}/`
If it exists, read it for:
Price target from the regime result
Confidence from the regime result
Active regime name for reasoning
Target: regime-implied price target
Confidence: from regime result
Method: `historical-analog`

Track weights:

If regime analysis exists (4 tracks):

fundamental: 35%
participant: 25%
pattern: 20%
regime: 20%

If no regime analysis (3 tracks, original weights):

fundamental: 40%
participant: 30%
pattern: 30%

Composite calculation:

compositePrice = sum(track_target × track_weight / 100)
compositeLow = min(track lows)
compositeHigh = max(track highs)
compositeConfidence = modal confidence across tracks

Output format — write to `analyses/{asset}/{date}/snapshots/PF-{timestamp}.md`:

```markdown

Temporal Validity

Field	Value
Created	{ISO 8601 datetime from snapshot timestamp}
Last Validated	{ISO 8601 datetime — same as Created initially}
Valid From	{forecastDate from PF table}
Valid To	{targetDate from PF table}
Trading Days	{business days between Valid From and Valid To}
Calendar Days	{total days between Valid From and Valid To}
Data Window	{forecastDate} to {forecastDate}

Price Forecasts

id	instrument	forecastDate	targetDate	targetTimeframe	compositePrice	compositeLow	compositeHigh	compositeConfidence	status	actualClose	error	errorPercent	references
PF{NNN}	{instrument}	{date}	{target_date}	2-4 trading days	{composite}	{low}	{high}	{confidence}	active	-	-	-	PAT{NNN}

PF{NNN}

track	method	predictedPrice	predictedLow	predictedHigh	confidence	weight	reasoning	references
fundamental	scenario-weighted	{price}	{low}	{high}	{conf}	40	{reasoning}	-
participant	positioning-flow	{price}	{low}	{high}	{conf}	30	{reasoning}	-
pattern	technical-level	{price}	{low}	{high}	{conf}	30	{reasoning}	-
regime	historical-analog	{price}	{low}	{high}	{conf}	20	{reasoning}	-

```

Note: The regime track row is only included when regime analysis exists. When present, use the 4-track weights (35/25/20/20). When absent, use the 3-track weights (40/30/30) and omit the regime row.

IMPORTANT: The PF file contains both the summary table under `## Price Forecasts` and the track detail under `### PF{NNN}`. The `references` column in the summary table links to the associated PAT snapshot ID.

Step 5: Generate PD (Price Delta) — Only If Prior PAT Exists

If a prior PAT snapshot exists in `analyses/{asset}/{date}/snapshots/`:

1. Read the most recent prior PAT file 2. For each component in the current PAT, find the matching component in the prior PAT (by component name) 3. Calculate delta = current_value - prior_value for each component 4. Determine status: `increased`, `decreased`, `unchanged`, `new` (no prior match), `removed` (in prior but not current) 5. Explained = sum of all component deltas

[Truncated — full method has 244 lines]

Cross Product Analysis

Cross-Product Analysis

Purpose

Discover inter-product relationships and produce spread/pair trading opportunities by analyzing relative price dynamics between products. Unlike directional analysis tracks, this track reasons about relative price changes — predicting spread widening/narrowing rather than up/down.

Pipeline Position

Standalone command: `/trade-cross-product [all | <product-a> <product-b>]`
Runs after per-asset analyses (fundamental, technical, regime) are complete
Not integrated into `/trade-analyze` pipeline
Two modes: full graph discovery (`all`) or targeted pair analysis

Input Spec

Input	Source	Purpose
Fundamental results	`analyses/{asset}/{date}/fundamental/result.md`	Directional bias, key drivers, supply/demand factors
Technical results	`analyses/{asset}/{date}/technical/result.md`	Price velocity, participant behavior, patterns
Regime results	`analyses/{asset}/{date}/regime/result.md`	Product-specific behavior context
Raw events	`events/{type}/{date}/*.md`	Cross-product co-occurrence scanning
Asset skills	`assets/{asset}/SKILL.md`	Product names, aliases, tickers for keyword matching
Knowledge library	`assets/cross-product/relationships.md`	Persistent confirmed relationships
Discovered instruments	`assets/cross-product/instruments.md`	Oanda tradability for untracked products
Price data	Oanda REST API	Spread history, correlation matrices

Method

Step 1: Product Graph Construction → `graph/nodes.md`

1. Run `node scripts/cross-product.js prepare-graph` — parses all per-asset analyses, extracts prices/velocity/bias, scans events for product keyword co-occurrences, computes price correlation matrix 2. Script outputs `xp-graph-state.json` + `xp-graph-llm-input.json` to `analyses/.tmp/` 3. LLM reads `xp-graph-llm-input.json` and produces edge judgments (next step)

Step 2: Relationship Discovery → `graph/edges.md`

Script/LLM boundary:

**Script (mechanical):** keyword matching for product co-occurrences in events, price correlation computation
**LLM (judgment):** causality reasoning, importance scoring (0-100), relationship type assignment

Edge types: `substitution`, `supply_displacement`, `macro_cascade`, `input_cost`, `correlation_break`, `flow_rotation`

Prune edges with importance < 30.

1. LLM fills edge judgment JSON with: product_a, product_b, relationship_type, direction, importance (0-100), evidence, timeframe_days 2. Run `node scripts/cross-product.js assemble-graph` — graph traversal, chain tracing, pruning 3. Script outputs `nodes.md`, `edges.md`, `chains.md` to `analyses/_cross-product/{date}/graph/`

Step 3: Chain Tracing → `graph/chains.md`

Handled by `assemble-graph` script:

Start from each edge with importance >= 60
Follow outgoing edges with 0.7 decay per hop
Stop at importance < 30, length > 5 hops, or circular
Check Oanda instrument availability for untracked products in chains

Step 4: Event Generation → `events/cross-product/{date}/`

For each significant relationship or chain: 1. LLM generates structured cross-product events using schema from `events/cross-product/_schema.md` 2. Columns: timestamp, source_event, products, relationship_type, direction, importance, timeframe, evidence 3. LLM also identifies information gaps → `source-recommendations.md`

Step 5: Spread Analysis → `spreads/{pair}/`

1. Run `node scripts/cross-product.js prepare-spreads` — fetches spread price history from Oanda, computes stats (mean, stddev, z-score, percentiles), lookback scaled by relationship type 2. Script outputs `xp-spread-state.json` + `xp-spread-llm-input.json` to `analyses/.tmp/` 3. LLM fills spread judgment JSON with: win_probability, target_spread, stop_spread, entry prices, leg directions, confidence, narrative, invalidation 4. Run `node scripts/cross-product.js assemble-spreads` — Kelly calculation, markdown assembly

Per-pair output:

`relationship.md` — Temporal Validity + relationship KV table + narrative + invalidation
`spread-analysis.md` — Temporal Validity + spread metrics + historical stats + Kelly analysis + legs table

Step 6: Synthesis → `result.md`

Handled by `assemble-spreads` script:

Ranked opportunities by halfKelly x importance
Consolidated file at `analyses/cross-product-{date}.md`
Source recommendations if information gaps identified
Archive intermediates to `_intermediates/{timestamp}/`

Output Files

File	Location	Temporal Validity
`nodes.md`	`_cross-product/{date}/graph/`	Snapshot day (refreshed daily)
`edges.md`	`_cross-product/{date}/graph/`	Until driving event expires
`chains.md`	`_cross-product/{date}/graph/`	Bounded by weakest link
`relationship.md`	`_cross-product/{date}/spreads/{pair}/`	Adaptive per relationship type
`spread-analysis.md`	`_cross-product/{date}/spreads/{pair}/`	Matches relationship timeframe
`result.md`	`_cross-product/{date}/`	Union of all spread windows
`source-recommendations.md`	`_cross-product/{date}/`	Informational, no expiry
Cross-product events	`events/cross-product/{date}/`	Per event type defaults
Consolidated	`analyses/cross-product-{date}.md`	Matches result.md

Cross-references

**Reads from:** fundamental/result.md, technical/result.md, regime/result.md (all tracked assets), raw events (all types), asset skills, price data
**Feeds into:** spread execution via Spread Distribution State, knowledge library updates
**Independent of:** Does not create reasoning dependencies on per-asset track conclusions — uses them as data inputs only

Event Rollup

Event Roll-up Analysis

Purpose

Roll-up produces higher-level summary events from lower-level events. Each roll-up level is itself an event, stored in the appropriate timeframe file. The LLM decides what matters at each level.

Input Spec

**Source:** Any event type directory under `events/{type}/`
**Filter:** Date range for the roll-up period
**Schema:** Read the event type's `_schema.md` to understand columns and roll-up method

Method

Step 1: Read the schema

Read `events/{type}/_schema.md`. Check the `Roll-up` section:

If **method = template**: apply the template mechanically
If **method = llm**: proceed to LLM summarization (Step 3)

Step 2: Template roll-up (for structured types)

For template-based types (price-ohlcv, economic-release, inventory, positioning):

1. Read all lower-level event files for the roll-up period 2. Apply the aggregation rule defined in the schema:

**price-ohlcv:** Open of first candle, high of max(high), low of min(low), close of last candle, sum of volumes
**economic-release:** List all releases with their surprise direction
**inventory:** List all reports with their change direction
**positioning:** Latest snapshot values with change from period start

3. Write the summary using the schema's summary template 4. Save to the appropriate timeframe file

Step 3: LLM roll-up (for complex types)

For LLM-based types (geopolitical, policy):

1. Read all lower-level event files for the roll-up period 2. Follow the roll-up instruction in the schema 3. Produce a structured summary that:

Captures the dominant theme
Notes escalation/de-escalation direction
Identifies key actor moves
States net price impact direction
Stays under the word limit specified in the schema

4. Save to the appropriate timeframe file

Step 4: Store the roll-up

Save the summary event in the correct location:

Daily roll-up: `events/{type}/{YYYY-MM-DD}/{instrument}-D.md` or `events/{type}/{YYYY-MM-DD}-summary.md`
Weekly roll-up: `events/{type}/{YYYY}-W{WW}/` directory
Monthly roll-up: `events/{type}/{YYYY-MM}/` directory

Output Schema

The output is a new event file following the same type schema, but at a higher timeframe. For template types, it's a table row. For LLM types, it's a summary section plus a table row.

LLM Roll-up Output Format

# {Type} {Period} Summary — {date range}

## Summary

{LLM-generated narrative summary}

## Events

| {same columns as source schema} |

| ... rolled-up/summarized rows ... |

Intermediate Files

None — roll-up is a single-step transformation.

Cross-references

None — roll-up operates within a single event type.