Tenant isolation
Every organisation's data is separated at the database level with row-level security policies on every tenant table, enforced in addition to application checks. The API refuses to start if its database role could bypass those policies. A structural test asserts that every live data stream has an isolation policy.
- Row-level security on every tenant-owned table, checked by an automated contract in the build.
- Three enforcement layers: the API schema, the data stream gateway and the database itself.
- A user can belong to several organisations with a different role in each; the organisation is chosen at login.
Authentication and step-up
Passwords get you in. Anything that moves money, changes access or exports data asks for more.
- Second factors: authenticator app codes, backup codes and passkeys. Password re-entry is not accepted for step-up.
- An elevated session lasts five minutes. Critical actions use a one-time proof bound to a single command, valid for two minutes and consumed on use.
- Owner-only actions include device revocation, catalogue changes, support approvals and installation handover.
- Kitchen and counter devices use per-device credentials with a one-use signed proof on every write. Staff unlock a station with an individual PIN.
Audit trail
Business facts are recorded as append-only entries. Corrections add a new entry; nothing is edited in place.
- Every command records who, when and what changed, and the audit explorer filters by domain, actor and event.
- Every view of an identity number and every person export writes to a personal-data access log.
- Exports declare their renderer version, confidence basis and redacted fields, and download through a one-time link that is never stored in the page.
Personal data
Personal data lives in an encrypted vault, separate from the business record, and is referenced rather than copied.
- Identity numbers, permits, contact keys and payment identifiers are encrypted at rest and redacted from logs.
- Customer screens show masked keys and consent badges, never raw contact details.
- Erasure removes the vault entry so the reference can no longer be resolved, while the business record stays intact for accounting.
Support and installer access
Nobody at ChowChirp can look at your data without your approval, and never as you.
- Support access is requested with a reason, approved by the owner, time-boxed, read-only by default and limited to a named outlet. A banner shows on every screen while it is active.
- There is no impersonation. Support sessions are separate sessions with their own log.
- Installers work under a time-boxed assignment and lose access at handover. They cannot accept their own handover.
Backups and recovery
Continuous write-ahead archiving plus nightly full backups, with a rehearsed restore.
- Recovery objectives: at most 24 hours of data loss and at most 2 hours to restore service in a disaster.
- Sealed archives are written to object storage, read back and verified by checksum and row count.
- Restore drills load into a scratch area first. Live records are never overwritten by a restore.
AI boundaries
The advisor reads. It cannot write.
- Model tools are read-only and scoped to the permissions of the person asking.
- Any action becomes a proposal that a person approves, edits or dismisses, with the decision logged.
- No customer data is used to train models. Provider calls are budgeted per organisation and stop rather than truncate.
