How Counsel.day protects the data underneath a private decision.
Counsel.day exists because the private vote is the mechanism. If the seal is not real, the product is theatre. This page is the plain-language account of who can read your notes, how the seal is enforced in the database, where the encryption keys live, what we back up, what we disclose under subpoena, and how to report a vulnerability. For the deeper engineering walkthrough, see the privacy mechanism.
No Counsel.day operator, including the founder, can read your votes or notes mid-decision. The database enforces this; the sealed read path is the only path; there is no admin override and no support escape hatch. If you are reading this page and looking for the line, that is the line.
Nobody but you.
The answer is short. Nobody but you can read what you wrote, mid-decision or after. Not your partner, until the verdict day. Not the Counsel.day support team. Not the founder. Not an engineer doing a database migration. Not a subpoena, until the verdict has published. The architecture is built so that the seal is enforced by the database itself, not by policy.
The single exception is on the verdict day, at the verdict moment, when both partners' notes become readable to each other (and only to each other) inside the verdict view. Even then, no operator at Counsel.day can read the notes; the analysis pipeline runs against the data in a constrained execution environment that returns the verdict text and nothing else.
The seal is enforced in the database, not in policy.
Every vote and every note row is protected by Postgres row-level security keyed to the voter's identity and the decision's verdict timestamp. The only path the application can take to read a vote row is the sealed read path; that path checks the verdict timestamp on every query, and refuses any read that is not the voter's own row or that is for a decision whose verdict has not yet opened.
There is no support tool, no admin console, and no operator-facing API that bypasses this check. Database migrations run against the encrypted blob, not against decrypted content. The privacy mechanism is described in full, with the SQL, on the engineering page.
Per-decision keys, rotated, managed by Infisical.
Each decision is encrypted with its own data-encryption key (DEK); the DEK is wrapped by a key-encryption key (KEK) held in Infisical, our secrets manager. KEK rotation runs quarterly; DEKs are rotated on every verdict close. Vote and note bodies are encrypted at rest with AES-256-GCM; transport is TLS 1.3 with HSTS preload and HTTP/2.
Passwords are stored as argon2id hashes with per-user salts; session tokens are short-lived and rotated on every privileged action. Multi-factor authentication is required for billing changes and account deletion, and is available for every account.
What we back up, and where it lives.
Encrypted nightly backups are written to two geographically separate object stores in the EU. The backups contain the same encrypted blobs as production; the KEK to decrypt them is held only in Infisical, and never travels with the backup. Backups are retained for thirty days, then irrevocably destroyed.
If you delete your account, the live row is destroyed immediately; the backup row falls out of the retention window within thirty days and is destroyed with the rest of the snapshot it sits in. We do not maintain long-term archives of deleted user data.
What we can, and cannot, disclose to a court.
We comply with valid lawful demands directed at the New Zealand entity, scoped to what the order requires. We can disclose: your account email, your billing record, the timestamps of votes (whether you voted on a given evening), the question and duration of a decision, and the verdict text once it has published.
We cannot disclose, even under subpoena, the contents of a vote or note before the verdict has opened. The architecture prevents it: the data is encrypted, and the read path will refuse the query. A court order that compels us to defeat the seal would be litigated as a request to break our own security model, with the user notified to the extent the order permits.
We will notify you of any lawful demand for your data unless the order specifically forbids it; in that case, we will notify you as soon as the gag is lifted.
Responsible disclosure.
If you have found a security issue, write to security@counsel.day. We acknowledge reports within one business day; we triage within five business days; we fix critical issues within thirty days and others within ninety. Good-faith researchers will not be pursued under computer-misuse statutes; we credit you in the next release notes (unless you ask us not to).
For sensitive disclosures, our PGP key is available on request; please do not publish proof-of-concept code targeting customer data before we have had a reasonable window to fix the issue.