Start4 · Validation & Version 24.2 · Live validation & strategic path
Content status: 24 August 2026Website 2.2.2
OPERATING VALIDATION & STRATEGY

After technical revalidation, real-market execution is intended to create an additional layer of evidence.

The framework's next maturity step is not intended to stop at backtesting. A professional trading and research office is planned to operate a clearly versioned system state under real market conditions. This operating validation must remain separate from product development: it does not replace replication, intraday testing or robustness work; it builds on them.

planned operating stagereal orders and fillstransaction objective and alternatives separated
NEXT OPERATING EVIDENCE LAYER

Reproducible tests are intended to be complemented by real-market execution.

After technical revalidation, a professional trading and research office is planned as an additional validation layer. It is intended to operate a clearly versioned framework state under real conditions. This is meant to connect decision, order, execution, risk and outcome in a traceable way. This live validation remains explicitly separate from backtesting, replication and robustness testing.

THREE DISTINCT LAYERS

Development, live validation and commercialisation serve different purposes.

The distinction matters. Otherwise a successful live period could be mistaken for a substitute for methodological validation, or a future business model could be confused with the product state that exists today.

01

Product and revalidation layer

The Decision Core, execution logic, APS Risk Layer, data, test and documentation architecture are reproduced, extended and tested under defined conditions.

Status

Version 2 is the current development and revalidation programme.

02

Operating validation layer

An approved system version is then intended to be used in a professional trading and research office under real market conditions with end-to-end documentation.

Status

Planned. No institutionally audited live track record of the complete framework is claimed today.

03

Commercialisation layer

Only at this level does the question arise whether the built operating unit is fully acquired, retained and operated, licensed or supplemented by a separate retail product.

Status

Strategic options, not products already offered today or transactions already committed.

TRADING & RESEARCH OFFICE

Its primary function is evidence under real conditions - not building a large trading business for its own sake.

The planned office is intended to be professional enough to connect real decisions, orders, executions and risks to the specific framework version used at the time. This creates a second evidence chain alongside reproducible backtests and validation reports.

1Version

Which approved state of the Decision Core, execution and APS was active?

2Decision

Which rule-based state or action was generated?

3Order

Which real order followed and when was it transmitted?

4Execution

Which actual fills, fees and slippage occurred?

5Risk

Which position size, protection logic and interim stress were present?

6Outcome

How did the real result differ from simulation, reference and expectation?

Important sequence: A live track record should only be treated as meaningful additional evidence once the system version used for it is sufficiently defined, versioned and reproducible. Otherwise it would later be impossible to establish precisely what was actually traded.
WHAT SHOULD BE RECORDED

Live performance is institutionally useful only if its state remains traceable.

An equity curve alone would not be enough. The operating setup is therefore intended to connect technical, trading and risk data for later review.

Order and execution data

  • order timestamps and order types
  • actual fills
  • fees and slippage
  • difference between signal and execution

Risk and path data

  • risk per trade
  • position size and exposure
  • equity and drawdown path
  • MAE/MFE and relevant intermediate states

Version and evidence data

  • framework version used
  • parameter and configuration state
  • comparison with simulation and reference
  • automated performance and risk reports

No premature specification: The exact metrics, account structures and reporting depth for later live operation will only be fixed once the technical and legal design of that phase has been completed.

PREFERRED STRATEGIC OBJECTIVE

The framework is intended to become a transferable operating unit - not a project permanently dependent on its founder.

The preferred target state is a company with six clearly organised areas: technology, IP, documentation, research, operating validation and the related processes. This makes a complete corporate acquisition possible where strategic fit exists.

PRIORITY

Develop → validate → build operating substance → enable complete acquisition

Transaction readiness should not be improvised at the end. Rights, documentation, data provenance, technical handover and organisational processes are therefore intended to be structured from the outset so that an acquirer can review and take over the operating unit.

Deliberately not fixed publicly

This website does not state a binding exit date, purchase price, company valuation or equity percentage. Those issues belong in a qualified financing or transaction process and depend on the maturity level actually demonstrated at that point.

IF NO SUITABLE TRANSACTION EMERGES

Alternative commercialisation paths provide economic optionality - but they are not an equal work programme for the first development phase.

A potential acquirer should not be the only route to economic use. At the same time, it would be inefficient to build product development, a large trading operation, institutional licensing and a retail business at full priority in parallel from day one. The sequence therefore remains explicit.

A

Expand own operation

After successful technical and operating validation, the trading and research office could be used more extensively for proprietary trading and additional real-world evidence.

B

Institutional licensing

Defined modules or usage packages could be licensed to professional users if rights, technology, support and regulatory responsibilities have been clarified.

C

Separate retail product

A simplified analysis and decision-support product for private traders could later be derived from the protected institutional core without exposing the complete Decision Core.

Priority remains unchanged: First make the Decision Core and complete framework technically robust, then build real-market validation and make the operating unit transaction-ready. Alternative business models are developed further only if they become strategically necessary.
POSSIBLE RETAIL LAYER

A future retail product would be a separate product layer - not publication of the institutional core.

A possible retail layer could present general market regimes, long/short bias, risk and volatility states, scenarios, scores or other forms of decision support. Which features would actually be offered remains open today.

Before any such launch, product design, data rights, liability and regulatory classification would require separate review. Automated control of client assets, individual portfolio decisions or comparable regulated services are not presented on this website as existing or already approved product functions.

COREDecision Core + APS + executionproprietary core logic
INSTITUTIONALinterfaces & professional integrationdependent on the later use case
VALIDATIONtrading & research officereal execution and track record
RETAIL · OPTIONALsimplified analysis & decision supportseparate product and legal review
CLASSIFICATION

The new operating strategy does not change today's evidence status.

Version 1 remains a documented research state, Version 2 remains the revalidation programme and live validation remains a planned later evidence layer. Keeping those categories separate prevents strategic ambition from being confused with evidence already delivered.