Isolation in the database, and a trail that shows any tampering
Each customer’s data is held apart by the database itself: on PostgreSQL every tenant table forces row-level security. Changes to governed records go through change requests, and the record change log and the platform’s own action log are hash chains that show an edit, a gap or a reordering.
Who uses it
- Administrator
- Auditor
- Security officer
What it does
- Row-level security forced on tenant tables in PostgreSQL, so one customer’s request cannot read another’s rows.
- Governed record changes (DG-01): a change request, approved by someone other than the requester where the record requires it.
- A per-workspace, hash-chained, append-only log of record changes, with sensitive values redacted.
- The platform’s action log as a hash chain, anchored in object storage and verified on a schedule.
- Content hashes on working papers, statements, signatures and archives.
How it works
- Every request runs inside its workspace’s scope.
- A governed change is requested, decided and recorded.
- The chains are verified; a break is named at the first row where it occurs.
The controls that protect it
- The change log refuses updates and deletes by trigger, on both database dialects.
- A platform support session reaches a workspace only as the firm allows.
What it does not do (yet)
- An anchor kept on the server’s own disk (no storage bucket configured) says so: it catches an edit made through the database alone.
