Confidential identifiers nobody can read back
Row-level security answers one question: may this user touch this record? It cannot answer a different and equally important one: may the buyer read the seller's Social Security number?
So those values live in a separate store that no party can read — not even the person they belong to. There is no product reason to display someone's SSN back to them. Staff read them through a controlled path that demands a written reason and writes a permanent audit entry naming who looked and why.
What the other side can see
Field visibility is an explicit allow-list with default deny, and every field the counterparty can see carries a stated reason for why they can see it. The counterparty knows the person signing opposite them passed identity verification. They do not learn how.
An audit log that rejects edits
The log refuses updates and deletions at the database level — not in application code that a future change could route around, and not merely for ordinary users. Each entry commits to the hash of the entry before it, so an altered history stops verifying.
The log also refuses to accept secret-shaped values in its metadata. The one table you can never delete from is the worst possible place to put a Social Security number.
The document you read is the document you sign
The same domain logic runs in the mobile app, in the server functions, and in the test suite. That is why the document a party reads on screen is byte-identical to the one the server renders: same template snapshot, same merge data, same content hash. If those could diverge, “the document you signed” would be a claim rather than a fact.
Invitations need two channels
The invitation link carries a high-entropy token and a six-digit code travels by a different channel. Neither one alone admits anybody, so a forwarded email is harmless. Only hashes are stored, and every failed attempt is rate-limited and reported identically — a wrong code and an expired invitation look the same to whoever is guessing.