Principal-ready overview. Parents control student identification. Schools only see student names when parents opt in. Parent contact information is never exposed. All school actions are audited.
Every table enforces row-level security in the database. Even with a valid login, the database refuses to return rows that don't belong to that user's role and school.
Parents, school staff, and school admins each have distinct roles stored in a separate, tamper-resistant table. Roles are checked by the database — not by the browser.
All traffic is HTTPS. Credentials are never stored in plain text. API keys for SMS and maps are held server-side only.
School staff cannot see a rider's real name unless the parent has explicitly turned on school identification for that rider.
Every school-staff action — viewing a rider's record, issuing a violation, authorizing a bike lock, lifting a campus restriction — writes an immutable entry to the audit log with the actor, role, timestamp, and the affected rider or bike.
Parents can see every action taken against their own rider's record. School admins can review every action taken at their school. Audit entries cannot be edited or deleted by any signed-in user.
Anyone with a bike's QR code can submit a parking or safety complaint without logging in. This is intentional — it's how community members report issues. Submissions only attach to that specific bike and are reviewed by school staff before any action.
Photos attached to complaints live in a read-only public bucket so school staff and the bike's parent can view them directly from an SMS link. Links are random and not listable from the browser; uploaders and staff are the only roles allowed to delete or modify them.
Schools in the pilot share the same RideBeacon scoring weights so outcomes are comparable across campuses. Per-school configuration is intentionally not exposed in the dashboard during the pilot.