About the History Log

Sign-ins (both email/password and Google), sign-outs, password resets, two-factor enrollment and challenges, role changes, residency approvals, exports of the history log itself, and — when the rest of the platform is wired in — meetings, minutes, elections, donations, grants, and 311 reports.

Each entry records who did the action, when (UTC), what action it was, which neighborhood or foundation it relates to, and any forensic context (IP address, browser).

You can always see the history of actions you yourself caused. Neighborhood admins and foundation board members can see the list of all actions in their own association — but the forensic detail (IP, browser, raw context) is hidden when the action belongs to someone else.

City auditors (the CRS Auditor role) and platform administrators can see everything across all tenants. That access is part of how the platform supports compliance with the Citizen Participation Plan and federal CDBG reporting requirements.

The history log is append-only at the database level. The database itself refuses to accept any UPDATE or DELETE on an audit row, regardless of whether an admin asks for it or a bug in the code requests it. That’s structural — even a compromised application can’t rewrite history.

This matters for civic accountability. When a vote or a fund disbursement is later disputed, the history log is the authoritative record. The 2022 Glen Iris VP election dispute is part of why this design is the way it is.

Authorized roles can download the full log (up to 10,000 events at a time) as CSV or JSON from the History log page. The download itself is also logged — every export is recorded as a SESSION_REVOKED-style entry naming who exported, when, and how many rows.