DEVELOPMENT

Version 2 is intended to test, extend and engineer existing substance.

The development plan begins with controlled replication rather than new features. Intraday execution, costs, APS integration and additional robustness tests are added only afterwards. This sequence is designed to keep the source of each change measurable.

Version 1: documented research stateVersion 2: development and revalidation programme

TODAY

What already exists

The starting point is not an empty concept. There is a broadly tested Excel reference core, a multi-year APS risk-governance system, historical simulations and comparison paths, and extensive domain documentation. What does not exist today is a fully integrated, intraday-realistic production platform.

VERSION 1 · DOCUMENTED

Research & reference core

94 real instruments
60 oscillators
5,640 systematic tests
synthetic control group
daily data 2009–2025

APS · SEPARATELY DOCUMENTED

Risk & equity governance

documented lineage from 2013
stages and high-watermark logic
warning and stop states
tactical rules
historical simulations and comparisons

VERSION 2 · TARGETReproducible product architectureindependent compute core
intraday event logic
costs and slippage
APS integration
forward and stress testing

VALIDATION ORDER

The order matters more than the length of the feature list.

Each step has a clearly defined validation object. This avoids introducing several changes at once and then losing the ability to identify which change improved or degraded the result.

Freeze the reference state

Data, parameters, calculation rules and expected outputs become the unchanged baseline.

Foundation

Data quality & intraday data

Import paths, completeness, timestamps and provenance are checked before finer-grained testing begins.

Data

Replicate Version 1 independently

The existing Decision Core is reimplemented and compared output by output with the reference state.

Replication

Intraday event logic

The actual order of price events is represented instead of inferred from daily bars.

Execution

Stops, break-even, trailing and costs

More realistic protection and execution rules, commissions and slippage are added and measured separately.

Economics

Integrate APS under identical conditions

The incremental contribution of the risk layer is measured against an unchanged comparison path.

Risk

New data & walk-forward testing

Rules are evaluated on data not used for their respective development and in rolling forward windows.

Robustness

Product, API, help and reporting

Interface, integration, help and institutional handover material are completed after the core has stabilised.

Product

WHY INTRADAY?

A daily bar shows high and low – but not necessarily which came first.

If both a target and a stop area are touched on the same trading day, a daily bar alone may not reveal which event occurred first. That ordering can determine whether a hypothetical trade is classified as a win or a loss.

Version 1

Structural decision validation on end-of-day data, useful for cross-market consistency.

Version 2

Intraday data resolves event order so stops, targets, break-even and trailing can be simulated more realistically.

Outcome

Only execution, costs and position sizing allow a more robust statement about the economic path.

AFTER VERSION 2

Technical validation is intended to be followed by real-market execution.

Backtests and forward tests answer different questions from real orders. Once Version 2 is sufficiently defined, a professional trading and research office is therefore planned as an additional evidence layer. The live phase is deliberately positioned after methodological revalidation and is not treated as a substitute for it.

Reference & replication

Preserve the existing logic and reproduce it independently.

Intraday & economics

Test sequence, stops, costs, slippage and APS separately.

New data

Out-of-sample and rolling forward testing.

Live validation

Operate an approved version with real orders, fills, fees, risk and version logs.

Additional evidence, not a shortcut: A positive live period cannot retroactively repair methodological weaknesses. Conversely, a clean backtest cannot fully reproduce real execution conditions. The two layers should therefore remain separately documented and later be assessed together.

DEVELOPMENT LINEAGE

The current architecture emerged from several documented stages.

The timeline distinguishes data history from actual development. The dataset reaches back to 2009; the documented APS system lineage begins with the 2013 risk-manager prototype.

2009–2025

Data history

The historical period used by the current Version 1 reference tests.

2013

Risk-manager prototype

Early forms of high-watermark trailing, trading permission, loss-sequence stops and hierarchical risk control.

2017–2018

Integrated APS

Stages, HWM systems, warning states, drawdown analysis and operational control are brought together.

2019

Publication & comparisons

APS is documented in a three-part TRADERS’ cover series; several historical comparison files date from the same period.

2020

Portfolio extension

The development reaches a centralised 16-instrument portfolio perspective.

2026

Framework & revalidation

Research Core, Decision Core, Execution, APS and documentation are reorganised as separate layers and prepared for independent technical replication.

NO HIDDEN PROMISES

Timelines and technologies are planning assumptions, not guarantees.

Development depends on data quality, architecture choices, resources, licensing, security requirements and the needs of a potential partner. Neither an exact completion date nor a particular technology stack is presented as an immutable product feature.

The validation order is the durable commitment: freeze the reference, reproduce it, measure extensions separately, and only then move toward production-oriented integration.

The technical implementation follows this validation sequence.

Technology Traceability