Rider Score Overview

Levy Rider Score is a per-rider safety reputation system. Every completed trip is scored 0-100, those trip scores roll into a 90-day weighted profile, and the result drives both rewards (wallet credits, discounts, priority access) and interventions (warnings, throttle caps, price uplifts, lockouts).

The system is per-subaccount and off by default. When you turn it on, scoring runs in the background on your existing ride-end pipeline. No new hardware, no extra rider friction.

What it does

1. Scores every completed ride using GPS, zone events, throttle position, and violations data you already collect.
2. Maintains a rolling 90-day rider score with a 30-day halflife - recent rides count more.
3. Sorts riders into tiers (Platinum, Gold, Silver, Bronze, At Risk, Beginner) and grants tier-appropriate perks.
4. Runs a 7-step intervention ladder when scores drop, escalating from a nudge to a permanent ban.
5. Issues all rewards through the existing wallet credit pipeline - no direct wallet writes, full audit trail.

What it does not do

• It does not duplicate the Violations module. Rider Score reads violations, it never writes them.
• It does not score the fleet or operator (that is a different product idea).
• It does not currently share scores across subaccounts. A rider's score on Operator A is invisible to Operator B.
• It does not run sidewalk-detection computer vision in v1. That signal is plumbed at weight zero until our CV pipeline ships.

Why this matters

Phased capabilities

How scoring runs

When a ride ends:

1. The existing ride-end pipeline fires.
2. An async job in the rider-score service pulls GPS samples, zone events, throttle frames, and any open violations.
3. A per-trip score is written to ride_safety_signals (with the exact weights snapshot, so historical scores stay reproducible).
4. The rolling rider score is recomputed and upserted.
5. If the score crossed a tier boundary, a reward grant or an intervention is queued.
6. The rider gets a push notification with their new score and the top contributor to it.

Failures in the rider-score subsystem never block a ride from ending. The integration is soft-fail by design.

Reward and intervention pipeline

All wallet credits flow through the existing ride-refund pipeline. Specifically:

• A rider_score_rewards row is inserted (pending).
• A ride_refunds row is created.
• creditWalletForRefund() issues the wallet credit against that refund row.
• The reward row is finalized with linked ids.

This is non-negotiable. We never write wallet_balance directly or insert raw wallet_transactions. The same discipline that protects refund accounting protects Rider Score reward accounting.

Privacy and fairness commitments

• Transparency. Riders see their own score, full breakdown, and the weights used to compute it. No black box.
• Right to correction. Every rider can file an appeal on any trip score. SLA is 7 days, operator-configurable.
• Reaction-time test framing. The late-night reaction test is a "Safe Ride Check," not a sobriety or DUI test. Results are never shared with law enforcement except by warrant.
• Selfie storage. Helmet selfies live in a private bucket and are deleted 30 days after their TTL expires unless they are attached to an open dispute.

---