Privacy & data handling
This statement describes how the Sokano Rec demonstration build (RFI-26-24-REC) handles data. It is written for the demo as it actually runs — not as marketing.
What this system stores
- Account data: name, email, a salted scrypt password hash (never the password itself), and an optional mailing address.
- Recreation records: program registrations (participant name, status, fee paid), facility reservations, membership passes, and check-in timestamps.
- Residency verification: a verified/not-verified flag, the verification date, and which staff member verified with which document type. The document itself is never uploaded or stored.
- Payments (PCI SAQ-A posture): only the card brand, last four digits, and expiry month/year. Full card numbers never touch this system — payment pages are hosted by the processor (Stripe, test mode only in this demo).
- Operational logs: an append-only audit trail of staff actions (residency changes, refunds, reservation cancellations) and an outbound-notification log.
Who can see what
- Residents and visitors see only their own account, registrations, and passes.
- Staff and administrator roles are required for rosters, residency records, payments, reports, the audit log, and the notification outbox. Every staff page re-checks the session on the server; the CSV export and server actions enforce the same role checks independently of the UI.
- Staff actions that touch personal data are recorded in the audit log with the acting staff member's email.
Retention
Everything in this build is demonstration data and is routinely reset; nothing entered here is treated as a system of record. A production deployment for the City would carry a written retention schedule agreed with the City Clerk (typically aligned to the Colorado Municipal Records Retention Schedule) before go-live.
Questions
Demo operator: Jordan Damhof — jordandamhof@gmail.com. Venue context: Bob L. Burger Recreation Center, 111 W. Baseline Rd, Lafayette, CO 80026.