FamilyBridge holds some of the most sensitive records a family will ever generate — visit notes, children’s names, signed agreements, court-bound reports. This page explains specifically how that data is isolated, encrypted, and protected from tampering, and is honest about where the limits are. No certification theater, no vague promises.
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.
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.
We don’t stop at the infrastructure layer. The most sensitive fields are encrypted a second time by our application — AES-256-GCM with a random IV and authentication tag, in a versioned format — before they’re ever written to the database. That covers visit notes, locations, and attendee lists; parties’ names, emails, and phone numbers; children’s names and dates of birth; report content and the AI prompt and raw output; intake form data, including details like driver’s license numbers; and signer names on agreements.
One thing we won’t imply: this is server-side encryption. FamilyBridge holds the keys and encrypts and decrypts on your behalf. It is not end-to-end encryption, and we won’t pretend it is.
Before any visit text reaches the language model, the names in the case file — custodial parent, non-custodial parent, each child, attorneys, the monitor — and the visit location are replaced with anonymous placeholders: [CUSTODIAL_PARENT], [CHILD_1], [LOCATION], and so on. If the case context needed to build that redaction map can’t be loaded, generation fails closed: the report simply doesn’t generate, rather than sending unredacted text. GPS coordinates are never included in the prompt at all — 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, and are field-encrypted on top of that.
Being precise about the limit: this is entity-based redaction built from the case file, not a general-purpose scrubber. A name that exists only inside a note’s free text — a grandparent, a new partner not on the case — is not recognized and not redacted.
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.
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 in 7 days, signing and party-access links default to 72 hours, and report view links expire in 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 data export is available on request as an operator-run process.
FamilyBridge’s founder runs Allied Visitation, a working supervised visitation practice. FamilyBridge wasn’t designed in the abstract — it was built inside that practice, on live cases and real court deadlines. That’s the disclosure. Here’s the question it raises: if the people behind FamilyBridge also run a visitation business, can they see your cases?
The honest answer is that, like every hosted software operator, we can technically access customer data. We run the servers, hold the infrastructure credentials, and hold the encryption keys — administrative access exists for support, debugging, and legal compliance. That’s true of any platform whose servers process your data the way ours do; we’d rather say it plainly than imply otherwise. What we’ve done instead is make that access structurally narrow and hard to use quietly. The admin console contains no case browser — it surfaces accounts, subscriptions, billing, and verification status, not visit notes or reports. Admin routes return 404 for anyone without the platform-admin role, can be restricted to an IP allowlist, and are held to a one-hour session timeout. Destructive admin actions are written to an admin activity log. Sensitive case fields are encrypted at the field level, so case content is ciphertext in ordinary database views — a real obstacle to casual browsing, though not a mathematical barrier, since we hold the keys.
Two things are hardened even against us: the evidentiary columns of every signature record, where a database trigger rejects changes from every role including our own service role, and finalized reports, where database policies refuse updates and deletes on locked rows — including through our own maintenance paths. And our operating practice is simple: we do not open case content except when you’ve asked for support that requires it or when we are legally compelled. If that’s not enough for your agency, ask us hard questions. We’d rather answer them than dodge them.
Reviewing FamilyBridge for an agency? Read the Data Processing Agreement or ask us your hardest questions.
See how case data flows through an AI report