Diese Seite fasst den öffentlichen Projektstand bewusst nüchtern zusammen. Sie unterscheidet vorhandene Forschungs- und Systemsubstanz von den Prüfungen, die für Version 2 noch ausstehen. Dadurch soll ein Leser nicht aus einzelnen Kennzahlen auf einen Reifegrad schließen müssen, den das Projekt selbst noch nicht beansprucht.
Eine belastbare Einordnung beginnt mit den Grenzen. Der öffentliche Auftritt trennt deshalb vorhandene Substanz, Entwicklungsziele und Aussagen, die bewusst nicht getroffen werden.
Das Projekt besitzt bereits einen erheblichen Bestand an Regeln, Testreihen, historischen Vergleichspfaden und Dokumentation. Gleichzeitig fehlen noch genau die Prüfungen, die aus einem Forschungs- und Referenzkern eine belastbarere produktionsnahe Architektur machen.
Ein Statuswechsel soll durch bestandene Prüfungen entstehen, nicht durch neue Bezeichnungen. Die folgenden Projektphasen verdichten die fachlichen Abhängigkeiten für die öffentliche Statussicht: einzelne Arbeiten können technisch parallel laufen, aber ihre Aussagen werden erst belastbar, wenn der benötigte Referenz- und Ausführungsstand feststeht. Die technischen Arbeitspakete P0–P7 und die formalen Validierungstore G1–G7 bleiben davon getrennte Ebenen.
Die bestehende Rechenlogik wird unabhängig neu implementiert und Ergebnis für Ergebnis gegen den dokumentierten Referenzstand verglichen.
Abnahmekriterium: Identische Daten und dieselbe Regelversion erzeugen dieselben Referenzergebnisse – oder jede Abweichung ist vollständig erklärt und dokumentiert.
Intraday-Reihenfolge, Einstieg, Ziel, Stop, Break-even und Trailing werden zeitlich korrekt verarbeitet; Kommissionen und Slippage werden getrennt einbezogen.
Abnahmekriterium: Ereignisreihenfolge und ökonomische Reibungen sind deterministisch abgebildet und ihre Auswirkungen separat ausweisbar.
Die heutige synthetische Kontrollgruppe wird reproduziert und um alternative Nullmodelle ergänzt, damit der Vergleich nicht von nur einer Generatorfamilie abhängt.
Abnahmekriterium: Kontrollreihen und zusätzliche Nullmodelle sind reproduzierbar dokumentiert und unter identischen Bewertungsregeln vergleichbar.
APS wird gegen denselben Handels- und Execution-Pfad ohne APS gemessen. Signal- und Ausführungsbedingungen bleiben dabei unverändert.
Abnahmekriterium: Unterschiede zwischen Baseline und APS-Variante lassen sich der Risikoschicht isoliert zurechnen.
Parallel möglich: Phase 3A und Phase 3B können nach einem stabilen Referenz- und Execution-Stand unabhängig voneinander bearbeitet werden.
Die Regeln werden auf Daten und Zeitfenstern geprüft, die nicht zur Entwicklung derselben Regeln verwendet wurden.
Abnahmekriterium: Ergebnisse auf neuen Daten und über fortlaufende Walk-forward-Fenster sind vollständig versioniert und ohne nachträgliche Vermischung mit Entwicklungsdaten dokumentiert.
Nach einer ausreichend definierten und reproduzierbaren Systemversion soll ein professionelles Handels- und Forschungsbüro reale Orders, Fills, Gebühren, Risiko- und Versionsdaten erfassen.
Abnahmekriterium: Der reale Ausführungspfad ist durchgängig nachvollziehbar; ein Live-Track-Record ergänzt die vorherigen Prüfungen, ersetzt sie aber nicht.
Der Entwicklungsweg wird in vier bewusst getrennten Sichten beschrieben: P0–P7 sind technische Arbeitspakete, G1–G7 formale Abnahmekriterien der methodischen und technischen Revalidierung, die Projektphasen 1–5 verdichten den Status für die öffentliche Managementsicht, und die Schritte 01–06 im Executive Overview sind ausschließlich eine leserfreundliche Kurzfassung dieses Pfads. Die folgende Zuordnung verhindert, dass daraus konkurrierende Roadmaps werden.
| Projektphase | Technische Arbeitspakete | Formale Validierungstore | Executive Overview | Einordnung |
|---|---|---|---|---|
| 1 · Referenz reproduzieren | P0–P2 | G1–G2 | 01–02 | Referenzstand sichern, Datenbasis prüfen und Version 1 unabhängig reproduzieren. |
| 2 · Execution realistisch abbilden | P1, P3–P4 | G3–G4 | 03–04 | Intraday-Daten, Ereignisreihenfolge, Schutzregeln, Kosten und Slippage getrennt abbilden. |
| 3A · Statistische Robustheit | Querschnittlicher Prüfpfad ohne eigene P-Nummer | G5 | 05 · Kontrollgruppen-Zweig | Kontrollgruppe reproduzieren und um alternative Nullmodelle erweitern; dies ist statistische Beweisarbeit, kein eigenes Softwaremodul. |
| 3B · APS-Zusatznutzen isolieren | P5 | G6 | 05 · APS-Zweig | Identische Handels- und Ausführungsbedingungen mit und ohne APS paarweise vergleichen. |
| 4 · Neue Daten & Walk-forward | P6 | G7 | 06 | Regeln auf nicht zur Entwicklung verwendeten Daten und in fortlaufenden Vorwärtsfenstern prüfen. |
| Produktorientierte Anschlussarbeit | P7 | kein eigenes G-Tor | separater Hinweis nach 01–06 | Produkt, API, Hilfe und Reporting werden nach Stabilisierung des Kerns ausgebaut. Diese Arbeit unterstützt Integration und Übergabe, ist aber nicht mit der späteren Live-Phase gleichzusetzen. |
| 5 · Reale Marktausführung | kein P-Arbeitspaket; separate operative Ebene | außerhalb G1–G7 | separater Hinweis nach 01–06 | Nach einem ausreichend definierten Version-2-Stand folgt eine getrennte operative Beweisebene mit realen Orders, Fills, Gebühren, Risiko- und Versionsdaten. |
Nach der technischen Revalidierung ist eine operative Validierungsstufe vorgesehen: Eine klar versionierte Ausbaustufe soll unter realen Marktbedingungen eingesetzt und von Entscheidung bis Ausführung dokumentiert werden. Parallel wird die Organisation so gedacht, dass Technologie, IP, Research, Dokumentation und Betriebsprozesse später als zusammenhängende Einheit geprüft und übertragen werden können.
Transaktionsfähige Einheit aufbauen und bei strategischer Passung eine vollständige Unternehmensübernahme ermöglichen.
AlternativeFalls keine passende Transaktion entsteht, bleiben Eigenbetrieb, institutionelle Lizenzierung und ein separates Endkundenprodukt als spätere Verwertungswege offen.
Live-Validierung & Strategie im Detail →Python, relationale Datenbanken, API-Grenzen oder eine konkrete Benutzeroberfläche sind technische Arbeitsrichtungen. Sie werden nicht als unveränderliche Produkteigenschaft verkauft. Entscheidend ist, dass Daten, Regeln, Ergebnisse und Versionen nachvollziehbar getrennt bleiben und die Rechenlogik reproduzierbar getestet werden kann.
Eine technische Entscheidung gilt erst dann als Fortschritt, wenn sie die Prüfbarkeit, Wartbarkeit oder Integrationsfähigkeit verbessert. Ein Wechsel der Programmiersprache allein erhöht den fachlichen Reifegrad nicht.
Die Versionen 0.x.x dokumentieren die Vorentwicklung der heutigen Website und des öffentlichen Informationsmodells. Historische Arbeiten bleiben als Entwicklungsgeschichte sichtbar, werden jedoch nicht stillschweigend mit dem aktuellen Framework- und Nachweisstand gleichgesetzt. Mit Website 1.0.0 wird der erste vollständig freigegebene öffentliche Gesamtstand eingefroren. Nachfolgende Versionen dokumentieren nachvollziehbar inhaltliche, methodische oder technische Änderungen.
Publikumssprache bereinigt, Kennzahlen verständlicher erklärt und die englische Fassung ergänzt.
Technologie, Entwicklung, Dokumentation, FAQ und sichtbare Nachweisstatus wurden ausgebaut.
Projektstatus, Glossar und ausführliche methodische Fachbeiträge ergänzen die öffentliche Prüfebene.
Zweisprachiges Executive Overview, gestaffelte Informationsfreigabe und quellenorientierte Publikationshistorie ergänzen die öffentliche Dokumentenebene.
Öffentliche Aussagen werden mit Belegstatus, Aussagegrenze und konkretem nächstem Validierungsschritt verbunden. Ein separates Evidence & Validation Brief macht diese Prüflogik weitergabefähig.
Mögliche Erwerberperspektiven, die Abwägung zwischen Eigenentwicklung und Übernahme, gestufte Informationsfreigabe, Transaktionsfähigkeit und ein einseitiges Institutional Fact Sheet ergänzen die strategische Entscheidungsebene.
Terminologie, Metadaten, mobile Navigation, Barrierefreiheit, Favicons, Ladeverhalten und technische Konsistenz wurden abschließend geprüft und bereinigt.
Geplantes Handels- und Forschungsbüro, Live-Track-Record, bevorzugtes Transaktionsziel und alternative Verwertungswege werden als getrennte spätere Ebenen eingeordnet, ohne den heutigen Nachweisstatus zu verändern.
Historische APS-Primärpublikationen wurden als Originalquellen integriert, die sechs synthetischen Kontrollreihen anhand ihrer tatsächlichen Generatorlogik als unterschiedliche Trendregime präzisiert und die Testmatrix transparent als 94 reale Instrumente plus sechs synthetische Kontrollreihen mit insgesamt 6.000 Testkombinationen dokumentiert. Die öffentlichen Framework-Unterlagen wurden inhaltlich und gestalterisch auf diesen Stand abgestimmt.
Erster vollständig freigegebener Gesamtstand der neu positionierten Website von Plagge Consulting. Inhaltliche Architektur, zweisprachige Darstellung, Quellen-, Nachweis- und Dokumentationsstruktur, rechtliche Seiten, Markenauftritt sowie technische Umsetzung sind konsolidiert und bilden die verbindliche öffentliche Ausgangsbasis für alle folgenden Versionen.
Der vollständige öffentliche Inhalt wird in eine nummerierte Manual-Struktur überführt. Bestehende Seiten und Inhalte bleiben erhalten, erhalten jedoch eindeutige Kapitel- und Unterkapitelrollen, einen sichtbaren Datenstand, lokale Kapitelnavigation, Breadcrumbs sowie einen linearen Vor-/Zurück-Lesepfad. Referenzbereiche und Rechtliches werden von den fachlichen Kapiteln getrennt. Dieser Stand friert den öffentlichen Daten- und Navigationsstand ein.
Patch-Release: deutsche und englische Rechtsfassungen werden synchronisiert und aktualisiert, die redaktionelle Verantwortung wird präzisiert und das neue KI-generierte Porträt von Andreas Plagge direkt gekennzeichnet. Architektur, Framework-Inhalte, Research-Evidenz und öffentliche Fachunterlagen bleiben fachlich unverändert.
Technischer Patch: der CSP-Konflikt auf den Profilseiten wird beseitigt, indem die Porträt-Kennzeichnung ausschließlich über ein externes Stylesheet formatiert wird. Zusätzlich wird HSTS mit einer Laufzeit von einem Jahr gesetzt. Rechtstexte, Framework-Inhalte, Evidenz und öffentliche Fachunterlagen bleiben unverändert.
Patch-Release: Kapitel 9 wird in der sichtbaren deutschen Navigation von „Über uns“ zu „Profil“ und in der englischen Fassung von „About“ zu „Profile“ präzisiert. Die bestehenden URLs, Inhalte, Rechtsseiten, Framework-Struktur und technischen Sicherheitsmaßnahmen bleiben unverändert.
Patch-Release: Der bestehende NinjaTrader®-Ecosystem-Vendor-Status wurde erstmals auf der Profilseite dokumentiert.
Compliance-Release: eigene NinjaTrader®-/Kinetick®-Informationsseite, bevorzugte Plattform-/Brokerage-/Marktdatenpositionierung, permanenter Ecosystem-Risikohinweis und prominente Hypothetical-Performance-Hinweise werden integriert. Quantitative Framework-PDFs mit simulierten Ergebnissen erhalten einen zusätzlichen Compliance-Vorspann und Ergebnisverweis, ohne die zugrunde liegenden Research-Inhalte umzudeuten.
Minor Release: Eine zentrale, zweisprachige Rechtsseite bündelt Anbieterkennzeichnung und Datenschutzhinweise für die geschäftlichen Social-Media-Präsenzen sowie WhatsApp, Messenger, SMS, Zoom und Microsoft Teams. Die Website-Datenschutzerklärung bleibt schlank und verweist ergänzend auf diese externe Kanalebene.
Minor Release: Die Architektur wird ohne zusätzliche Bilddateien um explizite Übergaben zwischen den sechs Ebenen verdichtet; die redundante zweite Architekturdarstellung entfällt. Die nächsten materiellen Nachweise werden als Gate-basierter Validierungspfad mit Abnahmekriterien strukturiert, und der institutionelle Prüfprozess macht die zunehmende Informationstiefe sowie Vertraulichkeit sichtbar. Typografie, Grunddesign, Rechtsseiten und Research-PDFs bleiben unverändert.
Patch-Release: Der vollständige Hypothetical-Performance-Disclaimer wird auf die Seiten mit konkreten historischen, simulierten oder backtestbasierten Ergebnisangaben konzentriert und dort unmittelbar vor dem relevanten Ergebnisbereich nur einmal ausgegeben. Allgemeine FAQ-, Dokumentations-, Unterlagen-, Publikations- und Forschungsübersichtsseiten zeigen keine spezifischen Performancewerte mehr und benötigen deshalb keinen seitenfüllenden Hinweis. Der permanente NinjaTrader®-Ecosystem-Risikohinweis im Footer bleibt unverändert bestehen.
Patch-Release: Das deutsch-englische Glossar wird von 29 auf 48 Begriffe erweitert. Ergänzt werden insbesondere der vollständige Projektname, Framework, Oszillator, Handelsplattform, NinjaTrader®, Broker, Marktdatenfeed, OHLC/OHLCV, Futures, Evidenz, Audit Trail, Due Diligence, Governance, Reproduzierbarkeit, Regelversion, Signal, synthetische Kontrollreihen und Testmatrix. Bestehende Facharchitektur, Evidenz, Rechtsseiten, Performance-Hinweise, Gestaltung und Downloads bleiben unverändert.
Minor Release: Die drei bisher parallel dargestellten Ebenen werden eindeutig getrennt und miteinander verknüpft: P0–P7 als technische Arbeitspakete, G1–G7 als formale Validierungstore und die Projektphasen 1–5 als verdichtete Statussicht einschließlich der späteren realen Marktausführung. Der gestufte Informationszugang auf der Unterlagenseite wird auf das sechsstufige Mastermodell des Prüfprozesses synchronisiert. Veraltete Metadaten der öffentlichen PDFs werden gegen die tatsächlich ausgelieferten Dokumentstände korrigiert; die PDFs selbst, quantitative Evidenz, Rechtsseiten, Gestaltung und Performance-Hinweise bleiben unverändert.
Hotfix nach direkter Prüfung der PDF-Dateien: Die sechsschrittige Kurzsicht 01–06 des Executive Overview wird ausdrücklich auf P0–P7, G1–G7 und die Projektphasen abgebildet und nicht mehr als eigenständige Roadmap lesbar. Das Executive Overview wird als Dokumentversion 1.3 neu ausgespielt und verwendet nun dasselbe sechsstufige Prüfmodell 0–5 wie die Website. Gleichzeitig werden die tatsächlichen PDF-Seitenumfänge von Executive Overview und Evidence & Validation Brief mit jeweils zehn Seiten korrekt ausgewiesen. Evidence Brief, Fact Sheet, quantitative Evidenz, Rechtsseiten und Performance-Hinweise bleiben fachlich unverändert.
Der öffentliche Stand präzisiert die Trennung zwischen eigenem Framework-IP und extern lizenzierten Marktdaten sowie sonstigen Drittrechten. Für Prüfberichte wird der Rechte- und Offenlegungsstatus künftig als eigener Bestandteil der Nachweiskette geführt; Vertraulichkeit und Datenrechte werden dabei getrennt behandelt. Die öffentliche Evidenzdarstellung wurde zugleich stärker auf Forschungsumfang, Methodik, Validierungsstatus und Reproduzierbarkeit fokussiert. Historische Detailkennzahlen bleiben Bestandteil des versionierten internen Forschungsbestands. Zusätzlich wurden statische Versionsstände einzelner Seiten auf den gemeinsamen Website-Stand vereinheitlicht.
Patch-Release: Die öffentliche Entwicklungsgeschichte erhält eine klar abgegrenzte methodische Vorgeschichte vor 2013. Gleichzeitig wird der bereits verwendete prinzipienbasierte Entwicklungsansatz ausdrücklich benannt: Systemlogik und qualitative Lösungsprinzipien gehen der Parameter-Feinsteuerung voraus. Die bestehende APS-Quellenkette ab 2013, die Datenrechte-/Provenienzlogik aus 2.4.0, Facharchitektur, Evidenzlogik, Kennzahlenpolitik, Downloads und Rechtseiten bleiben unverändert.
Technischer Patch-Release: Die öffentliche Kontaktadresse wird auf andreas@itdrf.com umgestellt und die Website für den Wechsel der Hauptdomain auf itdrf.com vorbereitet. Fachinhalte, Projektstand, Evidenz, Downloads, Gestaltung und rechtliche Verantwortlichkeit bleiben unverändert.
Technischer Patch-Release: itdrf.com wird als kanonische Hauptdomain des Webauftritts gesetzt. Die .htaccess wird an die bei IONOS eingerichteten Domain-Weiterleitungen angepasst und erzwingt innerhalb des direkt zugewiesenen Webspace nur noch HTTPS sowie die bestehenden Sicherheits- und URL-Regeln. Der inhaltliche öffentliche Stand bleibt der 20.09.2026.
