PolyTraderSharp/docs/archiv/konzepte/KONZEPT-Modul-DataDriven.md

Konzept: Eigenes datengetriebenes Trading-Modul („DataDriven")

Stand: 2026-07-11 Status: KONZEPT (noch kein Umsetzungsplan). Ziel: ein Strategiemodul, das eigene Handelsentscheidungen aus externen Datenquellen ableitet — je Marktkategorie eine eigene Datenquelle + ein eigenes Fair-Value-Modell. Die Datenanbindung wird so gebaut, dass das ResolutionFarming sie mitnutzen kann (State-aware-Filter, C-S2).

---

1. Grundidee

Alle bisherigen Module leiten Signale von ANDEREN ab (Master-Trades, Marktpreise). DataDriven dreht das um: Wir berechnen aus Rohdaten eine eigene faire Wahrscheinlichkeit und handeln nur, wenn der Marktpreis deutlich davon abweicht:

FairValue(Markt) aus Datenquelle → Vergleich mit Marktpreis (Bid/Ask)
→ |FairValue − Preis| > MinEdge (nach Fees) → Order (Maker bevorzugt) → Halten bis Resolution/Ziel

Der Edge kommt nicht aus Geschwindigkeit, sondern daraus, die Daten besser/ konsequenter auszuwerten als der Durchschnitts-Teilnehmer der jeweiligen Kategorie. Deshalb ist die Kategorien-Wahl die wichtigste Entscheidung dieses Moduls.

2. Architektur (fügt sich in die bestehende Modul-Landschaft)

PolyTrader.Modules.DataDriven (IPolyTraderModule, DbPrefix dd_)
│
├── Core-Beitrag (geteilt, auch für ResolutionFarming nutzbar):
│     IMarketStateProvider          // je Kategorie: liefert konservative
│     {                             // Wahrscheinlichkeits-Schätzung + Zustand
│        bool Supports(MarketData m);
│        Task<MarketStateEstimate?> EstimateAsync(MarketData m, CancellationToken ct);
│     }
│     record MarketStateEstimate(decimal ProbLowerBound, decimal ProbUpperBound,
│                                string StateSummary, DateTime AsOf, string Source);
│
├── Provider (je Kategorie ein Adapter, einzeln aktivierbar):
│     WeatherStateProvider          // Open-Meteo/NOAA-Modelläufe
│     SportsScoreStateProvider      // Live-Scores (z. B. API-Football)
│     CryptoStrikeStateProvider     // Binance-Spot + realisierte Volatilität
│     MacroStateProvider            // Nowcasts/Konsensdaten (CPI, Zinsen)
│
├── Services:
│     DdScannerService              // Märkte je aktiver Kategorie laden, FairValue
│                                   // berechnen, Kandidaten mit Edge persistieren
│     DdExecutionService            // Sizing/Limits (Muster: FarmingRiskEngine/
│                                   // Planner wiederverwenden!), Maker-first
│     DdPositionMonitorService      // Re-Evaluation offener Positionen: dreht der
│                                   // FairValue, wird der Exit geprüft (Leiter-Muster)
│
└── Persistenz: dd_settings / dd_candidates / dd_positions / dd_closed_trades
      (Kopie des bewährten rf_-Schemas; Autoincrement-IDs, Kalibrierungs-Historie)

Wichtige Wiederverwendung: Risk-Engine, Execution-Planner, Fill-Modell, Resolution-Monitor und UI-Aufbau des ResolutionFarming sind fast 1:1 übertragbar — DataDriven ist strukturell „ResolutionFarming mit eigener Signalquelle statt Preisband-Scan". Der Unterschied: DataDriven darf auch UNTER 0.90 kaufen (überall, wo FairValue ≫ Preis) und optional vor der Resolution verkaufen, wenn der Edge realisiert ist (Preis hat FairValue erreicht → Kapitalumschlag).

ResolutionFarming-Synergie (C-S2): Sobald ein IMarketStateProvider für eine Kategorie existiert, nutzt ihn auch der RF-Scanner: Ein Preis-Dip wird nicht mehr pauschal gemieden (Momentum-Filter), sondern gegen ProbLowerBound geprüft — Richards 5:1-in-Minute-80-Beispiel wird damit zur Kaufgelegenheit statt zum Reject.

3. Kategorien-Bewertung: Wo lohnt sich ein eigenes Modell?

Bewertung nach: Datenlage (frei/billig verfügbar?), Modell-Komplexität, Bot-Konkurrenz (Stand 2026), Fee-Satz, Kapitalbindung.

Kategorie	Datenquelle (Kosten)	Modell	Bot-Konkurrenz	Fee	Bindung	Urteil
Wetter (Tages-Märkte: Temperatur/Niederschlag je Stadt)	Open-Meteo/NOAA/ECMWF-Läufe (kostenlos)	Modell-Konsens vs. Marktpreis; Update-Lag nutzen	moderat, wachsend — Edges von ~10 Pp (2023) auf ~3 Pp (2026) komprimiert, aber vorhanden; dünne Bücher, wenig Retail	1,25 %	Stunden–Tage	✅ Bester Einstieg
Wetter (Saison: Hurrikane, Rekorde)	wie oben + NHC	aufwendiger	gering (Kapital-Lockup schreckt ab)	1,25 %	Wochen–Monate	⚠️ später (Bindung)
Sport pre-game (kleinere Ligen)	API-Football o. ä. (~20–30 $/Mon.)	Elo-/Quotenvergleich vs. Buchmacher-Konsens	groß in Top-Ligen, moderat in Nebenligen	0,75 %	Stunden–Tage	✅ zweiter Kandidat
Sport live (State-Provider)	wie oben, Live-Scores	Score+Restzeit → P(Sieg), konservative Untergrenze	hoch (Latenz-Bots) — aber wir brauchen nur EINEN Fill unter FairValue, nicht den schnellsten	0,75 %	Minuten–Stunden	✅ als RF-Filter; als eigene Strategie nur eng begrenzt
Krypto-Strikes (Wochen/Monat: „BTC über X am Y")	Binance-WSS (kostenlos)	Distanz zum Strike + realisierte Vol → P	hoch bei 15-min/Stunde, moderat bei Wochen-Strikes	1,8 % ⚠️	Tage–Wochen	⚠️ Fee frisst viel; nur bei großem Modell-Edge
Makro (CPI, Zinsentscheide)	Cleveland-Fed-Nowcast, Konsens-Schätzungen (frei)	Nowcast vs. Marktpreis	moderat, aber informierte Gegenseite	1,5 %	Tage–Wochen	⚠️ Nische, wenige Märkte
Politik-Longtail (Nicht-Headline)	Polls/Aggregatoren	Poll-Modell	gering im Long Tail	1,0 %	Wochen+	⚠️ Bindung + Resolution-Risiko
Kultur/Awards/Mentions	Box-Office-Daten teils frei; sonst dünn	schwach	gering	1,25–1,56 %	variabel	❌ Resolution-Risiko (AI-Rater Pflicht), Datenlage schlecht
Krypto 15-min/1h Up-Down	Binance	Latenz	extrem (Sub-100-ms-Bots)	1,8 %	Minuten	❌ nicht unser Spiel

Antwort auf „nicht geflutete Kategorien": Am wenigsten Bot-dominiert sind 2026 (a) Wetter — dünne Bücher, Nischenwissen (Stations-Regeln, Modell-Läufe), Retail meidet die Kategorie; (b) Long-Tail-/Nebenliga-Sport pre-game; (c) Makro- Nischen und (d) Long-Tail-Politik. Geflutet sind: Krypto-Kurzfrist, Top-Sport in-play, Headline-Elections, Arbitrage/NegRisk-Rebalancing. Faustregel: Bots meiden Kapitalbindung und Nischenwissen — genau dort liegt unser Fenster.

4. Empfohlener Aufbau-Pfad

1. Phase DD-0: IMarketStateProvider-Contract in Core + Modul-Skelett (rf_-Schema kopieren). Kein Provider aktiv.
2. Phase DD-1 (Wetter, read-only): WeatherStateProvider (Open-Meteo, tägliche Temperatur-Märkte 2–3 US-Städte). Scanner läuft wochenlang read-only: FairValue vs. Marktpreis loggen → misst den real verbliebenen Edge, bevor irgendetwas gehandelt wird (dasselbe Kalibrierungs-Gate-Prinzip wie RF).
3. Phase DD-2: Demo-Execution (Planner/Fill-Modell aus RF), 4 Wochen.
4. Phase DD-3: SportsScoreStateProvider — zuerst NUR als RF-Filter (C-S2: Dip-Freigabe bei klarer Führung), erst danach als eigene DD-Strategie.
5. Phase DD-4: Live klein (eigener Account, wie bei RF), dann weitere Provider nach gemessenem Edge.

5. Risiken dieses Moduls (ehrlich)

1. Modell-Risiko ersetzt Master-Risiko: Ein Bug/Bias im Fair-Value-Modell produziert systematisch falsche Trades. Gegenmittel: read-only-Messphase je Provider (DD-1-Prinzip), konservative Untergrenzen statt Punktschätzern.
2. Edge-Kompression: Der Wetter-Edge ist dokumentiert am Schrumpfen (10→3 Pp). Read-only-Messung VOR jedem Livegang, und die Bereitschaft, eine Kategorie wieder abzuschalten, wenn die Messung < MinEdge zeigt.
3. Regel-Fallen: Wetter-Märkte lösen nach exakten Stations-Regeln auf — der AI-Auflösequalitäts-Rater (separater Plan) und das genaue Lesen der Regeln je Markt-Serie sind Pflicht (welche Station, welche Rundung, welcher Zeitraum).
4. Aufwand: Jede Kategorie ist ein eigenes kleines Forschungsprojekt. Deshalb: strikt eine Kategorie nach der anderen, jede mit eigenem Go/No-Go-Gate.

6. Quellen (Kategorien-/Konkurrenz-Einschätzung)

• Polymarket Weather/Climate-Kategorieübersichten (Volumen/Marktzahl): https://polymarket.com/predictions/weather, https://polymarket.com/predictions/climate
• Weather-Bot-Funktionsweise & Edge-Kompression 2023→2026: https://laikalabs.ai/prediction-markets/polymarket-weather-trading-bot
• Markt-Mikrostruktur/Tiefe Wetter-Märkte: https://polymart.app/blog/polymarket-weather-markets, https://polymarkets.co.il/en/guide/weather-guide/