Operations2026-06-07 · 1 min read
Visitor Gate Audit Trail & Compliance for Societies
P
Plinth
Plinth
Cover image · 1280 × 640
Visitor gate audit trail and compliance
Every state change on Plinth visitor passes goes through audited RPCs not direct client writes to visitor tables. The gate_events table and append-only audit_log give committees a searchable record when security incidents or neighbour disputes arise.
What gets logged
| Action | RPC | Audit / events |
|---|---|---|
| Pass created | visitor pass creation | gate.pass_created in audit log |
| OTP / QR verified | pass verification (OTP or QR) | approved event in gate_events |
| Walk-in logged | walk-in approval request | gate.walkin_requested; approval_requested event |
| Resident approved | visit approval | gate.approved; approved event |
| Resident denied | visit denial | gate.denied; denied event |
| Entry / exit | gate event log | gate.entry / gate.exit; matching gate_events row |
Each row records who acted (guard, resident, or admin), which pass, and when.
Why committees care
- Security incidents "Did an unknown person enter Block B on Tuesday evening?"
- Vendor disputes Prove whether a contractor was on premises during a damage claim
- Delivery complaints Confirm whether a courier was logged entered before a theft report
- AGM questions Show the committee upgraded from paper registers to auditable digital logs
- Bye-law hygiene Visitor records sit alongside voting and notice audit trails on one platform
Access control
- Residents see passes they created or walk-ins pending for their flat
- Guards and society staff operate Gate desk via gate access check verify, walk-in, entry/exit
- Admins have full visibility within their society
- Cross-society reads are blocked by RLS the cross-tenant security model applies to gate data too