Axion

• 

  Research. Decide. Execute. A provider-independent operating system for quantitative research, decision-making and execution.

• 

  Research creates knowledge. Knowledge improves decisions. Every execution strengthens the next one.

• 

  A provider-independent architecture where research, runtime and execution share the same canonical foundation.

• 

  Concept UI illustrating Axion's Dataset Store. The underlying storage architecture is fully implemented.

• 

  Concept UI illustrating the future runtime. The event-driven runtime and paper trading engine are already implemented.

• 

  From research platform to continuously improving quantitative decision system across markets, brokers and intelligent models.

• 

  Actual Axion output — ORB trade analysis generated from the backtesting and visualization pipeline.

Inspiration

Most quantitative trading projects begin with a strategy.

Mine started with a different problem: every new strategy seemed to require rebuilding the same infrastructure.

Historical data, features, broker integrations, backtesting tools and execution logic were often developed separately. As the project grew, so did the duplication and technical debt.

I eventually realized that the strategy itself should not be the main reusable asset. The platform around it should be.

That became the starting point for Axion: a provider-independent system where research, decision-making and execution can share the same foundations.

What it does

Axion is a platform for quantitative research, decision-making and execution.

It provides a common architecture for moving from historical analysis toward controlled runtime execution without rebuilding the surrounding infrastructure for every strategy.

The current platform includes:

• standardized market-data models;
• provider-independent data and runtime boundaries;
• historical research and backtesting;
• an event-driven trading runtime;
• deterministic internal paper execution;
• shared models across research and runtime environments.

The goal is simple: make new strategies reuse the platform rather than create another isolated implementation.

How I built it

Axion is built as a layered, event-driven Python application.

External market data is translated into a shared internal format before it reaches research, strategy or execution components. This keeps the core platform independent from a specific broker or data vendor.

The project currently includes a Dataset Store, Feature Store, backtesting tools, an event-driven runtime, risk and decision components, paper execution, position monitoring and automated tests.

One of the main design principles is to keep research and runtime aligned without forcing them to share the same orchestration code.

Challenges I ran into

The hardest part was not implementing a trading strategy. It was deciding where each responsibility should live.

Historical research and live execution have very different operational requirements, but they still need to agree on market data, features, signals and trade definitions.

I also wanted broker and provider integrations to remain replaceable. That required introducing standardized internal models and clear boundaries between adapters, strategies, decisions and execution.

Designing for those boundaries took longer than building the first working path, but it made the project much easier to extend and reason about.

Accomplishments that I'm proud of

Axion began as a collection of research and trading utilities. During the project, it gradually became a coherent platform.

Some of the milestones I am most proud of are:

• building a provider-independent market-data architecture;
• creating shared Dataset and Feature Stores;
• connecting an ORB strategy to an event-driven runtime;
• validating realtime IBKR market-data ingestion;
• implementing deterministic paper execution and risk rejections;
• adding automated tests and a reproducible offline demonstration.

I am also proud that the current documentation clearly separates what already works from what remains on the roadmap.

What I learned

My biggest lesson was that the long-term value of a quantitative platform does not come only from accumulating strategies.

It also comes from preserving what each experiment and execution teaches you: datasets, features, assumptions, decisions, results and failures.

That changed how I thought about Axion.

Instead of treating research outputs as disposable, I began designing the platform around reusable evidence that can support future decisions.

I am not yet at the machine-learning stage of the roadmap, but the architecture is now being built to support it properly.

What's next for Axion

Axion is only at the beginning of its roadmap.

The next priority is execution maturity.

That includes broker-side paper-order routing, fill reconciliation, richer exit handling, position lifecycle validation and better runtime observability.

After that, the roadmap includes:

• reusable knowledge and feature layers;
• strategy ranking;
• portfolio-aware decision-making;
• machine-learning-assisted decisions;
• additional providers and asset classes;
• learning from live execution results.

The long-term objective is not simply to build more strategies. It is to build a better system for deciding which strategy, risk and execution approach should be used in a given situation.

Built With

• api
• architecture
• code
• data
• engineering
• event-driven
• finance
• git
• github
• gpt-5
• ibkr
• learning
• machine
• openai
• parquet
• pytest
• python
• quantitative
• vs