Retention and erasure against a sealed record

A signing record is built to be append-only, and an erasure request asks for personal data to be destroyed. Those two properties pull against each other. OctoDoc's post-v1.0 design separates document bytes from the structure intended to show that the record was never rewritten, encrypts the first under a destructible key, and leaves the second intact.

Both failure modes are unacceptable, and they are symmetrical. A record that can never be reduced has no erasure path at all, and whoever operates it has architected away the ability to carry out a deletion instruction before the first request ever arrives. A record where erasure looks identical to corruption is worthless as evidence, because any party holding an inconvenient document would have a reason to destroy it and every other party would have a reason to disbelieve any verification result.

The resolution is one design decision taken early, before a single file landed: encryption is scoped per file, and the ledger hashes ciphertext rather than plaintext.

Regulation (EU) 2016/679 Article 17(1) opens: "The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies:", followed by six enumerated grounds covering data no longer necessary for its original purpose, withdrawn consent, objection, unlawful processing, an erasure obligation in law, and information-society services offered to a child.

Paragraph 3 is an exemption, and it is worth reading in the statute's own verb rather than a gloss. It reads: "Paragraphs 1 and 2 shall not apply to the extent that processing is necessary:", followed by five purposes. Point (e) reads "for the establishment, exercise or defence of legal claims."

The post-v1.0 compliance design names 17(3)(e) as the basis on which a ledger evidence block — full IP, coarse geo, user agent, authentication method, achieved tier and consent hashes — would be retained for the organisation's retention window and disclosed on the first signing screen.

This page describes the text of a regulation and the behaviour of a piece of software. It does not apply either one to any particular record, party or dispute.

The octodoc verify command, once it exists, will run the same procedure whether or not a shred has happened. It canonicalises each ledger event with JCS, recomputes its digest, checks that each entry's hash covers its predecessor's, and checks the periodic Merkle anchors against their archived RFC 3161 timestamp tokens. Where payload_ct is present, it verifies payload_ct_sha256.

A shredded payload passes that last step, because the digest was taken over ciphertext and the ciphertext has not changed. What changed is that nothing can decrypt it any more. The report therefore marks the file erased, cites the retention.crypto_shredded event and its sequence number, and returns success.

The mismatch status is reserved for something else entirely: a payload that no longer hashes to its stored digest, or a chain link that no longer covers its predecessor. In that case verification names the exact sequence number where the chain broke and shows the anchor token proving the head predated the edit.

Keeping those two outcomes distinguishable is the point of the whole arrangement. Erasure is an event inside the record, not a hole in it. The end-to-end test that will pin this shreds a data encryption key and then asserts the full verification procedure still passes; neither the key hierarchy nor that test has been built.

The two modes differ in one respect: whether any principal at all can remove the stored object before its retention date. AWS is direct about the answer for compliance mode — "The only way to delete an object under the compliance mode before its retention date expires is to delete the associated AWS account."

That property would not block the planned erasure mechanism. In the post-v1.0 design, the data-encryption key would be held in KMS and never in S3, so destroying it would work identically under either retention mode. Compliance mode removes the second path: deleting the ciphertext object before its retention period. The design keeps both paths open because the choice is one-way at the bucket level — "After you enable Object Lock on a bucket, you can't disable Object Lock or suspend versioning for that bucket."

Object Lock retention defaults are configured per bucket, not per account. The post-v1.0 OctoDoc design therefore chooses governance mode rather than imposing compliance mode on organisations with no elected regulatory retention obligation. This is an architecture reference, not a claim about v1.0 storage, which uses private Supabase Storage without Object Lock.

AWS also documents the seam that crypto-shredding depends on: "While Object Lock can help prevent Amazon S3 objects from being deleted or overwritten, it does not protect against losing access to the encryption keys or encryption keys being deleted." In most architectures that sentence is a warning about accidental data loss. In the post-v1.0 design it would become a deliberate, recorded, dual-controlled erasure mechanism.

Nobody wants to read the contract. OctoDoc is being built so you do not have to: write a document from a prompt, ask plain-language questions about the one you were sent, and keep every one of them in a single place instead of four accounts and an inbox.

Anyone can check a sealed file with no account.

Unlimited human sends on the paid tier.