This page gives a deliberately sober view of the public project status. It separates existing research and system substance from the tests that still need to be completed for Version 2. Readers should not have to infer a maturity level from individual figures that the project itself does not yet claim.
A credible assessment starts with boundaries. The public presentation therefore distinguishes existing substance, development objectives and claims that are deliberately not made.
The project already contains a substantial body of rules, tests, historical comparison paths and documentation. At the same time, the exact work that turns a research and reference core into a more production-oriented architecture is still outstanding.
Status should change because substantive validation has been completed, not because new labels have been introduced. The following project phases condense the dependencies for the public status view: some work can proceed in parallel, but its conclusions only become robust once the required reference and execution state is fixed. The technical work packages P0–P7 and the formal validation gates G1–G7 remain separate layers.
The existing calculation logic is reimplemented independently and compared result by result with the documented reference state.
Acceptance criterion: Identical data and the same rule version reproduce the same reference results, or every difference is fully explained and documented.
Intraday ordering, entry, target, stop, break-even and trailing are processed in actual sequence; commissions and slippage are introduced separately.
Acceptance criterion: Event ordering and economic frictions are deterministic and their effects can be reported separately.
The current synthetic control is reproduced and extended with alternative null models so that the comparison does not depend on a single generator family.
Acceptance criterion: Control series and additional null models are reproducibly documented and comparable under identical evaluation rules.
APS is measured against the same trading and execution path without APS while signal and execution conditions remain unchanged.
Acceptance criterion: Differences between baseline and APS variant can be attributed specifically to the risk layer.
Parallel work is possible: Phase 3A and Phase 3B can be pursued independently once a stable reference and execution state exists.
The rules are tested on data and time windows that were not used to develop those same rules.
Acceptance criterion: Results on new data and across successive walk-forward windows are fully versioned and documented without retrospective mixing with development data.
Once the system version is sufficiently defined and reproducible, a professional trading and research office is intended to capture real orders, fills, fees, risk and version data.
Acceptance criterion: The real execution path is continuously traceable; a live track record adds to the preceding evidence but does not replace it.
The development path is described through four deliberately separate views: P0–P7 are technical work packages, G1–G7 are formal acceptance criteria for methodological and technical revalidation, project phases 1–5 condense the status for the public management view, and steps 01–06 in the Executive Overview are only a reader-friendly short form of that path. The mapping below prevents these views from becoming competing roadmaps.
| Project phase | Technical work packages | Formal validation gates | Executive Overview | Classification |
|---|---|---|---|---|
| 1 · Reproduce the reference | P0–P2 | G1–G2 | 01–02 | Freeze the reference state, verify the data basis and reproduce Version 1 independently. |
| 2 · Model execution realistically | P1, P3–P4 | G3–G4 | 03–04 | Model intraday data, event sequence, protection rules, costs and slippage separately. |
| 3A · Statistical robustness | Cross-cutting validation path without its own P number | G5 | 05 · control-group branch | Reproduce the control group and extend it with alternative null models; this is statistical evidence work, not a separate software module. |
| 3B · Isolate APS incremental value | P5 | G6 | 05 · APS branch | Compare identical trading and execution conditions pairwise with and without APS. |
| 4 · New data & walk-forward | P6 | G7 | 06 | Test rules on data not used to develop those rules and across rolling forward windows. |
| Product-oriented follow-on work | P7 | no separate G gate | separate note after 01–06 | Product, API, help and reporting are expanded after the core stabilises. This supports integration and transfer but is not the later live phase. |
| 5 · Real-market execution | no P work package; separate operational layer | outside G1–G7 | separate note after 01–06 | After a sufficiently defined Version 2 state, a separate operational evidence layer follows with real orders, fills, fees, risk and version data. |
After technical revalidation, an operating validation stage is planned: a clearly versioned system state is intended to be used under real market conditions and documented from decision through execution. In parallel, the organisation is intended to structure technology, IP, research, documentation and operating processes so that they can later be reviewed and transferred as a coherent unit.
Build a transaction-ready operating unit and enable complete corporate acquisition where strategic fit exists.
AlternativeIf no suitable transaction emerges, own operation, institutional licensing and a separate retail product remain possible later commercialisation paths.
Live validation & strategy in detail →Python, relational databases, API boundaries or a specific user interface are technical working directions. They are not sold as immutable product properties. What matters is that data, rules, results and versions remain clearly separated and that the calculation logic can be reproduced and tested.
A technical decision counts as progress only when it improves testability, maintainability or integration capability. Changing the programming language alone does not increase methodological maturity.
Versions 0.x.x document the pre-release development of the current website and its public information model. Historical work remains visible as development history, but is not silently equated with the current framework and evidence status. Website 1.0.0 freezes the first fully released public overall state. Subsequent versions document substantive, methodological or technical changes in a traceable manner.
Audience-facing language was revised, metrics were explained more clearly and the English version was added.
Technology, development, documentation, FAQ and visible evidence statuses were expanded.
Project status, glossary and detailed methodological research notes extend the public review layer.
A bilingual Executive Overview, staged information access and a source-based publication history add a public document layer.
Public claims are tied to evidence status, limitations and a concrete next validation step. A separate Evidence & Validation Brief makes that review logic shareable.
Potential institutional perspectives, build-versus-buy framing, staged disclosure, transaction readiness and a one-page Institutional Fact Sheet add the strategic decision layer.
Terminology, metadata, mobile navigation, accessibility, favicons, loading behaviour and technical consistency were reviewed and refined without changing the Framework’s substantive architecture.
The planned trading and research office, live track record, preferred transaction objective and alternative commercialisation paths are classified as distinct later layers without changing today's evidence status.
Historical APS primary publications were integrated as original sources, the six synthetic control series were refined on the basis of their actual generator logic as different trend regimes, and the test matrix was documented transparently as 94 real instruments plus six synthetic control series with 6,000 test combinations in total. The public Framework documents were aligned with this state in content and visual identity.
First fully released overall state of the repositioned Plagge Consulting website. Content architecture, bilingual presentation, source, evidence and documentation structure, legal pages, visual identity and technical implementation are consolidated and form the binding public baseline for all subsequent versions.
The complete public content is reorganised into a numbered manual structure. Existing pages and content remain available but receive explicit chapter and subchapter roles, a visible content date, local chapter navigation, breadcrumbs and a linear previous/next reading path. Reference areas and legal information are separated from the technical chapters. This release freezes the public data and navigation state.
Patch release: the German and English legal pages are synchronised and updated, editorial responsibility is stated more precisely, and the new AI-generated portrait of Andreas Plagge receives a direct disclosure. Architecture, Framework content, research evidence and public technical documents remain substantively unchanged.
Technical patch: the CSP conflict on the profile pages is removed by formatting the portrait disclosure exclusively through an external stylesheet. HSTS with a one-year max-age is added. Legal texts, Framework content, evidence and public technical documents remain unchanged.
Patch release: Chapter 9 is renamed in the visible navigation from “About” to “Profile”, with the German equivalent changed from “Über uns” to “Profil”. Existing URLs, content, legal pages, Framework structure and technical security measures remain unchanged.
Patch release: the existing NinjaTrader® Ecosystem vendor status was first documented on the profile page.
Compliance release: dedicated NinjaTrader® and Kinetick® information pages, preferred platform/brokerage/market-data positioning, permanent Ecosystem risk disclosure, and prominent hypothetical-performance disclosures are integrated. Quantitative Framework PDFs containing simulated results receive an additional compliance cover and result-page reference without altering the underlying research content.
Minor release: a central bilingual legal page consolidates provider information and privacy notices for the business social-media presences as well as WhatsApp, Messenger, SMS, Zoom and Microsoft Teams. The website privacy policy remains concise and links to this external-channel layer.
Minor release: the architecture is condensed without additional image files by adding explicit hand-offs between the six layers and removing the redundant second architecture presentation. The next material proof points are reorganised as a gate-based validation path with acceptance criteria, while the institutional review process makes increasing information depth and confidentiality visible. Typography, core design, legal pages and research PDFs remain unchanged.
Patch release: the full hypothetical-performance disclosure is limited to pages that present specific historical, simulated or backtest-derived performance figures and is rendered once immediately before the relevant result area. General FAQ, documentation, documents, publication-history and research-overview pages no longer present specific performance figures and therefore no longer carry the full-page disclosure. The permanent NinjaTrader® Ecosystem risk disclosure in the footer remains unchanged.
Patch release: the German and English glossaries are expanded from 29 to 48 terms. Additions include the full project name, Framework, Oscillator, Trading Platform, NinjaTrader®, Broker, Market-data feed, OHLC/OHLCV, Futures, Evidence, Audit Trail, Due Diligence, Governance, Reproducibility, Rule Version, Signal, Synthetic Control Series and Test Matrix. Existing technical architecture, evidence, legal pages, performance disclosures, design and downloads remain unchanged.
Minor release: the three previously parallel layers are explicitly separated and mapped to each other: P0–P7 as technical work packages, G1–G7 as formal validation gates, and project phases 1–5 as the condensed public status view including later real-market execution. The staged information-access ladder on the documents page is synchronised with the six-stage master model on the review-process page. Outdated metadata for the public PDFs is corrected against the documents actually delivered; the PDFs themselves, quantitative evidence, legal pages, visual design and performance disclosures remain unchanged.
Hotfix after direct review of the PDF files: the six-step 01–06 short view in the Executive Overview is explicitly mapped to P0–P7, G1–G7 and the project phases and can no longer be read as a separate roadmap. The Executive Overview is reissued as document Version 1.3 and now uses the same six-stage 0–5 review model as the website. The actual PDF lengths of both the Executive Overview and Evidence & Validation Brief are also corrected to ten pages. The Evidence Brief, Fact Sheet, quantitative evidence, legal pages and performance disclosures remain substantively unchanged.
The public state refines the separation between proprietary Framework IP and externally licensed market data and other third-party rights. For validation reports, rights and disclosure status are now treated as a dedicated part of the evidence chain, while confidentiality and data rights are handled separately. The public evidence presentation has also been focused more strongly on research scope, methodology, validation status and reproducibility. Historical detail metrics remain part of the versioned internal research record. Static version labels on individual pages were also aligned with the current website state.
Patch release: the public development history gains a clearly separated methodological prehistory before 2013. At the same time, the principle-based development approach already used in the project is stated explicitly: system logic and qualitative solution principles precede parameter fine-tuning. The existing APS source chain from 2013 onward, the data-rights and provenance logic introduced in 2.4.0, technical architecture, evidence logic, public metrics policy, downloads and legal pages remain unchanged.
Technical patch release: the public contact address is changed to andreas@itdrf.com and the website is prepared for the transition of the primary domain to itdrf.com. Technical content, project status, evidence, downloads, design and legal responsibility remain unchanged.
Technical patch release: itdrf.com is set as the canonical primary domain of the website. The .htaccess configuration is aligned with the domain redirects configured at IONOS and now enforces only HTTPS within the directly assigned webspace together with the existing security and URL rules. The public content status remains 20 September 2026.
