Troubleshooting Levy Vision

This article is your first stop when something looks wrong. The diagnoses below cover the most common issues across helmet, parking, and sidewalk-detection. If nothing here resolves it, contact support with the relevant event IDs.

Helmet selfie never appears for riders

The rider taps Unlock, but no selfie screen shows.

Check the subaccount toggle

1. Open Dashboard > Safety > Safety settings.
2. Confirm you're on the correct subaccount in the switcher.
3. Verify Helmet check enabled is on. Save if you toggled it.

Check the AXA bypass

If the vehicle has an AXA helmet lock and the rider just unlocked the helmet (within 60 seconds), the bypass automatically skips the selfie. Look for an event with status='bypassed' in Safety > Events. If you see one, the system is working as designed.

Check the rider's app version

The helmet selfie screen ships with rider app version 1.8.0 and later. If the rider is on an older version, push them to update. The app store usually has the latest within a day of release.

Check the IL consent toggle

If the rider's billing address is Illinois and they haven't accepted the BIPA consent toggle in their account settings, the selfie flow is skipped. Have them open the rider app, go to Profile > Privacy, and accept the toggle.

Helmet selfie shows but always fails

The rider takes a clean selfie wearing a helmet, but the result is always fail.

Check confidence

Open Safety > Events, find the failed event, click the row. Look at the inference reasoning string. Common issues:

• "low_light" — the rider is in dim conditions. They need to move to better light.
• "face_occluded" — the helmet sits too low on the brow. Common with full-face helmets.
• "headwear_not_helmet" — the model thinks it's a hat. Some commuter helmets look hat-shaped to the model.

For the last case, flag the event as a false positive. The model learns from those flags over time.

Try strict mode off

If you have Strict mode on and the rider can't get past the screen, temporarily flip strict off (Safety > Safety settings), have the rider retry, then flip strict back on. With strict off, an ambiguous event still lets the ride start, which unblocks the rider while you debug.

Check Gemini status

If many riders across many fleets are failing, our Gemini provider may be down. Check Sentry for helmet_classifier_inference_failed errors. If you see a spike, fail-open is on (inference_failed events still start the ride), so riders should not be blocked.

Parking-pose results never appear

The rider takes the end-of-ride photo, but no row appears in Safety > Parking reviews or Safety > Events.

Check the subaccount toggle

In Safety > Safety settings, confirm Parking validation enabled is on. Off means the photo is collected but not graded.

Wait a few seconds

The classifier can take up to 5 seconds on Gemini and longer on Captur (async). Give it a minute, then refresh.

Check the photo

If the photo is corrupted (network drop mid-upload), no inference runs. Look in the ride detail for the parking photo. If it's missing or broken, the rider should retake — there's a "Retake parking photo" option in their app for the most recent ride.

Check the storage bucket

The cv-evidence bucket needs to exist with private access and signed-URL reads. If it's been deleted or its policies were changed, classification fails silently. Contact support if you suspect this.

No sidewalk events are flowing

You installed vendor hardware, provisioned devices, and expected events to appear — but Safety > Events has no sidewalk_entry rows.

This is the most common issue. Work through it in order:

Confirm the device is mapped

Open Safety > Vendor devices. The device serial must be in the list and linked to a real vehicle. If it's missing, the webhook fires but we can't attribute it.

Confirm enforcement is on

In Safety > Safety settings, verify Sidewalk detection enabled is on. With it off, events still log but the dashboard hides them by default. Use the "Show all event types" filter on the events page to verify.

Confirm webhook reaches us

In the vendor's dashboard, find the "webhook delivery log" or equivalent. Look for delivery attempts to our URL. They should be 200 OK. If they're 401, the signature is wrong — check the Webhook signing secret in safety settings.

If they're timing out (504), our endpoint may be slow under load. Sentry will have caught it; contact support.

Confirm signature scheme

Drover uses t=<ts>,v1=<hex> HMAC-SHA256. Luna uses flat hex HMAC-SHA256. If the vendor is signing with a different scheme (some have older endpoints), we'll reject. Get the vendor to confirm scheme.

Confirm there's a ride

We attribute sidewalk events to the current ride for the vehicle. If the vehicle is idle (no active ride), the event is logged but not enforced, and may not show in the rider-facing UI. Check Safety > Events with the "vehicle: idle" filter on.

Throttle cut didn't fire

You expected a vehicle to be throttled-off after the threshold but the rider kept riding.

Check the threshold count

Open the ride. Count the sidewalk events. If the rider had 2 events and your Cut threshold is 3, no cut should fire. Confirm thresholds in safety settings.

Check throttle cut master switch

Throttle cut enabled is a separate master toggle from the threshold. If it's off, no cut fires regardless of threshold.

Check the protocol

Some IoT protocols don't support mid-ride throttle disable. Look at the vehicle's iot_type. If it's acton-legacy, throttle cut is not supported — only warn fires. See the OEM compatibility matrix in Throttle-cut policy.

Check the IoT command log

Open the ride detail. The "IoT commands" section should show a disable_throttle attempt with reason cv_sidewalk_repeated. If it's missing, the policy engine didn't fire — check the events feed for a cv_violation_actions row.

If the command was attempted but failed (queued + timed out), the vehicle was offline. The policy engine retries for 60 seconds, then gives up.

Throttle won't restore

A rider was cut and now can't get throttle back even after tapping I'm back on the road.

Check telemetry

The restore endpoint requires 30 seconds of clean telemetry (no sidewalk events). If the rider is still on a sidewalk according to the vendor, the restore is denied. Look at the events feed for the ride.

Check the IoT path

If the vehicle is offline, the enable command can't reach it. Wait for the vehicle to report back, then have the rider retry.

Manual restore

If you need to override, open the event in Safety > Events and click Restore throttle. The dashboard issues enableVehicleThrottle() directly, bypassing the telemetry check.

Latency feels slow

Riders complain helmet selfie or parking validation takes too long.

Check the latency chart

The Safety > Overview page has p50 and p95 latency for each capability. Spec target:

• Helmet: 2s p50, 4s p95
• Parking (Gemini): 3s p50, 6s p95
• Parking (Captur): async, no rider wait

If you're consistently above these numbers, contact support.

Check rider cellular

Most "slow inference" reports are slow uploads. The classifier itself takes 1–2 seconds; the rest is image upload and network round-trip. Riders on poor connections see the lag.

False positives are too high

Riders are getting cut or fined when they shouldn't be.

Use Flag false positive

Every false positive should be flagged on the event row. This feeds the model improvement pipeline. Don't skip this step.

Raise thresholds

In safety settings, raise the warn / speed-reduce / cut thresholds by one. The model isn't changing, but the policy engine becomes less aggressive.

Add geofence allow-list

Sidewalks that aren't really sidewalks (protected bike lanes, plazas) — add a kind=allow polygon in Sidewalk hotspots.

Escalate to support

If your false-positive rate is above 5% after a week of tuning, that's a signal the model is poorly calibrated for your geography or vehicle mix. Tell support — we can adjust per-subaccount confidence floors.

Still stuck?

Open a support ticket from the help center or email support@levyelectric.com. Include:

• Subaccount ID
• A specific event ID (from the events feed)
• What you expected vs what happened
• Time range of the issue