Helmet Verification at Unlock

Helmet verification asks each rider to take a quick selfie before their ride starts. A vision model checks for a visible helmet, classifies the result with a confidence band, and decides whether to pass, ask for a retake, or block the unlock. This article covers the rider flow, the operator settings, the bypass paths, and how to read results.

How the rider experience works

1. The rider opens the app and picks a vehicle.
2. They tap Unlock.
3. The new Helmet selfie screen appears with a head-circle overlay. They line their face up and tap the shutter.
4. The photo is uploaded; the classifier returns a result in about 2–3 seconds.
5. One of three things happens:
   • Pass (high or medium confidence helmet visible) — unlock proceeds as normal.
   • Retake (low confidence or no helmet detected) — the rider sees "Helmet required" with a retry CTA. They can try up to your max-attempts setting.
   • Ambiguous (low confidence either way) — behavior depends on strict mode. See below.

The classifier is forgiving on lighting and angle. It's tuned to recognize full-face, half-shell, novelty, and hijab-compatible helmets, plus standard cycling and skate helmets.

Operator settings

Open Dashboard > Safety > Safety settings. The Helmet verification section has three controls:

Helmet check enabled

The master toggle. With it off, no helmet selfie is requested and no events are logged. With it on, every unlock in this subaccount goes through the selfie flow.

Strict mode

This controls what happens on a low-confidence inference, on inference failure (Gemini timeout or 5xx), and after max-attempts retries.

We recommend running with strict mode off for at least your first week of pilot. Watch the Helmet compliance page, look at the ambiguous and inference-failed rates, and only flip to strict once you're confident the classifier is well-tuned for your fleet.

Max attempts

Default 3. The rider gets this many tries before they hit the strict-mode block (or, with strict off, the ambiguous fallback). Most operators leave this at the default; raising it dilutes enforcement, lowering it frustrates riders in poor lighting.

The AXA helmet-lock bypass

If your vehicles have a hardware helmet lock (such as the AXA helmet locks shipped with several of our bike SKUs), Levy Vision can skip the selfie when the helmet is freshly unlocked.

How it works:

1. The rider unlocks the helmet lock from the app (existing flow).
2. The IoT command writes helmet_lock_state='unlocked' to the iot_commands metadata.
3. Within 60 seconds of that command, when the rider taps Unlock on the vehicle, the helmet selfie step is skipped automatically.
4. The event is logged with status bypassed.

This is on by default for any vehicle whose IoT device supports the AXA command set. There's no operator switch — if the hardware has it, the bypass works.

Reading helmet event results

Go to Safety > Helmet compliance for the trend view, or Safety > Events for the unified feed.

Each helmet event row shows:

• Ride — links to the ride detail page
• Status — pass, fail, ambiguous, bypassed, or inference_failed
• Confidence — high, medium, or low
• Attempts — how many selfies the rider took before the result was final
• Selfie — click to view the image (signed URL, 24-hour expiry)

Click any row to open the event drawer with the full inference payload, including the classifier's reasoning string and any issues it flagged ("face occluded", "low light", "headwear that isn't a helmet").

Flagging a false positive

If you spot an event where the rider was clearly wearing a helmet but got marked fail, click Flag false positive in the event drawer and choose a reason code. This:

• Marks the event in the operator log
• Feeds the labeled image back into the dataset we use to evaluate the classifier
• Counts toward the bias-evaluation rollups we publish quarterly

Don't worry about the rider's experience for that specific event — flagging is for future improvements, not retroactive ride correction. If the rider asks for a refund, handle it through the usual ride adjust-fare flow.

Privacy notes for riders

Helmet selfies are stored encrypted for up to 60 months in a private Supabase Storage bucket. They are NOT used for facial recognition or biometric template extraction — we only check whether a helmet appears in the frame. Riders in Illinois see an explicit BIPA consent toggle during onboarding before any selfie is requested.

If a rider requests deletion via the data-deletion flow, their selfies are purged from storage along with their other personal data.

Common questions

Why did my rider's clean selfie fail?

Most often: low light, helmet sitting too far back on the head, or a hat-shaped helmet (some commuter helmets). Check the inference reasoning string on the event row — the model usually tells you what it didn't like.

Can a rider refuse the selfie?

Today, no. They can refuse to ride (the unlock is blocked in strict mode). We're considering an opt-out higher-rate pricing path; see the FAQ.

How fast is the check?

P50 latency is around 2 seconds; p95 is around 4 seconds. If you see consistently slower numbers in your dashboard, check the Troubleshooting article for the latency-spike playbook.