Security · assurance summary · edition 2026.09
The promise is simple: two databases, and they never meet.
Everything else on this page is detail — written for the person who will actually test the claims. Controls cited by runbook section, plus a named list of what we refuse to over-promise.
Staff workspace STAFF SIDE
your firm’s own system · records · documents
Everything the firm does your records only
Staff accounts & sessions never copied out
Encryption keys unique to your firm
Client portal CLIENT SIDE
a separate system · separate records · separate documents
Only what you shared nothing else
Staff records — never written here not possible
Staff pages do not exist here no route to them
Fig. 01 — verified on the live fleet · runbook §§50–§52the red ✕ paths are not switched off — they do not exist
Sharing, in plain words
What crosses — and what can’t
| What it is | How it reaches the client | Verdict |
|---|---|---|
| Matter status & steps | Only the fields you mark as shared — internal notes stay inside the firm | ✓ Permitted · audited |
| Shared documents | A copy is placed where the client can see it, as an attachment rather than a link | ✓ Permitted · audited |
| Messages | Shared one item at a time, each share recorded with who sent it and when | ✓ Permitted · audited |
| Client invoices & receipts | That client’s own invoices and receipts, and nobody else’s | ✓ Permitted · audited |
| Staff identities & directory | Never placed on the client side at all | ✕ Excluded · structural |
| The trust ledger | Firm-side only; clients see their own statements | ✕ Excluded · structural |
| Any other client’s data | There is nowhere on the client side for it to sit | ✕ Excluded · by absence |
The controls
Ten things we do anyway
Filter the register — or read it end to end. Evidence cites the public runbook.
Scope
What we will state — and what we will not
Stated as fact defensible
- Separate records for staff and clients — the two sides never share a store.
- No shared tenancy in the default setup — your firm’s software, records, documents and keys are its own.
- Nothing for you to patch — no servers or virtual machines anywhere in the arrangement.
- Per-firm releases — tested on our own firm first, checked afterwards, and reversible for one firm at a time.
Refused as over-claim said aloud
- “True isolation, code-wise” is overstated: it is one product with two separately run parts. The separation is in how your firm is set up, not in two different programs.
- Separate accounts per firm are the target. The demonstration firms share one account boundary today, so until that changes the blast radius between demonstration firms is account-level. It is written into the plan as item B5.
- Our operations console holds a powerful key — what it can reach, and how often it is replaced, are treated as operational controls and recorded in our threat notes §§40–§43.
- Trust checks happen at the moment of writing, not by locking a record. That is safe when one person posts at a time; for firms where several people post to the same client account simultaneously, we flag it rather than pretend otherwise — it is on the list before general release.
Roll back one firm
The previous verified build redeploys to that instance alone. No fleet-wide surprises either way.
Restore from your own copies
Your firm’s records are copied on a schedule to storage your firm holds, and can be restored without touching anyone else’s.
Quarantine by shape
A compromised instance is separated exactly as a healthy one is — neighbours share nothing to reach through.
“Show me the boundary in the code — then let me decide.”
how every openlpm walkthrough begins