Uberblick Fahrer-Score

Levy Rider Score ist ein Reputationssystem fur Fahrer-Sicherheit. Jede abgeschlossene Fahrt erhalt eine Bewertung von 0-100, diese Bewertungen werden zu einem gewichteten 90-Tage-Profil zusammengefasst, und das Ergebnis treibt sowohl Belohnungen (Wallet-Gutschriften, Rabatte, vorrangiger Zugang) als auch Interventionen (Warnungen, Drosselbegrenzungen, Preisaufschlage, Sperren) an.

Das System ist pro Subkonto konfigurierbar und standardmassig deaktiviert. Wenn Sie es einschalten, lauft das Scoring im Hintergrund Ihrer bestehenden Fahrtende-Pipeline. Keine neue Hardware, keine zusatzliche Reibung fur den Fahrer.

Was es tut

1. Bewertet jede abgeschlossene Fahrt anhand von GPS, Zonen-Ereignissen, Drosselposition und Verstossen, die Sie bereits erfassen.
2. Pflegt einen rollierenden 90-Tage-Fahrer-Score mit 30-Tage-Halbwertszeit - aktuelle Fahrten zahlen mehr.
3. Ordnet Fahrer Stufen zu (Platin, Gold, Silber, Bronze, Risikofahrer, Anfanger) und gewahrt entsprechende Vorteile.
4. Fuhrt eine 7-stufige Interventionsleiter aus, wenn Scores fallen - vom Hinweis bis zur dauerhaften Sperre.
5. Stellt alle Belohnungen uber die bestehende Wallet-Gutschrift-Pipeline aus - keine direkten Wallet-Schreibvorgange, vollstandige Prufspur.

Was es nicht tut

• Es dupliziert nicht das Verstoss-Modul. Rider Score liest Verstosse, schreibt sie nie.
• Es bewertet nicht die Flotte oder den Betreiber (das ist eine andere Produktidee).
• Es teilt Scores derzeit nicht zwischen Subkonten. Der Score eines Fahrers bei Betreiber A ist fur Betreiber B unsichtbar.
• Es fuhrt in v1 keine Burgersteig-Erkennung per Computer Vision aus. Dieses Signal ist mit Gewicht null verdrahtet, bis unsere CV-Pipeline ausgeliefert wird.

Warum das wichtig ist

Stufen der Funktionalitat

Wie das Scoring lauft

Wenn eine Fahrt endet:

1. Die bestehende Fahrtende-Pipeline wird ausgelost.
2. Ein asynchroner Job im Rider-Score-Service zieht GPS-Stichproben, Zonen-Ereignisse, Drossel-Frames und offene Verstosse.
3. Ein Score pro Fahrt wird in ride_safety_signals geschrieben (mit dem genauen Gewichts-Snapshot, damit historische Scores reproduzierbar bleiben).
4. Der rollierende Fahrer-Score wird neu berechnet und gespeichert.
5. Wenn der Score eine Stufengrenze uberschritten hat, wird eine Pramien-Vergabe oder eine Intervention in die Warteschlange gestellt.
6. Der Fahrer erhalt eine Push-Benachrichtigung mit seinem neuen Score und dem wichtigsten Faktor.

Fehler im Rider-Score-Subsystem blockieren niemals das Beenden einer Fahrt. Die Integration ist Soft-Fail.

Belohnungs- und Interventions-Pipeline

Alle Wallet-Gutschriften fliessen durch die bestehende Fahrtenerstattungs-Pipeline. Konkret:

• Eine Zeile in rider_score_rewards wird eingefugt (ausstehend).
• Eine Zeile in ride_refunds wird erstellt.
• creditWalletForRefund() stellt die Gutschrift gegen diese Erstattungs-Zeile aus.
• Die Pramien-Zeile wird mit verknupften IDs abgeschlossen.

Das ist nicht verhandelbar. Wir schreiben niemals direkt in wallet_balance und fugen niemals manuelle wallet_transactions ein.

Datenschutz- und Fairness-Verpflichtungen

• Transparenz. Fahrer sehen ihren eigenen Score, die vollstandige Aufschlusselung und die verwendeten Gewichte. Keine Black Box.
• Recht auf Berichtigung. Jeder Fahrer kann zu jedem Fahrt-Score Einspruch einlegen. SLA betragt 7 Tage, pro Subkonto konfigurierbar.
• Reaktionstest-Rahmung. Der spatabendliche Reaktionstest ist ein "Safe Ride Check", kein Nuchternheits- oder DUI-Test.
• Selfie-Speicherung. Helm-Selfies leben in einem privaten Bucket und werden 30 Tage nach Ablauf der TTL geloscht.

---