From Videos to Rules: Extracting Trading Logic

The Observation Problem

You've watched 200 hours of trading content. You've taken notes. You can recognize the setups. And yet — when it's time to execute, you hesitate. You second-guess. The setup looks "almost right" but you're not sure.

This is the observation problem: watching a trader and understanding their system are two completely different things. Most traders watch for patterns. The market rewards those who watch for rules.

The difference matters more than you think. A pattern is something you recognize by shape. A rule is something you can execute without judgment. A pattern requires you to decide if this looks like the setup. A rule removes the decision — you either qualify or you don't.

The work of building a trading system is the work of converting observations into rules. This lesson shows you how to do it — and how to detect when you've gotten it wrong.

What Rules Actually Look Like

Before extracting rules, you need to know what a rule looks like when it's done.

A bad rule: "Buy when the setup looks bullish."

A good rule: "Enter long when: (1) the 15-min candle closes above the descending neckline resistance, (2) volume on that candle exceeds the 20-period average by at least 1.3x, and (3) the 4H regime is neutral or bullish as measured by price above the 20 EMA with BB width below the 30-day average."

The difference is precision. A good rule has:

• A specific trigger — exactly what must happen
• Measurable criteria — numbers, not feelings
• Context requirements — what must be true about the broader environment
• Falsifiability — you can determine, in hindsight, whether the rule fired correctly

If you can't code it, it's not a rule yet. That's the test.

The Extraction Process

Here's the process used to build the Foresight signal engine from 815 recorded sessions:

Step 1: Consume first for comprehension. Watch or read without taking notes. Get the gestalt of how the trader thinks. What's their primary concern — trend direction, volatility regime, specific price levels? Understanding their framework before extracting specifics prevents misinterpretation.

Step 2: Extract on second pass. Go back through and capture every stated condition for entry, exit, and avoidance. Timestamp every extraction. Capture exact quotes, not paraphrases.

Step 3: Frequency weight. Across all sessions, count how often each pattern or condition appears. A setup mentioned once might be anecdote. A setup that appears in 60% of sessions is part of the core system.

Step 4: Separate entry conditions from avoidance conditions. These are two different lists. Entry conditions define when to trade. Avoidance conditions (your Do-Not-Trade list) define when explicitly not to trade even if an entry condition fires.

Step 5: Quantify everything. "Strong volume" becomes "volume exceeds 20-period average by X." "Clear trend" becomes "price above 20 EMA on the trading timeframe." Every qualitative observation gets a quantitative proxy.

Frequency Weighting: What Actually Matters

The 815-session extraction produced a raw list of 47 potential patterns and conditions. But not all 47 are equally important.

Frequency weighting filters signal from noise:

• High frequency (50%+ of sessions): Core system components. These are non-negotiable in the final ruleset.
• Medium frequency (20-50%): Supplementary filters. Use as confirmation, not primary triggers.
• Low frequency (under 20%): Anecdote. Either the trader was experimenting or the condition is market-specific. Exclude from the systematic ruleset.

After frequency filtering, 815 sessions compressed to 19 measurable entry patterns and 20 Do-Not-Trade conditions. The other 8 patterns were present but not frequent enough to justify inclusion.

This is a critical step most traders skip. They extract everything and end up with a system so complex it's impossible to execute. Frequency weighting forces you to build around what matters most.

The Fabrication Audit

This is where most extraction processes fail.

When you're working through large volumes of content and trying to fill in gaps, your brain will fabricate rules. Not intentionally — but the pattern-seeking nature of human cognition will infer rules that were never explicitly stated.

The fabrication audit is the process of going back to every rule in your extracted list and asking: "Where exactly did this come from? Can I timestamp it to a specific source?"

If you can't timestamp a rule to a source, it's a fabrication. This doesn't mean the rule is wrong — it means you invented it based on inference, and it needs to be validated differently from extracted rules.

Separate your ruleset into two columns: Extracted (timestamped to source) and Inferred (derived by logic). Both can end up in your final system, but inferred rules carry more uncertainty and should be validated with backtesting before you trade them live.

For the Foresight engine, the fabrication audit caught 7 rules in the initial extraction that couldn't be sourced. Four were removed. Three were validated through backtesting and kept. The audit saved months of trading a partly-fabricated system.

The Output: Your Rule Document

When the extraction is complete, you should have a rule document with the following structure:

Entry Conditions (all must be true):

1. [Specific trigger with measurable criteria]
2. [Volume/momentum confirmation]
3. [Regime context requirement]

Do-Not-Trade Conditions (any one blocks entry):

1. [Condition A]
2. [Condition B] ...

Exit Rules:

• Target: [Where the trade thesis completes]
• Stop: [Where the thesis is proven wrong]
• Time stop: [Maximum hold duration if neither target nor stop hit]

This document is your system. Everything outside this document is discretion — and discretion is the first thing that fails under pressure.

The InDecision Framework started as exactly this kind of rule document. Over time, with backtesting and live validation, it compressed further into the 6-factor conviction scoring model. But the foundation was always rules extracted from observation — not intuitions developed from experience.

Experience informs judgment. Rules enable execution. You need both, and they're not the same thing.

What This Changes

Once you have a rule document, three things change immediately:

You stop second-guessing entries. The checklist either clears or it doesn't. You don't decide — the rules decide.

You can backtest properly. Rules are backtestable. Intuitions aren't. The moment you have a rule document, you can walk through historical data and verify the edge before risking real capital.

You can identify what's failing. When you take a loss, you can audit whether the rules fired correctly and the trade just lost, or whether you deviated from the rules. These are completely different problems with completely different solutions.

The observation problem doesn't resolve itself with more observation. It resolves with the discipline to convert observation into rules — and the intellectual honesty to audit those rules for fabrication before you trade them.

Start the extraction. Run the fabrication audit. Build the rule document. Then we can talk about backtesting it.