Data
Historical market data, quality, provenance and, later, exact intraday event ordering.
Core components: OHLCV, provenance and timestamps; Version 1 on end-of-day data, Version 2 with minute/tick data.
Hand-off to Research: versioned data state.
FRAMEWORK
From market data to a controlled decision
The framework separates research, decision logic, execution and risk governance. This makes it possible to see which layer produces a finding, which layer turns it into a concrete trading event and which layer subsequently controls risk.
SYSTEM ARCHITECTURE
Six layers with explicit hand-offs
The separation shows not only where a statement originates, but also which defined output each layer passes to the next. This keeps effects attributable to the layer in which they actually arise.
Research
Consistent tests across markets and oscillators plus synthetic control series for context.
Core components: 60 oscillators, pivot structure, control series and consistent test rules.
Hand-off to Decision Core: documented test finding.
Decision Core
Versioned rules translate market structure and analytical values into reproducible decisions.
Core components: direction, market structure, context, filters and a fixed rule version.
Hand-off to Execution: rule-based decision or permission.
Execution
Entry, target, stop, break-even, trailing, sequence, costs and slippage form a separate layer.
Core components: entry, target, stop, break-even, trailing, intraday order, costs and slippage.
Hand-off to APS: defined execution path.
APS Risk Layer
Position size, protection, warning states, de-escalation and controlled restart of a plan.
Core components: staged position sizing, high-watermark protection, warning/stop states and restart logic.
Hand-off to Evidence: risk state and permitted exposure.
Evidence & Reporting
Data state, rules, test conditions, version history and known limitations remain attached to results.
Core components: versions, test conditions, data provenance, limitations and traceable result paths.
Result: reviewable result and audit trail.
DECISION CORE
Research findings and real-world execution are not treated as the same thing
The Decision Core answers the rule-based question of what decision follows from the available data and rules. Whether that decision remains economically viable after stops, costs and slippage is a separate question and therefore belongs to the execution layer.
This separation protects against a common backtesting error: a high win rate or an attractive winners-to-losers ratio is not yet evidence of a strong monetary profit factor or a realistically achievable return.
Explore the Decision Core →Research, not a black box
Identical data and the same rule version should produce identical results. Changes are handled as new versions rather than hidden adjustments. AI may assist analysis, documentation and user support; it is not intended to rewrite core logic autonomously.
DECISION CORE
The Decision Core applies rules – it does not optimise them after the fact
The Decision Core is the layer in which market structure and analytical values become a concrete rule-based decision. Its objective is not to improve an outcome retrospectively, but to implement a defined rule set clearly enough that the same data and the same rule version produce the same result again.
This makes an important distinction explicit: decision quality is not the same as trading performance. The downstream execution layer determines the realised entry, stop behaviour, intraday ordering and cost assumptions. The risk layer then determines how much capital may be exposed and when an active plan must be reduced or stopped.
01DeterministicIdentical input data and the same rule version should produce the same decision. Differences become investigable rather than hidden.
02VersionedA rule change creates a new version. Results from different rule states are not silently blended.
03ModularSignal, execution and risk remain separate so that the source of an effect can be identified.
04ExplainableA decision is tied to its data, rules, parameters and conditions – the basis for professional review.
FROM DECISION TO EXECUTION
The economic result only emerges after the execution layer
Version 1 models the structural decision on end-of-day data. Version 2 is intended to add the actual order of intraday events. That is where it becomes possible to determine, for example, whether a target or stop was hit first and how trading costs would have affected the theoretical move.
Decision
The Decision Core produces a rule-based direction or permission from the available market and analytical state.
Trading event
The execution layer defines entry, target, stop, break-even and trailing and resolves the actual sequence of market events.
Economic result
Only after costs, slippage, position size and risk governance do profit, loss, profit factor or drawdown become meaningful economic metrics.
APS RISK LAYER
APS does not answer “what should I trade?” – it answers “how much?” and “for how long?”
The Angriffsplan-Strategie (APS) is an independent risk and money-management logic that sits on top of an existing market decision. Its core idea is to scale favourable paths in a controlled manner, protect achieved equity highs and actively de-escalate when conditions deteriorate.
Stage model
Exposure and position size are increased only through defined stages and release conditions.
High-watermark protection
The highest achieved plan equity becomes a dynamic reference for protecting part of the progress already made.
Warning system
The remaining risk buffer is translated into states ranging from information and warning to a mandatory stop.
Tactical governance
A broad rule set defines responses to stress, loss sequences, reduced reserves, pauses and controlled restart.
Development history
The documented APS lineage runs from a risk-manager prototype in 2013 through integrated workbooks and simulations in 2017/2018 to published comparison tests in 2019 and a 16-instrument portfolio version in 2020. That history demonstrates depth of development; it does not replace a clean, isolated revalidation in Version 2.
INTEGRATION
How the framework could later fit into existing institutional infrastructure
The target is not a closed monolithic system. The functional layers are intended to expose clear boundaries so that existing data, order or reporting infrastructure can remain in place. The precise technology stack is therefore an architectural choice rather than a fixed product claim.
Market datainternal or licensed sources
→Decision Corerules, filters, states
→Executionorder and event logic
→APS Risk Layerexposure and governance
→Reporting/APIevidence, transfer, integration
Status: This is the target architecture. Version 1 exists as a transparent research prototype; the production-oriented technical layer remains part of Version 2 development and validation.
NEXT