Security that holds up under scrutiny

Every case-data table is scoped to the owning account, with Postgres Row Level Security turned on. Access requires membership on that account, and the check runs inside the database itself — not in application code that a bug could route around. A query without the right membership doesn’t get an error page; it gets nothing.

We prove it against a real database. A cross-tenant test suite checks seven sensitive tables — cases, visits, participants, invoices, service agreements, intake requests, and reports — from three perspectives: the owning organization, a different organization’s owner, and an unrelated authenticated stranger. The owner sees its own rows; the other two get empty results on read and a hard permission error on write. Last run: zero leaks.

An account is no longer a flat trust boundary. Owners and admins see every case in the practice; a monitor sees only the cases assigned to them. That boundary is the same Row Level Security machinery as the tenant boundary, evaluated in Postgres against the assignment on the case — a monitor querying a colleague’s case gets an empty result, not a filtered view they could page past.

Access is tied to live membership rather than to the assignment record, which is the part that matters when someone leaves. Remove them from the practice and their access to the cases they were carrying ends with the membership; there is no orphaned assignment still granting entry. A dedicated suite runs this against a real database from four positions inside one agency — owner, admin, and two monitors each assigned a different case — plus another organization’s owner and a solo practitioner, to confirm the solo case still sees everything. Thirty checks, last run green.

The limit, stated plainly: this separates monitors from each other, not staff from principals. Owners and admins are trusted with the whole book by design, and there is no setting that hides a case from them. If that matters for your practice, the control is who you make an admin.

All traffic is HTTPS, and production responses carry a strict transport security header — one-year max-age, subdomains included, preload. Our database and file storage run on Supabase, on AWS, which encrypts data at rest with AES-256.

To be precise about what that covers: the at-rest encryption is the hosting provider’s, and it protects the stored data and its backups against someone getting hold of the storage itself. It does not stop anyone with access to the database from reading case data. Who can read a case is decided by the access rules described on this page, not by encryption.

One thing we won’t imply: FamilyBridge’s servers read your data in order to show it to you, draft reports, and send documents. None of this is end-to-end encryption, and we won’t pretend it is.

Before any visit text reaches the language model, the names of the people recorded in the case file — parents, children, attorneys, the monitor, the mediator, court evaluator and guardian ad litem, and emergency contacts — are replaced with anonymous placeholders such as [CUSTODIAL_PARENT] or [CHILD_1], in the forms recorded there: full name, first name, last name, preferred name, and with a title such as “Ms.”. Email addresses and phone numbers in common formats are replaced too, and so is the visit location where it is written as recorded. So the report can still be written correctly, the model is told each placeholder’s role; their pronouns, as recorded in the case file or, failing that, inferred from a recorded gender or a parent’s relationship to the child (mother or father); and a child’s age when a date of birth or age is on file. A case number is not replaced unless it contains a recorded name, and street addresses in notes are not replaced. If the case records can’t be read or decrypted, generation stops rather than sending names it can’t identify. GPS coordinates aren’t included in the prompt — the route appears in reports only as a server-rendered map image. The model itself is a contracted AI subprocessor listed in our Data Processing Agreement.

Real names are restored only in the monitor’s editable copy after the model responds. The stored audit artifacts — the exact prompt used and the model’s raw output — keep the redacted form permanently.

Being precise about the limits: this is redaction built from the case file, not a general-purpose scrubber. A name that isn’t in the case file — a grandparent, a new partner — isn’t caught, and neither are initials or a nickname that isn’t on record. The visit location is caught only as it is recorded, so “the family center” or an abbreviation of it isn’t. A name that is also an everyday word, like Will or Grace, is replaced where it is capitalized and left alone in lowercase. That is why every AI report starts as a watermarked draft for the monitor to review and finalize, and the app sends a report only once it is finalized.

Every signature records a SHA-256 hash of the exact document content at the moment of signing, with a versioned label saying precisely what was hashed, plus per-signer SHA-256 hashes of the signed PDFs. A salted SHA-256 integrity checksum binds the document hash to the signer and timestamp. And the signature record is append-only at the database layer: a trigger rejects any change to the evidentiary columns — what was signed, who signed, the hashes, IP address, user agent, timestamps — for every database role, including our own service role.

Each signature also writes automatically to a signature audit log capturing action, IP address, user agent, and timestamps, and a Certificate of Completion PDF is generated per signer and hashed for the trail. Anyone with access to the agreement can re-verify a signature on demand: a database function recomputes the checksum from the stored record and checks for revocation, expiry, or supersession. To be exact about what that check does: it validates the stored signature record — it does not re-download and re-hash the stored PDF bytes.

Once a monitor finalizes a report, it locks at the database layer: the policies that allow updates and deletes require an unlocked report, generation completes only through a guarded database function, and even our own service-role maintenance path refuses to touch locked rows.

Corrections happen the way they do on paper: as timestamped addenda, stored in their own table, which can themselves be locked. The record shows what was written, when, and what was corrected — nothing gets silently rewritten. That’s what “built to survive cross-examination” means in practice.

Label the parents the way their order does — Residential/Visiting, Custodial/Noncustodial, Petitioner/Respondent, or your own terms — applied consistently across the app and the documents and reports you generate. It is not just preference: “noncustodial” asserts a custody finding that may not have been made, while Petitioner/Respondent stays neutral. Precise words in a document a judge reads.

Every case keeps a history of activity that customers can read and add to but have no path to edit or delete — the database grants no update or delete permission on it. Monitors can export it as an Audit Trail Export PDF whenever a case file needs to leave the system.

Separately, a security event log records authentication, admin, rate-limit, and security events — event type, IP address, user agent, severity — with writes restricted to the server and a documented one-year retention. One distinction we hold ourselves to: these logs are append-only by database policy; we reserve the word “immutable” for the two places it’s enforced by trigger and lock — signature records and finalized reports.

Parents and other case parties have no logins and no standing access. Everything they touch runs through single-purpose, expiring, tokenized links: intake links expire after 72 hours, agreement signing links after 7 days, and report view links after 7 days with a capped number of views. Expired links show a clear “Link Expired” state — they don’t half-work.

Before an unauthenticated parent can sign an agreement, they pass an ESIGN disclosure gate and verify a 6-digit code sent to their email — 10-minute lifetime, 5 attempts maximum, 3 sends per hour, stored only as a SHA-256 hash. The verification timestamp is carried onto the signature record for the audit trail. The full flow is covered by automated end-to-end tests.

Role-based rate limiting runs on sliding windows: 100 requests per minute for authenticated users, 20 for anonymous traffic, 5 for authentication endpoints — with separate, tighter limits on signing codes. Responses carry defensive headers: framing denied, MIME sniffing disabled, strict referrer policy, camera and microphone blocked, geolocation limited to the app itself, and strict transport security in production.

Our session policy: 24-hour sessions for regular users, a one-hour timeout for platform admins, 15-minute windows for sensitive operations, and 30-minute idle detection. Admin routes can additionally be restricted to an IP allowlist. The production database is backed up daily, encrypted, on a rolling window of snapshots.

The paperwork is public too: versioned Terms of Service, Privacy Policy, Cookie Policy, and a Data Processing Agreement committing to TLS in transit and AES-256 at rest. Account deletion is an OTP-confirmed flow, and a practice’s owner or admins can export all of its data themselves, from Settings.