Built so your court papers stay yours.

Family-court files are among the most sensitive documents a person ever holds. This page explains, in plain language and in concrete terms, exactly how EvidenceCanvas protects them — the design decisions, the logic behind them, and the honest limits. No vague “bank-grade security” hand-waving: every claim here corresponds to a mechanism that is actually implemented.

The one-sentence version: identifying material is engineered to stay inside your matter workspace — automated steps see minimised, pseudonymised extracts under the controls below; we don't claim no infrastructure operator can ever process readable data from documents it cannot identify anyone from.

The three-worlds rule — the core idea

1

RAW — the vault

Your original documents live in an encrypted, per-matter store. Originals stay there; where an automated step needs text, only a minimised, pseudonymised extract is used under the controls below. We don't claim readable data is beyond every infrastructure operator — suppliers act under contract and data-protection law.

2

IDENTITY — the mapping

When analysis is needed, names and identifiers are replaced with stable pseudonyms (FATHER_01, SCHOOL_01, ADDRESS_02). The mapping between pseudonyms and real identities is encrypted with a key specific to your matter, and lives in a separate store the processing pipeline cannot read.

3

AI-SAFE — the only outbound form

Only pseudonymised text is eligible to leave the workspace — and every outbound bundle is scanned first. If a raw identifier is detected, the request is blocked, not silently redacted. Fail-closed, by design.

Why it matters: a data breach of the AI layer exposes pseudonyms — not your family's names, addresses, or your child's school. Re-identification requires a second, separately-stored encrypted key. One breach does not cascade.

The pseudonymisation gateway — how documents become AI-safe

  • Two-pass recognition: deterministic patterns first (emails, postcodes, phone numbers, IPs, dates, court references), then an entity/alias pass for people and organisations.
  • Semantic pseudonyms: roles stay coherent — the AI reads about “FATHER_01” throughout a document, so its reasoning about a person stays consistent.
  • Legally-material facts are preserved: dates, amounts, court names and citations are kept (generalised where precision identifies) — because an AI that doesn't know the dates can't help you draft a chronology.
  • Matter-scoped namespaces: the same real name in two different matters maps to two different pseudonyms. Cross-matter correlation is substantially harder by construction — we don't claim it is impossible in every circumstance.
  • Encrypted identity vault: the pseudonym-to-identity mapping is encrypted with a per-matter key derived from a master key; the processing layer holds ciphertext only.
  • Classification gate: content is classified PUBLIC / CONFIDENTIAL / PRIVILEGED / IDENTIFYING. Anything marked IDENTIFYING is refused for external processing — the gateway throws, it doesn't warn.
  • Privacy canaries: known-marker strings are embedded in the pipeline; if a canary is ever observed outbound, the incident is caught immediately.

Leak defence in depth

  • Outbound scan: the fully-assembled prompt is scanned for raw identifiers before it leaves. Detection = hard block of the request (fail closed), logged for review.
  • Output scan: model responses are scanned on the way back for anything that looks like a raw identifier.
  • Attestations: every AI call carries a gateway-built attestation (pseudonymisation version, leak-scan policy, canary status, matter scope). Callers cannot self-attest — the gateway must assert it.
  • Fail-closed passage handling: if a single passage can't be safely pseudonymised, that passage is dropped — never “sent anyway”.

How AI processing handles your material

Automated processing is designed to minimise what leaves your matter workspace: names, addresses and contact details are replaced with placeholders before text is sent, and privacy checks abort rather than retry elsewhere. We use hosted AI model providers, whose servers are outside the UK (including Singapore and the United States), to answer requests. We do not claim absolute anonymity, zero retention by every provider, or that no infrastructure operator can ever process readable data; full details are in our Privacy Notice.

  • Controlled routing: Requests go to our primary model provider; if it fails, to a router restricted to zero-data-retention endpoints. Requests our privacy checks block are never retried elsewhere.
  • Task-scoped models: different tasks (extraction, drafting, QA) use pinned model configurations — no free-form model choice, no surprise routing.

What the AI never sees

  • Real names of parties, children, schools, addresses
  • Raw uploaded documents (only AI-SAFE pseudonymised extracts)
  • Anything from another user's matter (matter-scoped namespaces + per-request grants)
  • Your password, keys, or payment details

Automated processing steps are scoped to answering your request; case records, conversation history and limited operational records are retained as described in the Privacy Notice and retention schedule.

Network architecture — the door that doesn't exist

The production portal runs on a locked-down cloud host with zero inbound network ports. There is no port scanner target, no exposed login page at an IP address, no server to brute-force.

  • Outbound-only tunnel: the application publishes itself by making an outgoing connection to Cloudflare's edge. Inbound connections to the host are impossible — the firewall allows nothing in.
  • Edge identity gate: before any request reaches the portal, Cloudflare's Access layer requires a verified email address: anyone can open an account, but first proves control of their email with a one-time code. The portal then checks Cloudflare's signed token against our own audience tag and refuses any request without one. Unverified traffic is stopped at the edge and never reaches the application. Checked 13 October 2026.
  • Trusted-proxy pinning: the portal accepts identity headers only from the local tunnel process — a spoofed identity header from anywhere else is rejected.
  • Secure cookies: session cookies are Secure and HttpOnly — no reading them from scripts, no sending them over plain HTTP.

Matter-level isolation

  • Grant-checked on every request: every page, file and action is checked against the signed-in user's grant for the active matter. Changing an identifier in the URL gets you your own empty workspace, not someone else's case.
  • Separate workspaces: each matter (and each user-in-matter execution context) has its own workspace inside the practice partition.
  • Draft boundary: drafts are released only to users who hold a grant on that matter, never to anyone outside it.
  • Audited assistance: if practice-team support acts on your matter, both identities are recorded. Support access is a revocable grant, never impersonation.

Your documents at rest — encrypted and recoverable

  • Encrypted at rest: documents and backups are encrypted (AES-256-GCM, authenticated encryption) before they touch disk or cloud storage. Keys are generated per deployment and stored separately from the data they protect.
  • Encrypted backups: the backup pipeline encrypts every object client-side before upload — the cloud storage provider holds ciphertext, not your documents.
  • Upload hygiene: file limits, content hashing, type allow-listing, rate limits and fail-closed malware scanning run before material enters the evidence store.
  • Audit trail: security-relevant events (logins, grants, releases, uploads, support actions, privacy blocks) are recorded with actor, action and matter.

Payments security

Card payments are handled by Stripe, which is certified to PCI DSS Level 1; we never see or store full card numbers. Card numbers are entered only in Stripe's hosted, PCI-compliant checkout — they never touch EvidenceCanvas servers, are never stored by us, and are never seen by our systems or any AI component. Your payment data is handled safely and in accordance with PCI standards. Refunds follow our Refund & Cancellation Policy.

Data residency & GDPR posture

  • Hosting and storage are in the UK (AWS London region). AI processing of pseudonymised extracts happens outside the UK, with model providers whose servers include Singapore and the United States.
  • Personal data is processed for the single purpose of helping you prepare your case documents; it is not sold, shared or used for advertising.
  • Retention is matter-scoped: case material is kept for the life of your matter plus 12 months. If you ask us to delete your data, we delete it within one month; deleted data leaves our encrypted backups as they expire, within 400 days. Legal holds can extend retention where the law requires it.
  • We maintain a Data Protection Impact Assessment and review it on defined triggers (new suppliers, new processing, incidents) and at least annually; it was last reviewed in October 2026. A summary of it, the processor list and a records-of-processing summary are available to practitioner subscribers on request (see the trust pack, below).

Honest limits — what this does not claim

  • No absolute security exists. We design against realistic threats (breach, misrouting, over-sharing, provider retention) and say so; anything promising “unbreakable” is selling you something.
  • The portal is not a mirror of AI chats. Private operator conversations and internal reasoning are not exposed to portal users.
  • One practice, one host. The current architecture runs one dedicated host per practice — not a shared multi-tenant pool of unrelated firms.
  • Security ≠ legal privilege. A well-secured portal does not create legal professional privilege. That depends on your circumstances and your lawyer's advice.
  • You still matter: keep your devices patched, your password unique, and think before downloading documents to a shared computer.
  • Launch-state honesty: the mechanisms described here are implemented in the deployed codebase, and the current multi-role UAT evidence is part of the trust pack below.

Due-diligence & the trust pack

Practitioners and organisations evaluating EvidenceCanvas can request the release-specific trust pack: architecture summary, role matrix, AI routing and provider-location summary, pseudonymisation spec summary, retention schedule, incident-response route, DPIA summary and current UAT evidence. Every document is checked against the deployed configuration before it is shared — the pack describes the system as built, not aspired to.

Start on the free plan Request the trust pack