Opportunities: Wiki Knowledge Applicable to Localz — Incremental Pass, 2026-08-11
Scope: prior passes through 08-10 covered the AWS hybrid multi-tenant case study against Localz's named multi-city expansion gap. This pass checks the new Architecture/Challenges audit-log note against Localz's own existing (but underspecified) audit-log and dispute-handling plans.
Localz already names "audit log" as a requirement in three separate places but has never designed it against the two guarantees an audit log actually needs
Localz.md mentions audit logging or audit trails in at least four places: the PostgreSQL datastore rationale (line 119, "bookings, payments, users, KYC, payouts, reviews, disputes, audit trails"), the Phase 0 messaging security must-haves ("audit log for every message/meta change"), the AWS swap-in table ("Mongo audit collection → CloudWatch Logs + S3 Lake"), and the baseline NFRs ("SSO, audit logs, error tracking"). In every case it's named as a checkbox item — something the system should have — with no design behind what "audit log" actually guarantees. This window's audit-log Challenge note (written for a capital-markets platform, but the model solution generalizes to any dispute-bearing marketplace) names the exact gap: "must be auditable" is not one requirement, it's at minimum two separable guarantees — durable emission (no state-changing action is ever silently missed, solved by writing the audit record atomically with the state change rather than as an afterthought) and tamper-evidence (a record can be proven not to have been altered after the fact, solved with hash chaining, not just database access control).
This matters concretely for Localz specifically because of the OTP-based payment-completion flow (Functional-Requirements.md, cited in Localz.md §3): cash payments start and end on OTP exchange between provider and consumer, and disputes over "did the service actually happen, and when" are explicitly a named risk (dispute rate is even tracked as a go/no-go KPI, Localz.md line 275, "dispute rate ≤3%"). A dispute over a cash-payment OTP exchange is exactly the scenario where "can we prove this record wasn't altered after the fact" stops being a compliance nicety and becomes the actual mechanism that resolves a provider-vs-consumer disagreement — and Localz's current plan (a Mongo audit collection later swapped for CloudWatch Logs + S3) gives durable storage but says nothing about tamper-evidence at all; a bad actor with database access (an insider, or a compromised admin credential) could edit a disputed OTP-timing record with nothing in the current design to detect it.
Concrete next step: before Phase 0 messaging's "audit log for every message/meta change" gets implemented, apply the Challenge note's hash-chain pattern (each audit record's hash depends on the prior record's hash) to at minimum the OTP start/end events and any dispute-relevant status transition — this is a small addition to an already-planned Mongo collection, not new infrastructure, and directly strengthens the dispute-rate KPI Localz is already tracking as a launch metric.