· Court Transcript Platform
Only you hold the key: what private mode encrypts, and what it cannot
A per-account encryption tier for transcripts nobody here should be able to read. How the sealing works, what is ciphertext at rest, and the four limits we will not round up.
Some recordings should not be readable by the company processing them. An internal affairs interview. A sealed family matter. A recorded statement in an investigation that has not been charged yet. The customers who bring us this work ask a version of the same question every time, and it is a fair one: what stops your staff from reading this?
"We have a policy" is not an answer. So we built a tier where the answer is arithmetic instead.
This post is the technical description. It includes the things private mode does not do, at similar length, because a security claim without its limits is marketing rather than engineering.
The shape of it
Private is an accuracy tier you choose at upload, alongside Good, Advanced and Extreme. It runs the same two-engine ensemble as Advanced, so the transcript quality and the review burden are unchanged. What differs is what exists on disk when the run is finished.
You opt in once. That mints an X25519 keypair for your account. The public key is stored in the clear. The private key is stored only wrapped, twice:
- under a key derived from your password with Argon2id
- under a second key derived from a one-time recovery code, shown to you once
The server never stores your private key in a form it can use on its own. At login it unwraps the key with your password and holds it in an encrypted session cookie, which is how the application can read your transcripts back to you while you are signed in and cannot when you are not.
What happens to a private run
Every private run mints fresh AES-256-GCM data keys, one for the hearing's audio and one for the transcript, each sealed to your public key.
There is a wrinkle worth being explicit about, because it is the part a skeptical reader should ask about. Transcription takes a while and you are allowed to close your laptop. For the worker to keep processing after you log out, a second copy of each data key is wrapped under a server-held processing key.
Those copies are deleted by the final sealing stage.
That gives a run two phases with genuinely different security properties:
| While processing | After sealing | |
|---|---|---|
| Data keys on disk | Sealed to you, and wrapped under the server key | Sealed to you only |
| Server can decrypt alone | Yes | No |
| Plaintext original in storage | Briefly, until the first stage seals it | No |
After the seal stage completes, someone holding the database and the object storage and the server's environment cannot decrypt the run. Only a session carrying your unwrapped private key can.
What is ciphertext at rest
Not "the transcript." Specifically:
- the original upload, sealed in place by the first pipeline stage
- the normalized audio and the waveform peaks
- every ASR, diarization, and consensus artifact
- the word-level text of the transcript itself
- the edit log, both the operations and their inverses
- the alternatives stored on every review flag
- export artifacts
Playback and downloads run through authenticated decrypt-and-stream endpoints rather than presigned links, so there is no URL that works without a session holding your key. Admin sessions get a 404 on a private hearing's playback and debug surfaces, not a permission error. The surface is not there.
Masking before the model
Parts of the pipeline ask a language model for help: orthography, crosstalk resolution, speaker suggestions. Those calls go to a vendor.
Before any prompt leaves the building, the identifying strings we hold in structured form are replaced with stable placeholders, and mapped back in the answer. Case name and number, judge, deponent, who the deposition was taken on behalf of, and the speaker names you mapped. The substitution happens inside the chat client itself rather than at each call site, so a new call site cannot forget to do it.
What private mode does not promise
Here is the part that matters, and the part most vendors leave out.
The transcription vendors still hear the recording. This is the big one. Audio cannot be anonymized. The engines receive the file in full, including every name spoken aloud, and voices are themselves identifying. Encryption at rest protects what is stored, not what is processed. A local-models-only variant was designed and deliberately deferred; until it ships, this limit is real and you should assume it.
Masked is not anonymous. We mask entities we hold as structured data. A third party named from the stand, an address read into the record, a phone number spoken aloud: none of that is detected. There is no named-entity recognition in this version, and pretending otherwise would be worse than saying so.
The server sees plaintext transiently. In memory and temporary directories during pipeline stages, at TLS termination on upload, and on each request while you are authenticated. Before the seal stage finishes, the database plus the processing key can decrypt the run. A malicious deployment could capture keys at login. That is end-to-end encryption territory, and end-to-end encryption is incompatible with sending audio to a server for transcription. We are not going to claim a property the architecture cannot have.
Metadata stays visible to us. Case name, number and judge, the hearing and deposition fields, speaker names, word notations, timings, durations, stage progress, flag counts. What is encrypted is the record itself, what was said, and the audio. Tightening the metadata is a known follow-up rather than a shipped feature.
The recovery code is not a formality
If you lose your password and your recovery code, the data is unrecoverable. Not by support, not by an administrator, not by us. That is what "only you hold the key" means when it is true rather than decorative.
The password reset flow warns about this before it runs, and the opt-in dialog makes you acknowledge that you have saved the code. Both of those exist because the alternative, a support path that can restore your data, is precisely the back door the tier exists to remove.
Why this shape
The honest summary is that private mode moves the trust boundary rather than eliminating it. Before sealing, you are trusting our infrastructure. After sealing, you are trusting that the sealing happened, which is a much smaller claim and one that automated tests assert on every change, including a sweep that fails the build if any plaintext survives at rest.
We would rather ship that and describe it accurately than ship something called end-to-end and hope nobody reads the architecture.
The tier sits alongside the three document types on the transcript types page, and applies to any of them.