Ein Handelssystem zu entwickeln, das Marktinformationen nicht nur beobachtet, sondern daraus selbstständig kontrollierte Entscheidungen ableiten kann.
DIE ERSTEN GENERATIONEN
AUS IDEEN WERDEN SYSTEME
EULE→WINSTON→GERDV4→LOVE RAKETE
Jede Generation brachte neue Erfahrungen. Nicht jede Idee blieb bestehen – aber jede lieferte Erkenntnisse für den nächsten Schritt.
DIE ENTWICKLUNG WIRD REIFER
ERNST & WERNER
↓
MINUTETRADER US-MASTER
Die Anforderungen wurden klarer: mehr Automatisierung, bessere Entscheidungsqualität und ein System, das nicht einfach nur Signale ausführt.
DIE ENTSCHEIDENDE ERKENNTNIS
KLASSISCHE REGELN WAREN NICHT GENUG.
MARKTRISIKOENTSCHEIDUNGDATENAI
Aus einzelnen Regeln musste ein zusammenhängender Entscheidungsprozess entstehen.
DER NÄCHSTE SCHRITT
DIE QUANT-PHASE
Die ersten Trading-Systeme hatten ihre Aufgabe erfüllt. Jetzt begann der Übergang zu einer systematischeren Architektur.
KAPITEL 02 ORION QUANT → MARS AI QUANT
KAPITEL 02
Q
30. MAI 2026
ORION QUANT
Die Entwicklung verlagerte sich von einzelnen Handelsregeln hin zu einer strukturierteren, systematischen Trading Engine.
STRUKTUR STATT EINZELREGEL
03. JUNI 2026
MARS AI QUANT
QUANT+AI=INTELLIGENTE BEWERTUNG
Quantitative Handelslogik und künstliche Intelligenz rückten erstmals sichtbar zusammen. Die Bewertung einer Handelsentscheidung wurde wichtiger als ein einzelnes Signal.
13. JUNI 2026
MARS v2.000
MARKTDATEN
ANALYSE
ENTSCHEIDUNG
RISIKO
Die Architektur wurde weiter konsolidiert. Automatisierung, Entscheidungsqualität und kontrollierte Handelsausführung rückten enger zusammen.
15. JUNI 2026
MARS EXECUTOR v3.000
ANALYSE→ENTSCHEIDUNG→ORDER→POSITION
Eine gute Entscheidung allein reicht nicht. Sie muss kontrolliert in eine reale Order übersetzt und anschließend verwaltet werden.
Aus einem vorhandenen Signal wurde eine Qualitätsentscheidung. Erst wenn mehrere Bereiche gemeinsam überzeugten, durfte aus einem Signal ein handelbares Setup werden.
ZENITH AI v2.000 COMPACT
VOM EA ZUM SYSTEM
TRADING ENGINE
+
AI
+
RISK
+
SERVER
Die wachsende Intelligenz musste beherrschbar bleiben. ZENITH entwickelte sich zunehmend vom einzelnen Expert Advisor zu einem vernetzten Gesamtsystem.
KAPITEL 04 AI & TRADING INTELLIGENCE
KAPITEL 04
AI & TRADING INTELLIGENCE
WIE ZENITH AUS MARKTDATEN EINE ENTSCHEIDUNG ERZEUGT
MARKT→TECHNIK→AI→QUALITY→ENTSCHEIDUNG
ZENITH handelt nicht aufgrund eines einzelnen Signals. Eine mögliche Position durchläuft mehrere voneinander getrennte Bewertungsstufen.
1 — MARKTDATEN & TECHNISCHE INTELLIGENCE
DER MARKT LIEFERT DIE ROHDATEN
EMATrendrichtung
ATRVolatilität
ADXTrendstärke
RSIMomentum
MACDRichtung & Dynamik
Mehrere technische Informationsquellen erzeugen gemeinsam einen Marktkontext. Sie können eine BUY- oder SELL-Idee bestätigen, abschwächen oder vollständig ablehnen.
2 — EXTERNE AI-BEWERTUNG
DIE AI IST EIN TEIL DER ENTSCHEIDUNG
MT5 / ZENITH EA
MARKTMERKMALE →
AI
← RICHTUNG + CONFIDENCE + SCORE
ENTRY AUTHORITY
Der Expert Advisor übermittelt ausgewählte Marktmerkmale an die externe AI-Infrastruktur. Die AI liefert eine Bewertung zurück — aber sie besitzt nicht automatisch die alleinige Kontrolle über eine Order.
Erst die Kombination mehrerer Informationsbereiche entscheidet, ob ein vorhandenes Signal tatsächlich die erforderliche Qualität für einen Einstieg erreicht.
4 — ENTRY AUTHORITY
DIE LETZTE FRAGE VOR DER ORDER:
AI SIGNAL BUY
+
TECHNIK BESTÄTIGT?
+
QUALITY GENUG?
=
APPROVED YES / NO
Selbst ein AI-Signal mit sehr hoher Confidence kann abgelehnt werden, wenn technische Bestätigung oder Gesamtqualität nicht ausreichen.
5 — RISK & EXECUTION
EINE ENTSCHEIDUNG WIRD ZUR POSITION
ENTRY FREIGABE→RISIKO→SL / TP→ORDER→POSITION
Nach der Freigabe wird die Entscheidung kontrolliert umgesetzt. Mechanische Schutzmechanismen wie Stop-Loss und Take-Profit bleiben unabhängig von der intelligenten Entscheidungslogik erhalten.
6 — EXIT INTELLIGENCE
DER TRADE WIRD AUCH NACH DEM ENTRY WEITER GEDACHT
MARKTRAUSCHEN?AI-GEGENSIGNAL?TECHNISCHE INVALIDIERUNG?RISIKO?HALTEN ODER SCHLIESSEN?
ZENITH versucht zu unterscheiden, ob eine kurzfristige Gegenbewegung nur Marktrauschen ist oder ob die ursprüngliche Handelsannahme tatsächlich nicht mehr gültig ist.
Ein neuer Einstieg in dieselbe Richtung soll nicht bloß dieselbe bereits gescheiterte Entscheidung wiederholen. Neue Marktinformation und zusätzliche Bestätigung werden erforderlich.
Damit wird ZENITH nicht als einzelner Indikator oder Signalgeber verstanden, sondern als mehrstufiger Entscheidungsprozess.
KAPITEL 05 ENTERPRISE INFRASTRUKTUR
KAPITEL 05
ENTERPRISE INFRASTRUKTUR
AUS EINEM EA WIRD EIN VERNETZTES SYSTEM
MT5→VPS→API→AI SERVER→RUNTIME→DASHBOARD
Der Expert Advisor blieb der Trading-Kern. Rund um ihn entstand jedoch Schritt für Schritt eine externe Infrastruktur für AI, Überwachung, Kommunikation und Betrieb.
1 — METATRADER 5
DER TRADING-KERN
MARKTDATENPreis & Kerzen
ANALYSETechnische Bewertung
ORDERExecution
POSITIONManagement
Im MetaTrader trifft der Markt auf die ZENITH-Logik. Hier werden Entscheidungen vorbereitet, Positionen eröffnet und Trades verwaltet.
2 — METAQUOTES VPS
AUTONOMER BETRIEB 24/7
LOCAL PC
⟶ MIGRATION ⟶
METAQUOTES VPS
Der produktive ZENITH-EA kann auf MetaTrader Virtual Hosting betrieben werden. Dadurch bleibt der Trading-Prozess von einem dauerhaft eingeschalteten lokalen Rechner unabhängig.
3 — API & AI SERVER
DIE VERBINDUNGSSCHICHT
ZENITH EA
↔
API
↔
AI SERVER
Die API verbindet MetaTrader mit externer Intelligenz. Marktmerkmale können an den AI-Server übertragen und Bewertungen anschließend in den Entscheidungsprozess zurückgeführt werden.
4 — RUNTIME MONITORING
DAS SYSTEM WIRD SICHTBAR
AI STATUSPOSITIONENORDERSCONNECTIONHEALTHEVENTS
Runtime-Komponenten machen aktuelle Zustände außerhalb von MetaTrader sichtbar. Dadurch kann erkannt werden, ob AI, Server, Trading und weitere Dienste miteinander verbunden sind.
5 — ENTERPRISE DASHBOARD
EIN ZENTRALER KONTROLLPUNKT
TRADING STATUS
AI STATUS
RUNTIME
DIAGNOSTICS
ACCOUNT
COMMUNICATION
Das Enterprise Dashboard fasst Informationen aus unterschiedlichen Backend-Komponenten zusammen und macht komplexe Systemzustände leichter verständlich.
6 — MULTI-SYMBOL & PORTFOLIO
ARCHITEKTUR FÜR WACHSTUM
SYMBOL PROFILESETUP ENGINEPORTFOLIO RISKEXECUTION SCHEDULERCAPITAL ALLOCATION
Mit dem Enterprise-Ausbau entstanden Komponenten für Symbolprofile, Portfolio-Intelligence, Risikokontrolle und Execution Scheduling. ZENITH wurde damit als erweiterbare Plattform gedacht.
DAS GESAMTSYSTEM
TRADING-KERN + INFRASTRUKTUR = ZENITH PLATFORM
ZENITH EA
AI SERVERAPIRUNTIMEDASHBOARDLEARNINGCOMMUNICATION
Der EA handelt. Die AI bewertet. Die API verbindet. Die Runtime überwacht. Das Dashboard visualisiert. Weitere Komponenten analysieren und kommunizieren.
KAPITEL 06 LEARNING, TRADE DNA & FORENSIK
KAPITEL 06
LEARNING, TRADE DNA & FORENSIK
EIN TRADE ENDET NICHT MIT DEM EXIT
ENTRY→TRADE→EXIT→ANALYSE
Für ZENITH ist nicht nur wichtig, ob ein Trade gewonnen oder verloren wurde. Entscheidend ist auch, was zwischen Entry und Exit tatsächlich passiert ist.
Aus Marktbedingungen, AI-Bewertungen, technischen Merkmalen und dem späteren Ergebnis entsteht eine strukturierte Trade DNA.
2 — OUTCOME ANALYSE
WAS WAR BEIM ENTRY RICHTIG ODER FALSCH?
ENTRYWas wusste ZENITH?
↔
OUTCOMEWas geschah wirklich?
Nach Abschluss des Trades kann das reale Ergebnis mit der ursprünglichen Entscheidung verglichen werden. Dadurch werden wiederkehrende Muster sichtbar.
3 — MFE & MAE
DAS ENDERGEBNIS ERZÄHLT NICHT DIE GANZE GESCHICHTE
MFEMAXIMUM FAVORABLE EXCURSIONWie weit lief der Trade maximal in die profitable Richtung?
MAEMAXIMUM ADVERSE EXCURSIONWie weit bewegte sich der Trade maximal gegen die Position?
Ein Verlusttrade kann zwischenzeitlich deutlich im Gewinn gewesen sein. Ein Gewinner kann zuvor eine starke Gegenbewegung durchlaufen haben. MFE und MAE machen diese Information sichtbar.
Logs und Forensikdaten ermöglichen eine nachträgliche Untersuchung des realen Handelsablaufs. Entscheidungen sollen nicht vermutet, sondern anhand vorhandener Daten rekonstruiert werden.
5 — FEATURE ENGINEERING
AUS ROHDATEN WERDEN LERNMERKMALE
TRADE DATA→MARKTMERKMALE→FEATURES→DATASET
Richtung, Scores, technische Indikatoren, Momentum, Trendabstände und weitere Informationen können für statistische Analyse und experimentelles Machine Learning strukturiert werden.
Experimentelle Modelle können trainiert und getestet werden, ohne automatisch die produktive Handelsentscheidung zu verändern. Erst eine belastbare Validierung könnte später eine Promotion rechtfertigen.
Der langfristige Gedanke ist ein kontrollierter Lernkreislauf. Nicht jedes Modell wird produktiv. Learning muss zuerst beweisen, dass es einen messbaren Vorteil liefert.
DIE WICHTIGE ABGRENZUNG
TECHNOLOGIE IST NICHT AUTOMATISCH PERFORMANCE
VORHANDENTrade DNA Forensik Datasets Shadow Learning
≠
BEWIESENNachhaltiger Live-Vorteil muss validiert werden
ZENITH trennt bewusst zwischen vorhandener Learning-Technologie und tatsächlich nachgewiesener Verbesserung im Live-Trading.
KAPITEL 07 DASHBOARD, WHATSAPP & KOMMUNIKATION
KAPITEL 07
DASHBOARD, WHATSAPP & KOMMUNIKATION
DIE UNSICHTBARE INFRASTRUKTUR WIRD SICHTBAR
BACKEND→RUNTIME→EVENTS→BENUTZER
AI-Anfragen, Trading-Entscheidungen, Serverdienste und Trade-Ereignisse laufen im Hintergrund. Dashboard und Kommunikationskanäle machen diese Prozesse für Menschen nachvollziehbar.
Das ZENITH Enterprise Dashboard bündelt wichtige Informationen aus mehreren Backend-Komponenten an einem zentralen Ort.
2 — LIVE RUNTIME
NICHT NUR ANZEIGEN — LIVE VERBINDEN
EA→SERVER→RUNTIME STORE→DASHBOARD
Runtime-Daten verbinden den aktuellen Systemzustand mit der Oberfläche. Dadurch kann sichtbar werden, ob ZENITH arbeitet, welche Komponenten online sind und welche Ereignisse zuletzt stattgefunden haben.
3 — TRADING MONITORING
DER BETREIBER MUSS SCHNELL ERKENNEN: WAS PASSIERT?
POSITIONENOffene Trades
AIDecision & Confidence
SERVEROnline / Offline
RUNTIMEAktueller Zustand
HEALTHSystemprüfung
EVENTSWas geschah zuletzt?
Komplexe technische Prozesse werden in einen verständlicheren operativen Überblick übersetzt.
Trade-Eröffnungen, Trade-Abschlüsse sowie Gewinn- oder Verlustinformationen können über eine externe Kommunikationspipeline weitergegeben werden.
5 — EVENT PIPELINE
HINTER EINER NACHRICHT STEHT EINE TECHNISCHE KETTE
TRADE EVENT→API→QUEUE→MESSAGE ENGINE→WHATSAPP
Ein Trading-Ereignis wird übernommen, verarbeitet, protokolliert und an den Kommunikationskanal weitergereicht. Dadurch bleibt der Versand Teil einer nachvollziehbaren Pipeline.
6 — WEBSITE CONTACT GATEWAY
AUCH DIE WEBSITE WIRD TEIL DER PLATTFORM
WEBSITE→CONTACT API→GATEWAY→COMMUNICATION
Mit der Contact-Gateway-Infrastruktur entstand eine weitere Verbindung zwischen ZENITH, Website und externen Kommunikationswegen.
7 — HEALTH & RECOVERY
ONLINE SEIN REICHT NICHT — DER ZUSTAND MUSS ÜBERWACHT WERDEN
CONTACT GATEWAYONLINE
WHATSAPP GATEWAYONLINE
RUNTIMEOK
QUEUE0
ERRORS0
RECOVERYACTIVE
Health-, Diagnose- und Recovery-Funktionen helfen zu erkennen, ob ein Dienst reagiert, ein Gateway online ist oder eine Komponente Aufmerksamkeit benötigt.
DIE SICHTBARE ZENITH-WELT
BACKEND → INFORMATION → MENSCH
ZENITH BACKEND
↓
RUNTIMEEVENTS
↓
DASHBOARDWHATSAPPWEBSITE
Das Backend verarbeitet Entscheidungen. Runtime und Events transportieren Informationen. Dashboard und Kommunikation machen sie sichtbar.
KAPITEL 08 FEHLER, REPARATUREN & EVOLUTION
KAPITEL 08
FEHLER, REPARATUREN & EVOLUTION
ROBUSTHEIT ENTSTEHT DURCH LERNEN AUS PROBLEMEN
ENTWICKLUNG→TEST→DIAGNOSE→REPARATUR→VALIDIERUNG
ZENITH entstand nicht als fertiges Produkt. Mit jeder neuen Funktion stieg die technische Komplexität — und damit die Bedeutung eines reproduzierbaren Engineering-Prozesses.
1 — COMPILER ALS ERSTE KONTROLLE
EIN BUILD MUSS ZUERST TECHNISCH SAUBER SEIN
MQL5 BUILD0 ERRORS0 WARNINGS
Compilerfehler und Warnungen werden vor einem produktiven Einsatz beseitigt. Das garantiert keine Trading-Performance, schafft aber eine unverzichtbare technische Grundlage.
2 — LIVE-DIAGNOSE
NICHT VERMUTEN — MESSEN
AI REQUESTAI RESPONSEENTRY APPROVALQUALITY SCORERUNTIMEAPI HEALTHSERVICE STATUSURSACHE FINDEN
Logs, Runtime-Daten, Health-Endpunkte und gezielte Diagnosebefehle machen sichtbar, warum eine Komponente handelt, wartet oder einen Fehler meldet.
3 — TRADE FORENSIK
WARUM WURDE DIESER TRADE GENAU HIER BEENDET?
ENTRY→POSITION→AI / TECHNIK→RISK→EXIT CAUSE
Deal-ID, Position, Haltedauer, Exit Authority, Risk Limits und AI-Gegensignale können nachträglich untersucht werden. Dadurch wird ein realer Handelsablauf rekonstruierbar.
4 — SERVER & SERVICE RECOVERY
EIN SYSTEM MUSS SICH AUCH REPARIEREN LASSEN
DIENSTACTIVE?
PORTERREICHBAR?
APIHTTP 200?
DATEIBERECHTIGUNG?
GATEWAYONLINE?
RECOVERYVALIDIERT?
Ein Fehler gilt nicht als behoben, nur weil eine Datei geändert wurde. Nach der Reparatur muss geprüft werden, ob Dienst, Port, API und abhängige Komponenten tatsächlich wieder funktionieren.
5 — BACKUP & ROLLBACK
EIN FUNKTIONIERENDER STAND MUSS GESCHÜTZT BLEIBEN
FUNKTIONIERENDER BUILD→BACKUP→ÄNDERUNG→TEST→ROLLBACK WENN NÖTIG
Backups und Rollback-Strategien verhindern, dass eine neue Änderung einen bereits funktionierenden Zustand unkontrolliert zerstört.
6 — AUTOMATISIERTES DEPLOYMENT
AUS VIELEN HANDGRIFFEN WIRD EIN REPRODUZIERBARER ABLAUF
Wiederkehrende Installations- und Reparaturschritte wurden zunehmend automatisiert. Damit wurden Änderungen kontrollierbarer und leichter nachvollziehbar.
7 — AUS FEHLERN ENTSTEHEN FUNKTIONEN
PROBLEM → ERKENNTNIS → EVOLUTION
ZU FRÜHER EXIT→ Exit Intelligence
WIEDERHOLTE EINSTIEGE→ Re-Entry Intelligence
VERBINDUNGSPROBLEME→ Health & Recovery
UNÜBERSICHTLICHE SYSTEME→ Runtime & Dashboard
Viele wichtige ZENITH-Komponenten entstanden nicht trotz der Probleme, sondern gerade durch deren systematische Analyse.
Der aktuelle Entwicklungsstand behält bewusst dieselbe EA-Identität. Verbesserungen werden nicht hinter ständig neuen Produktnamen versteckt, sondern innerhalb eines nachvollziehbaren Builds bewertet.
2 — TECHNISCHER STATUS
PRODUKTIVER BUILD: SAUBER KOMPILIERT
COMPILER0 ERRORS
WARNINGS0
PLATTFORMMT5
MARKTBTCUSD
VPSAKTIV
AI SERVERVERBUNDEN
Der aktuelle Expert Advisor wurde erfolgreich kompiliert und auf das MetaTrader Virtual Hosting migriert. Die Server- und AI-Kommunikation ist Bestandteil des produktiven Betriebs.
3 — ENTRY INTELLIGENCE
EIN AI-SIGNAL IST NOCH KEINE ORDER
AI SIGNAL+TECHNIK+QUALITY SCORE=ENTRY APPROVAL
AIBUY / 100%
≠
AUTOMATISCHER TRADENEIN
ZENITH kann selbst ein sehr starkes AI-Signal ablehnen, wenn technische Bestätigung oder Gesamtqualität nicht ausreichend sind. Signal und Freigabe bleiben bewusst getrennt.
4 — EXIT INTELLIGENCE
GUTE TRADES SOLLEN ZEIT BEKOMMEN
15:00
900 SEKUNDENStrategische Loss-Protection
Normale strategische Verlust-Exits werden bewusst vor kurzfristigem Marktrauschen geschützt. Die Idee dahinter: Eine kurzfristige Gegenbewegung bedeutet nicht automatisch, dass die ursprüngliche Handelsannahme falsch geworden ist.
ABSOLUTE RISK EMERGENCY0.95 R
Notbremse bleibt aktiv
Eine längere Haltedauer bedeutet nicht, dass ZENITH Risiken ignoriert. Mechanischer Stop-Loss, Take-Profit und die absolute Risikogrenze bleiben als übergeordnete Sicherheitsmechanismen erhalten.
Ein Same-Direction-Re-Entry soll nicht einfach dieselbe bereits gescheiterte Entscheidung wiederholen. Neue Marktinformation und stärkere Bestätigung werden verlangt.
Die zentrale Frage lautet jetzt nicht, wie viele weitere Funktionen eingebaut werden können. Entscheidend ist, welche vorhandenen Funktionen unter realen Marktbedingungen einen messbaren Vorteil erzeugen.
9 — TRANSPARENZ
TECHNOLOGIE VORHANDEN — PROFITABILITÄT MUSS BEWIESEN WERDEN
HEUTE VORHANDENAITrading IntelligenceEnterprise InfrastrukturLearning & Forensik
≠
NOCH ZU VALIDIERENNachhaltige ProfitabilitätLangfristiger Live-VorteilBelastbare Performance
Eine seriöse ZENITH-Dokumentation trennt bewusst zwischen vorhandener Technologie und tatsächlich nachgewiesener Trading-Performance.
DER HEUTIGE PUNKT
VON DER IDEE ZUR LIVE-VALIDIERUNG
IDEE→QUANT→ZENITH AI→ENTERPRISE→LEARNING→R77 / 2.200 LIVE
ZENITH ist heute wesentlich weiter als die ursprüngliche Trading-Idee. Gleichzeitig ist dieser Punkt bewusst keine Schlusslinie. Die nächsten Entscheidungen sollen zunehmend durch reale Daten und messbare Ergebnisse bestimmt werden.
KAPITEL 10 DIE ZUKUNFT VON ZENITH
KAPITEL 10
DIE ZUKUNFT VON ZENITH
DIE GESCHICHTE ENDET HIER NICHT
ENTWICKELN→MESSEN→LERNEN→VERBESSERN
Mit dem heutigen Entwicklungsstand beginnt eine neue Phase. Nicht die Anzahl neuer Funktionen soll entscheiden, sondern die Frage, welche Verbesserungen unter realen Bedingungen tatsächlich einen messbaren Nutzen erzeugen.
1 — VON FEATURES ZU EVIDENZ
DIE NÄCHSTE GENERATION ENTSTEHT AUS DATEN
LIVE TRADES→TRADE DNA→FORENSIK→ANALYSE→VERBESSERUNG
Jeder reale Trade kann neue Informationen liefern. Einstiegsqualität, Marktphase, Haltedauer, MFE, MAE und Exit-Ursache bilden gemeinsam eine Grundlage für zukünftige Entscheidungen.
2 — LEARNING MIT KONTROLLE
LERNEN JA — ABER NICHT BLIND
01DATEN SAMMELN
Reale Entscheidungen und Outcomes
02SHADOW LEARNING
Modelle zunächst ohne Live-Einfluss prüfen
03VALIDIEREN
Neue Logik gegen unabhängige Daten testen
04PROMOTION
Nur bei nachgewiesenem Vorteil
Eine neue Modellversion sollte nicht automatisch das Live-Trading beeinflussen. Zuerst muss sie zeigen, dass sie gegenüber dem bestehenden Verhalten tatsächlich besser abschneidet.
3 — PERFORMANCE ENGINEERING
ERFOLG WIRD MESSBAR
WIN RATE↗
PROFIT FACTOR↗
EXPECTANCY↗
DRAWDOWN↘
AVG LOSS↘
STABILITY↗
Die Zukunft von ZENITH soll nicht anhand einzelner Gewinntrades beurteilt werden. Entscheidend sind belastbare Kennzahlen über genügend Trades und unterschiedliche Marktphasen.
4 — ADAPTIVE INTELLIGENCE
NICHT EIN MARKT — SONDERN VERSCHIEDENE MARKTZUSTÄNDE
TRENDRANGEVOLATILITÄTMOMENTUMLIQUIDITÄTTRANSITION
MARKT ERKENNEN → STRATEGIE ANPASSEN
Langfristig soll ZENITH Marktbedingungen differenzierter bewerten und seine Entscheidungen stärker an den jeweils erkannten Kontext anpassen, anstatt jede Situation identisch zu behandeln.
Ein autonomeres System darf nicht bedeuten, dass Schutzmechanismen verschwinden. Mit zunehmender Intelligenz müssen Risikoüberwachung, Nachvollziehbarkeit und technische Sicherheitsgrenzen mindestens ebenso stark wachsen.
6 — TRANSPARENZ FÜR DEN MENSCHEN
DIE AI SOLL NICHT NUR ENTSCHEIDEN — SONDERN ERKLÄREN
WARUM ENTRY?WARUM KEIN ENTRY?WARUM EXIT?WELCHES RISIKO?WELCHE MARKTPHASE?WELCHE EVIDENZ?
Eine wichtige Entwicklungsrichtung ist Explainability: Entscheidungen sollen für Betreiber, Entwickler und später auch Kunden möglichst nachvollziehbar dargestellt werden können.
Die langfristige Vision ist nicht nur ein einzelner Trading-Roboter. ZENITH entwickelt sich in Richtung einer verbundenen Plattform, in der Trading, Daten, AI, Risiko, Kommunikation und Analyse zusammenarbeiten.
8 — DIE ENTSCHEIDENDE BEDINGUNG
DIE TECHNOLOGIE MUSS IHREN WERT BEWEISEN
NICHT GENUG
MEHR CODE
NICHT GENUG
MEHR MODULE
NICHT GENUG
MEHR AI
ENTSCHEIDEND
MESSBARER LIVE-VORTEIL
Der zukünftige Wert von ZENITH hängt nicht davon ab, wie komplex das System klingt. Entscheidend ist, ob die Technologie dauerhaft bessere Entscheidungen, kontrolliertes Risiko und belastbare Ergebnisse erzeugt.
9 — DIE VISION
EIN SYSTEM, DAS MIT JEDER ENTSCHEIDUNG BESSER VERSTANDEN WIRD
BEOBACHTEN→ENTSCHEIDEN→HANDELN→AUSWERTEN→LERNEN
Die Vision ist ein System, dessen Entscheidungen zunehmend nachvollziehbar, messbar und datenbasiert verbessert werden können — ohne dabei die Kontrolle über Risiko und Betrieb zu verlieren.
Z
VON DER ERSTEN IDEE BIS HEUTE
DAS IST ZENITH AI
EULE→WINSTON→GERDV4→LOVE RAKETE→ERNST & WERNER→MINUTETRADER→ORION QUANT→MARS→ZENITH AI
Aus einer Trading-Idee entstand Schritt für Schritt eine AI-gestützte Trading- und Enterprise-Plattform.
ENTWICKELNTESTENVERSTEHENVERBESSERN
ZENITH AI
THE JOURNEY CONTINUES.
Z
ZENITH AI STORY STUDIO
DIE REISE IST VOLLSTÄNDIG
10 Kapitel. Von der ersten Trading-Idee bis zur heutigen ZENITH-AI-Plattform.
10KAPITEL
100%STORY
2026ZENITH AI
THE JOURNEY CONTINUES.
Neue validierte Entwicklungsstufen können später als weitere Meilensteine ergänzt werden.
ZENITH AI
TECHNICAL INTELLIGENCE MAP
01MT5 EA
Trading Core
→
02AI SERVER
Prediction & Confidence
→
03API
Transport Layer
→
04RUNTIME
Live State
05LEARNING
Shadow Models
→
06TRADE DNA
Decision Features
→
07FORENSICS
Outcome Analysis
→
08DASHBOARD
Visibility
→
09COMMUNICATION
WhatsApp / Contact
SELECTED COMPONENT
MT5 EA
Trading core for market analysis, entry approval, risk control, execution, position management, exit intelligence and re-entry logic.
TECHNICAL DOCUMENTATION
KAPITEL 01 — DIE IDEE
CHAPTER 01MODE TECHNIKDOCUMENTATION ACTIVE
TECHNISCHE BEDEUTUNG
ZENITH AI • TECH-03
KAPITEL 01 — DIE IDEE
CHAPTER 01 / 10LAYER DEEP DIVEACCESS TECH ONLY
ARCHITEKTUR
Vom Konzept zur ersten Systemstruktur
ENTWICKLUNGSSTUFE
FOUNDATION
TECHNISCHE REIFE
BASIS
ZENITH BEZUG
URSPRUNG
ZENITH AI • TECH-04
LIVE ARCHITECTURE TRACE
MODE TECHNIKTRACE READYFLOW AUTOMATED
01MARKTPreis, Kerzen, Volatilität
→
02MT5 EATrading Core
→
03TECHNIKEMA • ATR • ADX • RSI • MACD
→
04AI SERVERDirection • Confidence • Score
→
05QUALITYTrade Quality Engine
→
06ENTRY AUTHORITYFinal Approval
→
07RISKSL • TP • Limits
→
08ORDERExecution
→
09POSITIONLive Trade
→
10EXIT / RE-ENTRYPosition Intelligence
→
11EVENTTrade Event
→
12RUNTIMELive State
→
13DASHBOARDVisibility
AKTUELLER SCHRITT
MARKT
Der Markt liefert Rohdaten wie Preisbewegung, Kerzenstruktur, Volatilität und Momentum.
TRACE PROGRESS0%
ZENITH AI • TECH-05
EVIDENCE & VALIDATION MATRIX
TECHNOLOGIE
VORHANDEN
TECHNISCHER BUILD
VALIDIERT
LIVE PERFORMANCE
IN VALIDIERUNG
TECHNISCH BESTÄTIGT IMPLEMENTIERT / VORHANDEN LIVE ZU VALIDIEREN
01MT5 EA
Trading-Kern vorhanden
TECHNISCH BESTÄTIGT
Der MT5 Expert Advisor ist die zentrale Trading Authority. Andere Komponenten können Informationen liefern, Zustände anzeigen oder Events transportieren, aber die Handelsentscheidung bleibt im EA.
ABHÄNGIG VON
MARKTDATEN • MT5
WENN AUSGEFALLEN
TRADING STOPPT
KRITIKALITÄT
KRITISCH
MT5 EATRADING COREKRITISCH
APITRANSPORTHOCH
AI SERVERINTELLIGENCEHOCH
RUNTIMEOBSERVABILITYMITTEL
DASHBOARDVISIBILITYNIEDRIG
WHATSAPPCOMMUNICATIONNIEDRIG
CONTACTWEBSITENIEDRIG
LEARNINGSHADOWNIEDRIG
FORENSICSANALYSISMITTEL
VPSAVAILABILITYHOCH
WICHTIGER GRUNDSATZNicht jede externe Komponente ist für die reine Orderausführung zwingend erforderlich. ZENITH trennt Trading Authority, Intelligence, Observability, Learning und Communication bewusst voneinander.
ZENITH AI • TECH-07
FAILURE & RECOVERY INTELLIGENCE
01NORMALSystem healthy
→
02DEGRADEDPartial impairment
→
03FAILUREService unavailable
→
04RECOVERYRepair / restart
→
05VERIFIEDHealth confirmed
FAILURE DOMAIN
SELECTED DOMAIN
AI SERVER
Die externe AI-Bewertung ist nicht verfügbar. Die Auswirkungen hängen davon ab, wie stark der aktuelle Trading-Pfad von der AI-Freigabe abhängt.
WAS FÄLLT AUS?
AI DIRECTION / CONFIDENCE / SCORE
WAS BLEIBT?
MT5 • RISK • POSITION CONTROL
RECOVERY ACTION
AI SERVICE / API VERBINDUNG PRÜFEN
VERIFICATION
HEALTH + RESPONSE TEST
SEVERITYHOCH
1DETECT
Fehler sichtbar machen
→
2ISOLATE
Failure Domain eingrenzen
→
3REPAIR
Dienst / Verbindung reparieren
→
4VERIFY
Health / Port / API prüfen
→
5RETURN
Normalzustand bestätigen
ENGINEERING PRINCIPLE
Eine Reparatur ist erst abgeschlossen, wenn der betroffene Dienst und seine abhängigen Funktionen erneut technisch verifiziert wurden.
ZENITH AI • TECH-08
SECURITY & CONTROL BOUNDARIES
TRADING AUTHORITY
MT5 / ZENITH EADarf Entry, Order, Position und Exit kontrollieren
≠
EXTERNAL COMPONENTS
AI • API • DASHBOARD • COMMUNICATIONBewerten, transportieren, anzeigen oder melden
CONTROL LAYERS
SELECTED CONTROL DOMAIN
MT5 EA
Der Expert Advisor ist die zentrale Trading Authority. Er verarbeitet lokale Marktinformationen, entscheidet über Entry-Freigabe, führt Orders aus und verwaltet Positionen.
DARF
ANALYSIEREN • FREIGEBEN • ORDERN • EXIT
DARF NICHT ÜBERSCHRITTEN WERDEN
RISK LIMITS • SL / TP • EMERGENCY
DATA GOVERNANCE PRINCIPLE
ZENITH trennt Live-Entscheidungsdaten, Betriebsdaten, Kommunikationsereignisse und Learning-Daten bewusst nach ihrem technischen Zweck.
ZENITH AI • TECH-10
RUNTIME & SERVICE TOPOLOGY
TRADING CORE MT5 / VPSSERVER CORE API / AI / RUNTIMECOMMUNICATION WHATSAPP / CONTACTPUBLIC LAYER NGINX / HTTPS
TRADING LAYER
→
↓
SERVER LAYER
→+
↓
OBSERVABILITY & COMMUNICATION
++
↓
PUBLIC EDGE
→
SELECTED SERVICE
MT5 EA
Der Expert Advisor läuft in MetaTrader und bildet die zentrale Trading Authority.
ROLLE
TRADING CORE
SCHNITTSTELLE
MT5 INTERNAL
PORT / ENDPOINT
LOCAL
ABHÄNGIG VON
MT5 • BROKER • VPS
WENN AUSGEFALLEN
TRADING STOPPT
KRITIKALITÄT
KRITISCH
SERVICEFUNKTIONINTERFACESTATUS-TYP
MT5 EATRADINGMT5LOCAL / VPS
ZENITH APITRANSPORTHTTPSERVICE
AI SERVERINTELLIGENCEHTTPSERVICE
RUNTIME STOREOBSERVABILITYSTATERUNTIME
DASHBOARDVISIBILITYHTTP/WSFRONTEND
WHATSAPPCOMMUNICATIONHTTP/QUEUEGATEWAY
CONTACTCOMMUNICATIONHTTPGATEWAY
NGINXPUBLIC EDGE80 / 443PROXY
LOCAL / VPS
Trading läuft im MetaTrader-Kontext.
→
SERVER
AI, API und Runtime ergänzen Intelligence und Observability.
→
PUBLIC
Nginx und HTTPS exponieren nur vorgesehene Dienste nach außen.
RUNTIME PRINCIPLE
ZENITH trennt Trading-Ausführung, Server-Intelligence, Observability, Kommunikation und öffentliche Erreichbarkeit in eigene Laufzeitdomänen.
ZENITH AI • TECH-11
LIVE HEALTH & SERVICE STATUS
MODEDOCUMENTATION / LOCAL STORY
Keine erfundenen Live-Zustände. Nicht verbundene Dienste werden als UNKNOWN dargestellt.
ONLINE
0
DEGRADED
0
OFFLINE
0
UNKNOWN
10
SELECTED SERVICE
MT5 EA
Der lokale Story Viewer ist nicht direkt mit dem produktiven MetaTrader verbunden. Deshalb wird kein Live-Zustand behauptet.
STATUS
UNKNOWN
ENDPOINT
MT5 INTERNAL
LAST CHECK
NOT CONNECTED
RESPONSE TIME
N/A
DEPENDS ON
MT5 • BROKER • VPS
VERIFICATION METHOD
MT5 LOG / VPS STATUS
TRUTH STATENOT VERIFIED FROM THIS LOCAL STORY VIEWER
ONLINEHealth technisch bestätigt
DEGRADEDTeilfunktion gestört
OFFLINEDienst nicht verfügbar
UNKNOWNKeine aktuelle Live-Prüfung
1CONNECTEndpoint erreichbar?
→
2HEALTHHealth Response gültig?
→
3DEPENDENCYAbhängigkeiten verfügbar?
→
4LATENCYAntwortzeit plausibel?
→
5STATUSONLINE / DEGRADED / OFFLINE
HEALTH PRINCIPLE
Ein grüner Status darf nur angezeigt werden, wenn der betroffene Dienst aktuell technisch geprüft wurde. Fehlende Verbindung wird nicht als ONLINE interpretiert.
ZENITH AI • TECH-12
LIVE CONNECTIVITY & ENDPOINT MATRIX
LIVE VERIFICATIONNOT CONNECTED FROM LOCAL STORY VIEWER
Alle Verbindungen bleiben auf NOT VERIFIED, solange keine echte technische Prüfung erfolgt.
CONNECTIONS10
VERIFIED0
NOT VERIFIED10
PUBLIC EDGEHTTPS
→→→→+++++
SELECTED CONNECTION
MT5 EA → ZENITH API
Der Expert Advisor überträgt strukturierte Requests und Trade Events an die ZENITH API.
SOURCE
MT5 EA
TARGET
ZENITH API
PROTOCOL
HTTP
ENDPOINT / PORT
127.0.0.1:5001
DIRECTION
OUTBOUND FROM EA
BOUNDARY
LOCAL / SERVER
DATA
FEATURES • TRADE EVENTS
STATUS
NOT VERIFIED
VERIFICATION METHOD
1RESOLVEEndpoint bestimmen
→
2CONNECTPort erreichbar
→
3REQUESTRequest senden
→
4RESPONSEGültige Antwort
→
5VERIFYStatus bestätigen
TRUTH STATENO VERIFIED CONNECTION TEST = NOT VERIFIED
CONNECTIONPROTOCOLENDPOINTBOUNDARYSTATUS
MT5 → APIHTTP127.0.0.1:5001SERVERNOT VERIFIED
API → AIHTTPINTERNALSERVERNOT VERIFIED
API → RUNTIMESTATE/EVENTINTERNALSERVERNOT VERIFIED
CONNECTIVITY PRINCIPLE
Ein konfigurierter Endpoint ist nicht automatisch eine funktionierende Verbindung. ZENITH unterscheidet Konfiguration, Erreichbarkeit, gültige Antwort und tatsächlich bestätigten End-to-End-Datenfluss.
ZENITH AI • TECH-13
AUTHENTICATION & TRUST CHAIN
VERIFICATION MODEDOCUMENTED / NOT LIVE VERIFIED
Erreichbarkeit bedeutet nicht automatisch autorisierten Zugriff.
01IDENTITYWer kommuniziert?
→
02AUTHENTICATIONIdentität prüfen
→
03AUTHORIZATIONDarf diese Aktion erfolgen?
→
04TRANSPORTTLS / interne Verbindung
→
05BOUNDARYInterne / öffentliche Grenze
→
06VERIFIED ACCESSTechnisch bestätigt
TRUST DOMAINS
SELECTED TRUST DOMAIN
MT5 EA
Der Expert Advisor besitzt die Trading-Identität innerhalb des MetaTrader-Kontexts. Die lokale Story kann jedoch keine aktuelle produktive Authentifizierung verifizieren.
IDENTITY
MT5 EA / TRADING CONTEXT
AUTHENTICATION
NOT VERIFIED HERE
AUTHORIZATION
TRADING AUTHORITY LOCAL TO EA
TRANSPORT SECURITY
DEPENDS ON CONNECTION
TRUST BOUNDARY
MT5 / SERVER
VERIFICATION STATE
NOT VERIFIED
ACCESS RULEA connection alone does not prove authenticated or authorized access.
01IDENTITY ≠ ACCESS
Eine bekannte Komponente besitzt nicht automatisch Zugriffsrechte.
02AUTHENTICATION ≠ AUTHORIZATION
Eine bestätigte Identität darf nur erlaubte Aktionen ausführen.
03TLS ≠ APPLICATION AUTH
Transportverschlüsselung ersetzt keine Anwendungsautorisierung.
04PUBLIC ≠ TRUSTED
Öffentliche Erreichbarkeit ist immer eine eigene Vertrauensgrenze.
ZENITH TRUST PRINCIPLE
Eine Verbindung gilt erst dann als vertrauenswürdig, wenn Identität, Berechtigung, Transportweg und technische Verifikation zusammenpassen.
ZENITH AI • TECH-14
SECURITY EVENT & AUDIT TRAIL
MODEDOCUMENTED / NOT LIVE VERIFIED
Keine erfundenen Live-Logs. Reale Events können später über echte Log-Daten angebunden werden.
01EVENTWas ist passiert?
→
02SOURCEWo entstand es?
→
03ACTIONWas wurde ausgeführt?
→
04AUTHORITYWer durfte handeln?
→
05RESULTWas war das Ergebnis?
→
06EVIDENCEWelcher Nachweis existiert?
EVENT CLASSES
SELECTED EVENT CLASS
TRADE OPENED
Eine neue Position wurde durch den MT5 Expert Advisor eröffnet. Das eigentliche Trading-Ereignis entsteht im Trading-Kontext.
SOURCE
MT5 EA
ACTION
OPEN POSITION
AUTHORITY
TRADING AUTHORITY
EXPECTED RESULT
POSITION CREATED
EVIDENCE SOURCE
MT5 DEAL / TRADE EVENT
VERIFICATION STATE
DOCUMENTED
AUDIT RULEEin dokumentierter Event-Typ ist noch kein Beweis dafür, dass ein konkretes Live-Ereignis stattgefunden hat.
TRADING EVIDENCE
MT5 Deals • Orders • Position History
SERVER EVIDENCE
API Logs • Service Journal • Health
COMMUNICATION EVIDENCE
Event Log • Send Log • Audit Log
RECOVERY EVIDENCE
Backup • Self-Test • Health Verification
AUDIT PRINCIPLE
Ein belastbarer Audit Trail verbindet Ereignis, Quelle, Berechtigung, Ergebnis und technischen Nachweis. Fehlt der Nachweis, bleibt das Ereignis dokumentiert, aber nicht live verifiziert.
ZENITH AI • TECH-15
LOGGING & EVIDENCE CORRELATION
MODEDOCUMENTED / NOT LIVE CORRELATED
Die Story verbindet dokumentierte Datenklassen. Reale Live-Korrelation wird erst mit echten Logs als VERIFIED markiert.
01TRADEOrder / Deal
→
02DECISIONTech / AI / Quality
→
03APIRequest / Response
→
04EVENTOpened / Closed
→
05RUNTIMELive State
→
06COMMUNICATIONNotification
→
07AUDITEvidence Link
CORRELATION DOMAINS
SELECTED RECORD TYPE
TRADE RECORD
Der Trade Record bildet die handelstechnische Referenz. Er kann Order-, Deal-, Position- und Outcome-Informationen enthalten.
PRIMARY KEY
TICKET / DEAL ID
TIMESTAMP
TRADE TIME
SOURCE
MT5
LINKS TO
DECISION • EVENT • FORENSICS
EVIDENCE
ORDER / DEAL HISTORY
STATE
DOCUMENTED
CORRELATION RULEGemeinsame IDs, Zeitstempel oder eindeutige Ereignisbezüge sind erforderlich, bevor zwei Records als zusammengehörig gelten.
EXAMPLE CORRELATION PATH
TRADETICKET#123456
↔
DECISIONDECISION IDDEC-123456
↔
APIREQUEST IDREQ-123456
↔
EVENTEVENT IDEVT-123456
↔
AUDITEVIDENCE IDAUD-123456
IMPORTANTDie dargestellten IDs sind nur ein Dokumentationsbeispiel und keine echten Live-Datensätze.
01IDENTITY
Jeder Record benötigt einen nachvollziehbaren Identifikator.
02TIME
Zeitstempel müssen logisch zur Ereigniskette passen.
03CAUSALITY
Ein zeitlicher Zusammenhang allein beweist noch keine Ursache.
04EVIDENCE
Die Korrelation muss durch reale technische Records belegbar sein.
ZENITH CORRELATION PRINCIPLE
Ein belastbarer technischer Nachweis entsteht erst, wenn Trade, Entscheidung, Transport, Event, Runtime, Kommunikation und Audit über eindeutige Referenzen nachvollziehbar miteinander verbunden werden können.
ZENITH AI • TECH-16
INCIDENT & ROOT CAUSE INTELLIGENCE
MODEDOCUMENTED / NOT LIVE VERIFIED
Keine erfundenen Incidents. Reale Störungen werden erst durch Logs, Health Checks oder externe Evidenz als VERIFIED markiert.
01DETECTION
Was wurde erkannt?
→
02IMPACT
Welche Funktion ist betroffen?
→
03ROOT CAUSE
Was ist die Ursache?
→
04REPAIR
Welche Maßnahme behebt es?
→
05VALIDATION
Ist die Funktion wieder korrekt?
→
06CLOSURE
Ist der Incident technisch abgeschlossen?
INCIDENT CLASSES
SELECTED INCIDENT CLASS
API UNREACHABLE
Die zentrale API ist nicht erreichbar. Dadurch können externe AI-Anfragen, Events und serverseitige Integrationen unterbrochen werden.
DETECTION
HTTP CONNECTION FAILED
IMPACT
AI / EVENTS / SERVER CONNECTIVITY
ROOT CAUSE
SERVICE / PORT / ROUTING
REPAIR ACTION
SERVICE + PORT + ROUTE PRÜFEN
VALIDATION
HEALTH + REQUEST TEST
STATE
DOCUMENTED
INCIDENT RULE
Ein Incident ist erst geschlossen, wenn Ursache, Reparatur und Funktionsprüfung technisch nachvollziehbar bestätigt wurden.
Ein Neustart allein gilt nicht als Root-Cause-Behebung.
Erst reproduzierbare Ursache plus erfolgreiche Funktionsprüfung erlauben den Status VERIFIED.
INCIDENT PRINCIPLE
Robustheit entsteht nicht dadurch, dass Fehler niemals auftreten, sondern dadurch, dass sie erkannt, isoliert, verstanden, repariert und anschließend technisch validiert werden.
ZENITH AI • TECH-17
CHANGE, DEPLOYMENT & ROLLBACK INTELLIGENCE
MODEDOCUMENTED / CHANGE-SAFE
Änderungen gelten erst nach Backup, Deployment, Self-Test und technischer Validierung als akzeptiert.
01CHANGEWas soll geändert werden?
→
02BACKUPIst der vorherige Stand gesichert?
→
03DEPLOYWurde die Änderung installiert?
→
04SELF-TESTBesteht der technische Basistest?
→
05VALIDATIONIst die Ziel-Funktion wirklich korrekt?
→
06ACCEPT / ROLLBACKBehalten oder zurückrollen?
CHANGE DOMAINS
SELECTED CHANGE DOMAIN
MT5 EA
Änderungen am Expert Advisor betreffen den Trading Core und benötigen deshalb die strengste Backup-, Compile-, Migrations- und Live-Validierung.
CHANGE TYPE
TRADING LOGIC / EA CODE
BACKUP REQUIREMENT
SOURCE + LAST WORKING BUILD
DEPLOY TARGET
MT5 / METAQUOTES VPS
SELF-TEST
0 ERRORS / 0 WARNINGS
VALIDATION
LIVE BEHAVIOR / LOG / CONNECTION
ROLLBACK POINT
LAST VERIFIED BUILD
CHANGE RULEEine erfolgreiche Installation ist noch keine erfolgreiche Änderung. Erst Self-Test und Funktionsprüfung entscheiden über ACCEPT oder ROLLBACK.
BACKUP FIRST
Vor jeder produktiven Änderung wird ein reproduzierbarer Rückkehrpunkt erstellt.
✓
SELF-TEST
Syntax, Service, Health, Route oder Compile werden unmittelbar geprüft.
⌁
FUNCTION TEST
Die betroffene Funktion muss nach dem Deployment tatsächlich funktionieren.
↺
ROLLBACK READY
Fehlschlägt ein kritischer Test, wird auf den letzten verifizierten Stand zurückgekehrt.
DEPLOYMENT DECISION
INSTALL≠SUCCESS
SELF-TEST+FUNCTION TEST
→ ACCEPToder→ ROLLBACK
ENGINEERING NOTES
Ein Service mit Status ACTIVE kann funktional trotzdem falsch arbeiten.
Ein HTTP 200 allein beweist nicht den gesamten End-to-End-Prozess.
Ein Rollback gilt erst als erfolgreich, wenn auch der zurückgespielte Stand erneut geprüft wurde.
ZENITH DEPLOYMENT PRINCIPLE
Keine produktive Änderung ohne reproduzierbares Backup, technischen Self-Test, Funktionsvalidierung und einen klar definierten Rollback-Punkt.
ZENITH AI • TECH-18
SYSTEM EVOLUTION & VERSION LINEAGE
MODEDOCUMENTED DEVELOPMENT LINEAGE
Entwicklungsschritte werden als historische Systemlinie dargestellt. Live-Performance wird davon getrennt bewertet.
01GENERATIONWelche Systemgeneration?
→
02CAPABILITYWas konnte sie?
→
03LIMITATIONWas fehlte?
→
04CHANGEWas wurde verbessert?
→
05VALIDATIONWas wurde technisch bestätigt?
→
06SUCCESSORWas folgte daraus?
SYSTEM GENERATIONS
SELECTED GENERATION
ZENITH AI
ZENITH verbindet Trading Core, AI-Intelligence, Runtime, Forensik, Learning, Dashboard, Kommunikation und Enterprise-Infrastruktur zu einer gemeinsamen Plattform.
GENERATIONCURRENT PLATFORM
CORE CAPABILITYAI + TRADING + ENTERPRISE
MAJOR CHANGESYSTEM INTEGRATION
VALIDATIONTECHNICALLY BUILT / LIVE VALIDATION ONGOING
SUCCESSORZENITH CONTINUES
STATECURRENT
EVOLUTION RULEEine neue Generation gilt nicht automatisch als besser, nur weil sie mehr Funktionen besitzt. Fortschritt muss technisch und später auch durch reale Ergebnisse bestätigt werden.
ITERATIONJede Generation übernimmt Erkenntnisse aus vorherigen Versuchen.
②
SEPARATIONNeue Technologie wird von nachgewiesener Performance getrennt bewertet.
③
VALIDATIONCompile, Health und Architektur bestätigen Technik – nicht automatisch Profitabilität.
④
CONTINUITYZENITH ist kein Endpunkt, sondern der aktuellste dokumentierte Stand.
CURRENT ZENITH LINEAGE
ZENITH AI
Trading CoreACTIVE ARCHITECTURE
AI IntelligenceINTEGRATED
EnterpriseINTEGRATED
LearningSHADOW / VALIDATION
PerformanceLIVE EVIDENCE REQUIRED
ENGINEERING NOTES
Historische Namen dokumentieren Entwicklungsstufen, keine Garantie für Qualität oder wirtschaftlichen Erfolg.
Capability Growth und Performance Growth müssen getrennt gemessen werden.
Der heutige Stand kann später um weitere validierte Generationen ergänzt werden.
ZENITH EVOLUTION PRINCIPLE
Fortschritt bedeutet nicht, immer mehr Komponenten hinzuzufügen. Fortschritt bedeutet, aus jeder Generation belastbare Erkenntnisse zu gewinnen und nur das weiterzuführen, was technisch und praktisch Bestand hat.
ZENITH AI • TECH-19
TRADING DECISION ANATOMY
MODEDOCUMENTED DECISION FLOW
Die technische Entscheidungskette wird getrennt von tatsächlicher Live-Profitabilität dokumentiert.
01MARKET DATAWas liefert der Markt?
→
02INDICATORSWie wird der Zustand gemessen?
→
03FEATURESWelche Merkmale entstehen?
→
04AI / SCOREWelche Bewertung entsteht?
→
05AUTHORITYDarf ein Entry erfolgen?
→
06OUTCOMEWas geschieht danach?
DECISION DOMAINS
SELECTED DECISION DOMAIN
MARKET DATA
Die Entscheidung beginnt mit Rohinformationen aus dem Markt. Preis, Kerzenstruktur, Spread und technische Rohwerte bilden noch keine Handelsentscheidung, sondern nur die Datengrundlage.
INPUTPRICE • CANDLES • SPREAD
PROCESSMARKET OBSERVATION
OUTPUTRAW MARKET STATE
AUTHORITYNONE
EVIDENCETICKS / CANDLES / SYMBOL DATA
STATEDOCUMENTED
DECISION RULEMarktdaten liefern Informationen, aber keine Trading Authority.
DATAMarket Data beschreibt den Zustand, trifft aber keine Entscheidung.
②
INTELLIGENCETechnik und AI liefern Bewertungen und Kontext.
③
AUTHORITYDie endgültige Freigabe bleibt eine eigene kontrollierte Ebene.
④
EXECUTIONErst nach Freigabe darf aus einer Bewertung ein Trade werden.
TRADING AUTHORITY BOUNDARY
MARKETNO EXECUTION
AI SERVERADVISORY
QUALITYFILTER / SCORE
ENTRY AUTHORITYFINAL APPROVAL
MT5 EAEXECUTION
ENGINEERING NOTES
Ein hoher AI-Score allein darf keinen Trade erzwingen.
Technische Qualität und AI-Bewertung sind Eingaben für die Entscheidungslogik, nicht automatisch Execution Authority.
Nach dem Entry beginnt eine neue Entscheidungsphase: Position Management, Exit Intelligence und gegebenenfalls Re-Entry.
Outcome und Forensik wirken rückblickend auf Analyse und Learning, aber nicht rückwirkend auf den bereits ausgeführten Trade.
ZENITH DECISION PRINCIPLE
Eine robuste Trading-Entscheidung entsteht aus einer nachvollziehbaren Kette von Daten, Messung, Kontext, Intelligence, Qualitätsbewertung und kontrollierter Authority. Kein einzelner Score besitzt alleinige Trading-Macht.
ZENITH AI • TECH-20
TECHNICAL COMMAND SUMMARY & ARCHITECTURE OVERVIEW
MODETECHNICAL SUMMARY / DOCUMENTED ARCHITECTURE
Abschlussübersicht der technischen ZENITH-Dokumentation. Live-Status und Profitabilität bleiben davon getrennt.
01TRADING COREEntscheiden & handeln
→
02INTELLIGENCEBewerten & lernen
→
03TRANSPORTAPI & Events
→
04RUNTIMEStatus & Observability
→
05CONTROLSecurity & Recovery
→
06EVIDENCEAudit & Validation
ARCHITECTURE DOMAINS
SELECTED ARCHITECTURE DOMAIN
TRADING CORE
Der Trading Core bildet die zentrale Handlungsebene. Marktinformationen, technische Bewertung, Entry Authority, Orderausführung, Position Management sowie Exit- und Re-Entry-Logik laufen hier zusammen.
PRIMARY FUNCTIONTRADING AUTHORITY & EXECUTION
CORE COMPONENTSMT5 EA • ENTRY • POSITION • EXIT
INPUTMARKET • TECH • AI • RISK
OUTPUTORDER • POSITION • OUTCOME
CONTROL LEVELCRITICAL
STATEDOCUMENTED
ARCHITECTURE RULETrading Authority bleibt von Advisory-, Observability- und Communication-Komponenten getrennt.
TRADING AUTHORITYMT5 / ZENITH Trading Core bleibt die einzige direkte Handelsschicht.
②
AI AUTHORITYAI liefert Intelligence und Bewertung, nicht alleinige Order Authority.
③
OBSERVABILITYRuntime, Dashboard und Health beobachten den Zustand, ohne Trading Authority zu übernehmen.
④
EVIDENCELogs, Audit, Forensik und Correlation schaffen technische Nachvollziehbarkeit.
CURRENT TECHNICAL DOCUMENTATION
TECH-01 → TECH-20
ArchitectureDOCUMENTED
Trading AuthoritySEPARATED
AI InfluenceCONTROLLED
Security BoundariesDOCUMENTED
Audit / RecoveryDOCUMENTED
Live HealthREQUIRES LIVE SOURCE
ProfitabilityREQUIRES LIVE EVIDENCE
TECHNICAL CONCLUSION
ZENITH ist nicht mehr nur ein Expert Advisor.
Die Architektur umfasst Trading, Intelligence, Transport, Runtime, Observability, Kommunikation, Security, Recovery, Audit, Deployment und Learning.
Der nächste Entwicklungsschritt der Story betrifft nicht mehr die technische Übersicht, sondern die Präsentation und Erzählung dieser Entwicklung.
ZENITH TECHNICAL COMMAND PRINCIPLE
Die technische Stärke einer Plattform entsteht nicht aus einem einzelnen Modul, sondern aus klar getrennten Verantwortlichkeiten, kontrollierten Übergängen, reproduzierbaren Änderungen und nachvollziehbarer Evidenz über den gesamten Systemlebenszyklus.
ZENITH AI • NARRATOR-01
STORY NARRATOR ENGINE
STATUS
BEREIT
MODUS
KUNDE
KAPITEL
01 / 10
SPRACHE
DEUTSCH
JETZT WIRD ERZÄHLT
Kapitel 01 – Die Idee
Bereit für die ZENITH Geschichte.
0%Satz 0 / 0
KAPITEL DIREKT WÄHLEN
NARRATOR PRINCIPLE
Die Stimme begleitet die Geschichte. Sie ersetzt nicht den sichtbaren Inhalt, sondern macht aus der ZENITH Reise eine geführte Präsentation.