Parking-Pose Validation
Parking-pose validation grades the photo your rider takes at the end of every ride. Instead of just storing it, the classifier checks four things — is the vehicle upright, is it inside the parking zone, is it blocking the sidewalk, and is the photo clear enough to tell. Each fail can carry a reparking fee, and the rider can appeal with a second photo. This article explains how to configure it and how the results land in your dashboard.
What the classifier checks
Levy Vision's parking-pose classifier looks at the photo and returns a structured judgement:
- Pose —
upright,tipped,fallen, orunclear - Upright — boolean, the overall verdict on whether the vehicle is standing
- In zone — boolean, derived from the rider's GPS at end-of-ride compared to your geofenced parking zones
- Blocking sidewalk — boolean, the model's best guess on whether the vehicle is in the pedestrian path
- Status —
pass,fail,retake, or one of the appeal states
Anything other than a clean upright-in-zone-not-blocking photo logs an event. What you do with that event is up to your configuration.
Operator settings
Open Dashboard > Safety > Safety settings. The Parking-pose validation section has three controls.
Parking validation enabled
The master toggle. Off means the photo is still collected (as it always was) but never graded. On runs the classifier and writes a row to parking_validations for every ride end in this subaccount.
Classifier
Two options:
| Classifier | Cost | When to choose |
|---|---|---|
| Gemini (default) | Included | Good enough for nearly every fleet. Latency is ~3 seconds. |
| Captur.ai | Premium add-on | Higher accuracy on edge cases, dedicated parking model. Requires a Captur.ai agreement. See Vendor setup. |
You can switch classifiers at any time. The events feed shows the source column so you know which model produced each result.
Reparking fee
Set in cents. Default 500 (= $5.00). This is the amount auto-applied to the rider's wallet on a high-confidence fail. Set to 0 to log fails without charging anyone — useful for the first week of pilot while you eyeball the model.
Fee is applied via the ride
The reparking fee is added to the ride's fare, not credited or debited directly to the wallet. This keeps net-deposited and partner-payout math correct. If you ever need to reverse a fee, do it through Adjust fare on the ride, not by editing the wallet.
What each result triggers
| Result | Confidence | What happens |
|---|---|---|
| Upright, in zone, not blocking | high | Ride ends cleanly, event logged as pass |
| Tipped or fallen | high | Reparking fee applied, event flagged for review |
| Out of zone | high | Reparking fee applied, event flagged for review |
| Blocking sidewalk | high | Reparking fee applied, event flagged for review |
| Any of the above | medium | Rider prompted to retake the photo (no fee yet) |
| Unclear / classifier flake | low | Optimistic pass, event logged with inference_failed, queued for operator review |
The retake path is important. About 5–10% of photos are unclear because of glare, motion blur, or the rider's thumb on the lens. Retaking is friction-free for a real, well-parked vehicle.
The rider appeal flow
After a high-confidence fail, the rider sees a screen with:
- Their original photo
- The classifier's verdict (e.g., "We think your scooter is tipped over")
- The fee that was applied
- Appeal and Accept fee buttons
If they tap Appeal, they're prompted to take a second photo from a different angle. That photo is uploaded and a parking_validations row is updated with status='appealed' and the new photo URL.
The event lands in your Safety > Parking reviews queue. Read Reviewing parking appeals for the operator side.
If the appeal isn't resolved within 48 hours, the system auto-routes to a refund. The refund flows through the ride's adjust-fare endpoint, so net-deposited and any partner payout stay correct.
Reading parking events
Go to Safety > Events and filter by event type parking_pose, or open Safety > Parking reviews for just the appealed and unresolved ones.
Each row shows the ride, the rider's verdict status, the model's confidence, the photo (signed URL), and the fee applied if any. Click any row to see:
- All four photo URLs if appeal was filed (original + 1-3 appeal photos)
- Full classifier payload including the issue codes the model flagged
- Side-effect log (fee applied row from
cv_violation_actions)
Tuning thresholds for your fleet
Out of the box, the classifier is conservative — it would rather mark a borderline tip as retake than slap a $5 fee on a rider who probably did fine. If you want it tighter or looser:
- Run with fee = $0 for two weeks, watch the false-positive rate
- Use Flag false positive on any event you'd dispute as the operator
- After two weeks, look at the flag rate. Under 2% means you can confidently turn the fee on; over 5% means tell support so we can review your fleet's tuning
Common questions
Will riders abuse the appeal flow?
In pilot data, fewer than 8% of fee'd rides get an appeal, and over 90% of appeals are denied because the second photo confirms the issue. The retake friction filters out the casual disputers.
What if the rider can't take a second photo (dead phone, etc.)?
The appeal window stays open for 30 days. They can appeal next time they open the app. Fees that haven't been disputed convert to settled after the 30-day window.
Does this work on bikes and e-bikes, not just scooters?
Yes. The classifier was trained on scooters, bikes, e-bikes, and mopeds. Mopeds with kickstands are the trickiest case — they read as "tipped" if the kickstand is at an aggressive angle. Watch the false-positive rate on moped subaccounts specifically.