Document Lifecycle
From upload to deletion — every stage of a document's journey, and why the general application layer never sees plaintext at any point.
Every document follows the same path: encrypt → upload → process → searchable → shareable → deletable. At every stage, the general application and database layer handles only ciphertext, wrapped keys, and opaque tokens.
1. Encryption (on your device)
Before a document leaves your device, the following happens locally:
- A fresh encryption key is generated specifically for this document. No two documents share the same key.
- The document's content and metadata (title, filename, type, size) are encrypted separately using this key.
- The document key itself is then wrapped (encrypted) using your personal master key, so only you can unwrap it later.
- A blind document token is computed — a one-way cryptographic fingerprint that identifies the document without revealing its actual ID to the server.
The server receives only encrypted content, encrypted metadata, and wrapped keys. It has no ability to decrypt any of them.
For more on how these keys work together, see Key Hierarchy.
2. Upload
Your encrypted document is uploaded to the server in two phases:
- Reservation — You request a slot for the new document. The server returns a
document_idand acommitment_noncethat binds the upload to your identity and the specific document. - Content upload — The encrypted document blob is uploaded to secure object storage. The upload is atomic — only one upload attempt can succeed for a given reservation, preventing duplicate processing.
At this point, the server has your encrypted document but cannot read it.
3. Processing (inside the secure enclave)
Once uploaded, the document enters a processing queue. Processing happens entirely inside the hardware-isolated secure enclave:
- The enclave retrieves the encrypted document and unwraps the document key using the platform's hardware-protected key.
- The document is temporarily decrypted inside the enclave only — the decrypted content never leaves this isolated environment.
- Text extraction is performed (for supported document types) to extract searchable text.
- Identity verification is performed if applicable.
- Blind index tokens are generated for entity-scoped search — one-way cryptographic values derived from the entity's key material, scoped to the organization. Consumer blind index tokens are generated on your device and submitted separately via the consumer-indexes API.
- A verification seal is created — a cryptographic signature bound to this document that proves it was processed by an attested enclave.
- Everything is re-encrypted, and only the encrypted results are sent back to the server.
Audit trail — not yet active
The enclave contains a tamper-evident audit log implementation — each entry encrypted inside the enclave and chained cryptographically so tampering breaks the chain. This is not yet wired into the document processing pipeline. Tracked in issue #16.
The server stores the processing results — blind index tokens, encrypted verification seal, encrypted OCR text — but never sees the plaintext at any point.
4. Searchable
Your document is searchable through encrypted search (see Encrypted Search). Blind index tokens enable equality matching without the server learning what you're searching for.
Tokens are scoped: personal documents use tokens derived from your personal key; organization documents use tokens derived from the organization's key. The same document content produces different tokens in each scope, preventing server correlation between personal and organizational searches. A document is searchable once blind index tokens exist for the relevant scope — processing status alone does not guarantee it.
5. Shareable
You can share documents with other users or organizations through the grant system (see Grants & Sharing). Sharing is consent-based and time-limited:
- You create a grant that contains the document's encryption key, wrapped so only the intended recipient can unwrap it.
- The recipient discovers, claims, and accepts the grant.
- Once accepted, the recipient can decrypt the document using their own key chain.
- You can revoke access at any time, and all grants automatically expire after a set period.
When a document is shared with an organization, it goes through a re-indexing step inside the secure enclave. The enclave generates a new set of blind index tokens scoped to that organization, so members can search for the document within their organizational context. This re-indexing happens without re-running text extraction or verification — it only produces new, independently scoped tokens.
6. Deletable
When you delete a document:
- The document record is soft-deleted in the database (marked as deleted but not immediately removed).
- The encrypted document blob is deleted from object storage.
- If blob deletion fails, it is queued for automatic retry — ensuring no orphaned encrypted data lingers indefinitely.
- All associated blind index tokens are cleaned up.
Because the document was encrypted with a unique key, and that key was wrapped with your personal key, deleting the wrapped key effectively makes the document cryptographically unrecoverable — even if encrypted fragments remained somewhere, no one could decrypt them.
If the document was shared with organizations, revoking those grants removes the organization's wrapped copy of the key, cutting off their access as well.
At every stage of this lifecycle, the server acts as a blind custodian. It stores, routes, and delivers encrypted data — but the only place plaintext ever exists is on your device or inside the hardware-isolated enclave.