Umsetzung der Implementierungsspezifikation v1.0 · Stand 1. September 2026
Die komplette Engine aus der Spezifikation ist gebaut und läuft: Point-in-Time-Historie, gewichteter Candidate Pool, regularisierter Rating-Fit, Rally-/Satz-Simulation, exakte Live-Satzwahrscheinlichkeit, No-Vig-Marktvergleich, Signal-Gates mit maschinenlesbaren Gründen, Walk-forward-Backtest, Kalibrierung, Settlement und CLV. Alles ist deployed, versioniert und reproduzierbar. Was fehlt, ist der Datenprovider — und zwar bewusst: das ist laut Spec (Kap. 32) die erste offene Entscheidung. Bis dahin läuft die Engine auf einer synthetischen Demo-Welt, die sie nicht kennt und aus der sie die Teamstärken selbst schätzen muss.
Jedes Kapitel der Spezifikation, das v1 betrifft, ist implementiert. Die Zuordnung:
| Spec | Thema | Umsetzung |
|---|---|---|
| 3 | Competition Rule Configuration | rules.ts — versioniert, am Matchdatum geprüft; unbekanntes Format ⇒ BLOCKED_DATA_FORMAT, keine Prediction |
| 5–6 | Kanonisches Datenmodell | 23 D1-Tabellen, Rohdaten und Odds append-only, Korrekturen versioniert |
| 7 | Ingestion & Data Health | Rally-Sequenz-Validator (5 Pflichtprüfungen), Quarantäne, Completeness-Score je Prediction |
| 8 | Point-in-Time | Cutoff-Filter im Pool, Closing-Odds nur als spätere CLV-Metrik, Integrationstest gegen Leakage |
| 9 | Candidate Pool & Gewichtung | Recency-Decay, 10 Similarity-Dimensionen, Cap, ESS |
| 10 | Team DNA | Regularisierter logistischer Fit (gedämpftes Newton mit Backtracking), hierarchisches Shrinkage |
| 11 | Lineup | Logit-Adjustment, unbestätigte Aufstellung senkt Confidence per hartem Deckel |
| 12–13 | Rally-Modell & Simulation | Beide Serverzustände, Deuce, Entscheidungssatz, 50.000 Pfade, Seed gespeichert |
| 14 | ML Residual Layer | Gradient-Boosting in reinem TypeScript, korrigiert den Verteilungs-Parameter, 72/28-Blend |
| 15 | PRE Over Points | Most-even Main-Line-Auswahl, Fair Odds mit Push-Behandlung, alle Release-Gates |
| 16 | LIVE Set Winner | Exaktes Dynamic Programming inkl. analytisch gelöstem Deuce-Schwanz — keine Simulation |
| 17 | No-Vig, Push, CLV | Zweiweg-Entmarginalisierung, Integer-Totals, Viertellinien, Price-/Probability-CLV getrennt |
| 18–19 | Gates, Risiko, Confidence | 8 Decision States, 28 Reason Codes, 8-Komponenten-Confidence mit harten Deckeln |
| 20–21 | Backtesting & Kalibrierung | Expanding Walk-forward, Brier/LogLoss/ECE/CRPS/CLV, Isotonic-Kalibrierung, Champion/Challenger |
| 22–23 | Settings & API | Vollständiger Settings-Katalog mit Config-Hash, 17 /v1-Endpunkte |
| 24 | Orchestrierung | Nightly Feature Build, PRE-Snapshot-Leiter, atomares Live-Commit über state_version |
| 25–27 | Dashboard, Delivery, Audit | Zehn Seiten live an der API, Dedupe-Keys, vollständiger Audit-Record je Run |
| 28 | Testplan | 92 Tests: alle 14 Zeilen der Unit-Test-Tabelle plus die 6 Integrationsszenarien |
Es gibt noch keinen Datenprovider. Statt Platzhalterzahlen ins Dashboard zu schreiben, erzeugt der Build eine deterministische Demo-Welt: 60 Teams, 1.922 gespielte Matches über zwei Saisons, 317.704 Rallys mit vollständigem Point-by-Point, dazu ein Buchmacher, der aus seiner eigenen verrauschten Sicht auf dieselben verborgenen Teamparameter Preise stellt.
Die Engine kennt diese Parameter nicht. Sie muss sie aus den Rally-Logs schätzen — genau wie später aus einem echten Feed. Jede Zahl im Dashboard ist damit das Ergebnis der echten Pipeline, nur auf synthetischem Input. Kein Wert ist ein validiertes Profitabilitätsergebnis; die Spec verbietet diese Behauptung in Kapitel 1.2 ausdrücklich.
Gleicher Seed, gleiche Config ⇒ bitgleiche Ausgabe. Jede Prediction speichert Modellversion, Config-Hash, Feature-Snapshot, Odds-Snapshot, Random Seed und jeden einzelnen Gate-Wert. Der Rating-Fit rekonstruiert die verborgene Wahrheit sauber: Liga-Baseline −0,48 bis −0,56 gegen wahre −0,53, Heimvorteil 0,083–0,108 gegen wahre 0,085.
Mit den Spec-Defaults gibt die Engine auf 473 Walk-forward-Predictions null Wetten frei. Lockert man das Historienfenster so weit, dass Signale durchkommen, sind es 49 Wetten mit −14,53 % Rendite.
Das ist kein Fehler, sondern der Beweis, dass die Gates funktionieren. Auf dieser Welt stellt der Buchmacher seine Preise aus derselben Wahrheit wie die Spiele, mit weniger Rauschen als das Modell schätzen kann — das Modell soll hier keinen Vorsprung haben, und es hat keinen. Der Brier-Score liegt mit 0,2609 knapp neben dem Markt (0,2500). Wer später Schwellen senkt, „damit endlich Tipps kommen“, erzeugt genau dieses Ergebnis.
Die Spec setzt recency_half_life_days = 120 und minimum_effective_sample = 20. Beides zusammen ist bei zehn multiplikativen Similarity-Dimensionen und zwei Saisons Historie praktisch unerreichbar: die effektive Stichprobe landet im Mittel bei 13,0. Der ESS-Deckel zieht dann die Confidence auf 65 % — unter das 72-%-Gate. Ergebnis: es wird nichts freigegeben, und zwar aus einem strukturellen, nicht aus einem inhaltlichen Grund.
Zum Vergleich: die Spec selbst nennt in Kapitel 9.4 als Beispiel „60 Candidate Matches ⇒ ESS 24,7“. Das entspricht 41 % Retention; erreicht werden 22 %. Die Sensitivitätstabelle im Dashboard zeigt vier Halbwertszeiten × zwei ESS-Schwellen auf identischem Walk-forward. Diese Schwellen sind eine Quant-Entscheidung nach dem Holdout auf echten Daten — laut Spec Kapitel 32 ohnehin ein offener Punkt. Wir haben sie nicht eigenmächtig geändert: Champion bleibt die Spec-Default-Config.
Der Aufbau ist bewusst so geschnitten, dass er heute nichts kostet.
| Dienst | Nutzung heute | Free-Tier-Grenze | Kosten |
|---|---|---|---|
| Pages (Hosting) | 1 Projekt, statische Assets | unbegrenzte Requests | 0 € |
| Pages Functions (API) | < 1.000 Requests/Tag | 100.000 Requests/Tag | 0 € |
| D1 (Datenbank) | 3,31 MB · 93k Zeilen gelesen/Tag | 5 GB · 5 Mio. Zeilen/Tag | 0 € |
| D1 Schreiblast | 66k Zeilen (voller Re-Seed) | 100.000 Zeilen/Tag | 0 € |
| Durable Objects | bewusst nicht genutzt | nur im Bezahlplan | 0 € |
Kein Durable Object für den Live-State. Die Spec verlangt in Kapitel 24.1 ein atomares Commit auf state_version. Statt eines DO (nur im Bezahlplan) macht das ein bedingtes UPDATE … WHERE state_version = ? in D1 — dieselbe Compare-and-Swap-Garantie, null Zusatzkosten. Bei hoher Live-Frequenz ist der Wechsel auf DO ein einzelner, isolierter Umbau.
Rally-Logs komprimiert. Ein Match hat ~165 Rallys. Als kanonische Zeilen wären das bei 1.922 Matches über 300.000 Schreibvorgänge — dreimal über dem Tageslimit. Der Lesepfad nutzt deshalb pro Match einen kompakten Blob mit 2 Bit je Rally (45 Byte statt 180 Zeilen); die kanonische rallies-Tabelle ist implementiert und wird für die Audit-Stichprobe befüllt. Der ganze Datensatz kostet dadurch 33.000 statt 300.000 Schreibvorgänge.
Erwartete Kosten im Echtbetrieb: Bei rund 20 Spielen pro Tag reicht der Free-Tier für Datenhaltung und API weiterhin aus. Was den Bezahlplan nötig macht, ist die Rechenlast: ein PRE-Model-Run mit 50.000 Pfaden braucht mehrere Sekunden CPU und passt nicht in die 10 ms des Free-Tiers. Mit Workers Paid (5 $/Monat) stehen 30 s CPU pro Aufruf und Queues zur Verfügung; 20 Spiele × 7 Snapshots ≈ 140 Läufe/Tag liegen deutlich innerhalb der enthaltenen Kontingente. Realistisch also 5 $/Monat für die Infrastruktur — die Datenlizenz wird ein Vielfaches davon kosten und ist der eigentliche Kostentreiber.
In der Reihenfolge, die die Spec in Kapitel 29 vorgibt — und die Reihenfolge ist wichtig, weil eine fertige Oberfläche fehlende Datenqualität gut aussehen lässt.
Konkret brauchen wir: Fixtures + Regelwerk, Endergebnisse und Satzstände, Point-by-Point mit Score und Rally-Gewinner, den Aufschläger je Rally, Aufstellungen mit Zeitstempel, sowie Pre- und Live-Quoten mit Zeitstempel. Ohne Server je Rally fällt das halbe Serve-/Side-out-Modell weg; ohne Quoten-Zeitstempel ist kein ehrlicher Backtest möglich. Zwei bis drei Anbieter mit Beispieldateien anfragen und gegen unsere Feldliste prüfen (Spec 5.2–5.5).
Mindestens zwei volle Saisons je Liga. Der Sequenz-Validator und der Quarantäne-Pfad laufen bereits — sie liefern beim ersten Import direkt die Antwort, ob die Daten tragfähig sind. Erwartungswert: 2–5 % der Spiele fallen aus. Deutlich mehr heißt: Anbieter wechseln.
Welches Buch, welche exakten Marktbezeichnungen, welche Settlement-Regeln bei abgebrochenen Spielen, welche Limits. Die Push- und Viertellinien-Logik ist gebaut, muss aber gegen das echte Regelwerk geprüft werden. Ohne das ist jede EV-Zahl Theorie.
Erst hier lässt sich beantworten, ob überhaupt ein Vorsprung existiert. Der Backtest ist fertig; er braucht nur echte Historie. Ergebnis dieses Schritts: die endgültigen Werte für Edge, EV, Confidence und das Historienfenster — die offene Entscheidung aus Abschnitt 3c. Vorher keine Schwellen „nach Gefühl“ anpassen.
Nightly Feature Build und die PRE-Model-Runs laufen aktuell offline als Node-Job. Für den Betrieb: Workers Paid aktivieren, die Läufe über Cloudflare Queues fächern (eine Nachricht = ein Model Run) und per Cron auf die Snapshot-Leiter aus Spec 24 legen. Der Code ist identisch — er läuft schon heute in beiden Umgebungen.
Echter Feed, echte Quoten, echte Signale — nur ohne Geld. Gemessen werden Latenz, Anteil veralteter Signale, Datenvollständigkeit, Kalibrierungsdrift und CLV. Die Spec macht das in Kapitel 28.3 zur Abnahmebedingung, und es ist der einzige Schritt, der nicht abgekürzt werden kann.
Bot-Token und Chat-ID als Secrets hinterlegen, Edit-/Delete-Verhalten für abgelaufene Live-Signale festlegen (Spec 26.2). Die Dedupe-Keys verhindern bereits Doppelsendungen. Erst nach bestandenem Shadow-Betrieb aktivieren.
Kleine Einsätze, ein Wettbewerb, tägliche Kontrolle von CLV und Kalibrierung. Staking bleibt laut Spec 18.3 ein getrennter Layer und ist ausdrücklich nicht Teil der Prediction Engine.
| Entscheidung | Warum sie jetzt gebraucht wird |
|---|---|
| Budget und Auswahl Datenprovider | Blockiert die Schritte 2–8 vollständig |
| Buchmacher und Marktumfang | Bestimmt Settlement-Regeln, Limits und ob die Quoten überhaupt handelbar sind |
| Ligen und Geschlechter in Scope | Männer und Frauen brauchen getrennte Baselines; jede Liga eigene Regel-Config |
| Freigabe Workers Paid (5 $/Monat) | Nötig, sobald die Model-Runs in die Cloud ziehen |
| Wer gibt Modelle frei | Champion/Challenger braucht einen benannten Verantwortlichen (Spec 32) |
Die Modell- und Backend-Arbeit ist gemacht und getestet. Der kritische Pfad zum Livegang führt jetzt nicht mehr über Code, sondern über Daten: Provider auswählen, Historie einlesen, auf echten Daten testen, im Shadow-Betrieb beobachten. Die Engine sagt heute schon ehrlich „kein Signal“, wenn sie keinen Vorsprung sieht — das ist die Eigenschaft, auf die es beim Echtgeld ankommt.