Document Lifecycle

Every document follows the same path: encrypt → upload → process → searchable → shareable → deletable. At every stage, the application and database layers handle encrypted content, wrapped keys, blind index tokens, and opaque identifiers rather than document plaintext.

1. Encryption On The Client Device

Before upload, the client encrypts the document locally:

• A fresh document encryption key is generated for the document.
• Document content and metadata are encrypted separately.
• The document key is wrapped so authorized parties can unwrap it later.
• A blind document token is computed to identify the document without exposing a plaintext relationship identifier to the application 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

The encrypted document is uploaded in two phases:

1. Reservation — the client requests a slot for the new document. The server returns a document_id and a commitment_nonce that binds the upload to the authorized session and the specific document.
2. 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 the encrypted document but cannot read it.

3. Processing (inside the secure enclave)

Once uploaded, the document enters a processing queue. Processing that requires plaintext happens inside the hardware-isolated secure enclave:

1. The enclave retrieves the encrypted document and unwraps the document key using the platform’s hardware-protected key.
2. When authorized, the document is temporarily decrypted inside the enclave — the decrypted content never leaves this isolated environment.
3. Text extraction is performed (for supported document types) to extract searchable text.
4. Identity verification is performed if applicable.
5. 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 the client and submitted separately via the consumer-indexes API.
6. A verification seal is created — a cryptographic signature bound to this document that proves it was processed by an attested enclave.
7. Everything is re-encrypted, and only the encrypted results are sent back to the server.

The server stores the processing results — blind index tokens, encrypted verification seal, encrypted OCR text — but never sees the plaintext at any point.

Verification Seals

When the enclave processes a document, it can produce a verification seal: an encrypted, signed artifact bound to that document and processing result.

A seal proves:

1. Authenticity — the document was processed by a genuine attested enclave.
2. Integrity — the result has not been altered since creation.
3. Specificity — the seal is bound to this document and cannot be reused for another document.

The seal is encrypted and stored with the document. Literal may also store a commitment hash so the existence and integrity of the seal can be verified without revealing its contents.

4. Searchable

A document becomes searchable when blind index tokens exist for the relevant scope.

Personal documents use tokens derived from personal key material. Organization documents use tokens derived from organization-scoped key material. The same underlying document produces different tokens in different scopes, which prevents the application server from correlating personal and organization searches by token value.

See Encrypted Search for the full model.

5. Shareable

Document holders can share documents with recipients or organizations through the grant system (see Grants & Sharing). Sharing is consent-based and time-limited:

• The document holder creates a grant that wraps access for the intended recipient.
• The recipient discovers, claims, and accepts the grant.
• Once accepted, the recipient can decrypt the document through their own key chain.
• The document holder can revoke access, and grants can expire automatically.

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 a document is deleted:

1. The document record is soft-deleted in the database (marked as deleted but not immediately removed).
2. The encrypted document blob is deleted from object storage.
3. If blob deletion fails, it is queued for automatic retry — ensuring no orphaned encrypted data lingers indefinitely.
4. All associated blind index tokens are cleaned up.

Removing the wrapped key material makes remaining encrypted fragments unusable without a valid copy of the document key.

If the document was shared, revoking grants removes the recipient’s wrapped access path.

Related Concepts

• Key Hierarchy — the key types that protect each document at every stage.
• Encrypted Search — how blind index tokens enable search without revealing content.
• Grants & Sharing — how document access is shared through cryptographic grants.
• Blind Routing — how ownership and membership are tokenized to prevent relationship mapping.

Last updated on