Your residents’ data lives in your database, encrypted, and backed up where nobody can delete it.
City managers and county commissioners get asked hard questions in open session. These are the answers, and every one of them describes the software as it ships rather than a roadmap.
Isolation
Every jurisdiction runs on its own private database container. Your residents’ records are never co-mingled with another jurisdiction’s, so "who else is in that database" has a one-word answer.
Because the database is yours alone, a full export for a state audit or legal discovery is a single operation rather than a support ticket and a redaction project. You can ask for it at any time, including on your way out the door.
Encryption and the audit trail
Resident PII encrypted at rest
Names, emails, and phone numbers are encrypted in the database under a key unique to your jurisdiction — not stored as plain text that a stolen database dump would hand over intact.
Tamper-evident audit trail
Every status change and staff action is written to a hash-chained log that cannot be quietly edited after the fact. When a decision is questioned months later, the record answers for itself.
PII kept out of the logs
Application logs are sanitized before they are written, so resident details do not leak into the place nobody thinks to protect.
Staff sign in as themselves
Each staff member has their own login and password, sign-in attempts are rate limited and recorded, and a run of failures raises a warning to administrators. Single sign-on through Entra, Okta, Auth0, or any OIDC provider is available if your town wants it, and is not required.
Backups you can audit
Every night the platform takes a complete copy of your database, encrypts it on your own server before upload, and stores it in a bucket held in your name. Provider-side encryption is requested on every single upload rather than left to a setting somebody remembered to switch on, so two layers of encryption sit between the archive and anyone reading it, held by two organizations that share no key.
For a window set to your own records guidelines, those backups are immutable — enforced by the storage layer, not by our software. Ransomware that encrypts your live database cannot touch them, and neither can a stolen credential, a compromised server, or us.
A restore is rehearsed before a town goes live: a real archive is pulled back out of storage, decrypted, restored into a scratch database, and compared table by table against the live one. You get the output, with row counts, because a backup nobody has ever restored from is a hypothesis.
Retention, holds, and leaving
How long a closed request must remain producible comes from your state archives and your clerk. How many nightly database copies to keep is an operations question with no legal content at all. We keep the two apart, because tying them together means a five-year records schedule silently orders eighteen hundred full database copies that nobody decided on and nobody costed.
If your jurisdiction is served or enters litigation, one switch suspends every path that removes data — archiving, redaction of closed requests, and the pruning of old backups alike. Nothing is destroyed until the hold is lifted.
The storage account is yours, in your name, at any S3-compatible provider. Nothing in the design makes us hard to leave, which is deliberate: a vendor holding your only copy of the public record has leverage no municipality should hand over.
What the software does not do
It does not phone home. No analytics, no usage reporting, no license check, no registration call, no crash telemetry — not minimized, none. Our compliance documentation states this without exception, which makes it a claim your own IT staff can settle in an afternoon by watching what leaves the network.
It does not auto-patch. Updates are a decision we make and apply deliberately, so nothing changes underneath your staff on a Tuesday morning without anyone having chosen it.