Trading Systems

Engineering Evolution

A rule-based trading agent evolved into a modular decision architecture focused on explainability, evaluation, and continuous improvement.

Reliable decision pipelines need testing, reasoning, and evaluation rather than simple signal generation.

An iterative engineering story about replacing excitement with evaluated change.

Evolution Path
versioned strategy hypotheses and review
Experimentation
regime checks, backtests, comparison
Tradeoff Record
kept, narrowed, and removed assumptions
Status
draft
Year
2026
Role
Founder · AI Engineer · Systems Designer
Duration
Iterative research
Focus
Explainability, evaluation, continuous improvement, and modular decision architecture
  • Python
  • Pandas
  • Backtesting
  • Technical Analysis
  • Machine Learning

SECTION 01

Overview

Engineering Evolution is the story of moving from a rule-based trading agent into a modular decision architecture.

V2, V3, and ORB were not treated as a ladder where the newest version automatically wins. They became separate hypotheses: a broad momentum scalper, a stricter adaptive engine, and a selective structure-based breakout strategy. The important shift was learning to judge them by regime and evidence instead of by recency.

The important work is not short-term trading performance. It is the decision pipeline: testing, reasoning, and evaluation that make each strategy change reviewable instead of treating a lucky signal as proof.

SECTION 02

Problem

I built these iterations because a single strategy result was too easy to overread.

One choppy session can make a broad scalper look superior. The same session can make a stricter engine look weak and a breakout strategy look broken. The work became less about finding a universal winner and more about building a comparison system that could ask: what kind of day was this, and which engine was actually designed for it?

SECTION 03

Why Existing Solutions Weren't Enough

Simple trading bots can generate signals, but signals alone do not explain whether the system is improving. A profitable-looking backtest can hide regime dependence, overfitting, and brittle assumptions.

This project became valuable when the goal moved from "find a trade" to "build a decision pipeline that can be reviewed."

SECTION 04

Architecture

The architecture separates data preparation, indicators, strategy rules, evaluation, and review.

  • Pandas pipelines normalize market data and derived features.
  • Strategy modules express hypotheses as testable decision logic.
  • Backtests compare behavior across regimes instead of treating one result as truth.
  • Review outputs explain why a strategy changed from V2 to V3 to ORB.

SECTION 05

Interesting Engineering Decisions

The key decision was to keep multiple strategy generations alive as different hypotheses. V2, V3, and ORB are not just versions; they represent different beliefs about momentum, filtering, and structure.

That makes evaluation more honest because the system can ask which strategy fits the regime instead of assuming the latest code is the best code.

SECTION 06

Challenges

The central challenge was avoiding false conclusions from small samples.

V2 trades more often and can look better in mixed conditions because it casts a wider net. V3 is stricter, so it needs more observations before its edge or weakness is visible. ORB is the most selective and needs the right market structure before it can be judged at all.

The engineering problem became evaluation design: log each system, tag the regime, keep zero-trade days as data, and compare results by condition instead of collapsing everything into one winner.

SECTION 07

Tradeoffs

Rule-based systems are easier to inspect, but they can be rigid. Machine-learning layers are more adaptive, but they can become harder to trust.

The current architecture keeps explainability close to the decision path and treats ML as one input into a larger evaluation process, not a replacement for judgment.

SECTION 08

Evidence

What can be inspected

Which strategy generation fits which market regime?

Which strategy generation fits which market regime?

  • Version timeline
  • Evolution path
  • Backtest curve
  • Decision pipeline

Regime review

Strategies are compared under different conditions.

Change record

Assumptions are kept, narrowed, or removed explicitly.

Current evidence focuses on why each strategy generation exists and how it should be judged.

  • Strategy timeline: why V2, V3, and ORB exist as separate hypotheses.
  • Decision pipeline: data, indicators, scoring, risk checks, and review output.
  • Backtesting evidence: behavior compared across regimes instead of one aggregate score.
  • Change record: why a trading assumption was kept, narrowed, or removed.

SECTION 09

Outcome

The project now reads as an engineering evolution: from signal generation to modular decision architecture.

Its credibility comes from explicit versions, backtesting discipline, and a review loop that values explainability over short-term excitement.

SECTION 10

Lessons Learned

The lesson was not to crown or kill a system from one day of evidence.

V2 fitting a choppy day does not prove it is the best strategy. V3 being quiet does not prove it is useless. ORB producing few setups does not prove the structure is broken. Each system has to be judged in the environment it was built for.

That changed the design direction from strategy selection to regime routing. The next version should treat quiet days, zero-trade days, and failed setups as data, not as missing output.

SECTION 11

Timeline

V1

  • What changed: The work started as a first research and strategy layer.
  • Why it changed: Early results were not enough to separate useful signal from system-specific assumptions.
  • Lesson that forced the next generation: A strategy needs evaluation discipline before it earns more complexity.

V2

  • What changed: V2 became the broad momentum scalper.
  • Why it changed: It could capture more movement in mixed or choppy conditions because it used looser filters.
  • Lesson that forced the next generation: More trades can reveal behavior faster, but they also bring more noise.

V3

  • What changed: V3 became the stricter adaptive engine.
  • Why it changed: The system needed tighter filtering and more defensive behavior instead of simply increasing trade count.
  • Lesson that forced the next generation: Low trade count is not failure by itself; it is a sample-size problem that has to be measured over time.

ORB

  • What changed: ORB explored structure-based breakout logic.
  • Why it changed: Not every market condition should be handled by the same engine.
  • Lesson that forced the next generation: A selective strategy should sit out when the structure is not present; zero trades can be valid data.

SECTION 12

Future

The next step is regime-segmented evaluation over a longer window.

The useful question is not which version wins in isolation. It is whether the system can route attention or capital to the engine that fits the day: broad momentum in mixed conditions, stricter defense in weak conditions, and structural breakout logic only when the structure exists.

DLE is the later research layer for preserving that evidence and is presented separately to avoid duplicating its content.