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 | create_pass | gate.pass_created in audit log |
| OTP / QR verified | verify_pass, verify_pass_qr | approved event in gate_events |
| Walk-in logged | request_walkin_approval | gate.walkin_requested; approval_requested event |
| Resident approved | approve_visit | gate.approved; approved event |
| Resident denied | deny_visit | gate.denied; denied event |
| Entry / exit | log_gate_event | 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_can_operate— 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