Standard retention compared with ZDR
ZDR is not a stronger recovery mode. It is a reduced-custody mode with fewer
recovery, replay, export, and reconstruction semantics.
The current source row is customer-facing
preview, rollout_fenced,
admits only the zdr retention mode, and requires the hosted ZDR Runner
prerequisite plus release evidence. Those labels describe source posture;
the live endpoint must still report available: true for the selected
deployment and Workspace.
What may remain without execution content
Checkfu can retain non-content facts needed for governance, accounting, and safety, such as:- identifiers and sequence positions;
- timestamps and state transitions;
- authorization and policy dispositions;
- approval identity and decision;
- Usage units and monetary facts;
- content-unavailable reasons; and
- non-secret provider effect disposition.
Recovery and your own delivery
The Session event log is the only transcript. If your application copies Session output into a messaging app, mail, or another system, that copy is yours. Under standard retention you can read retained events again and resend them. Under ZDR, content omitted from the Session cannot later be reconstructed by Checkfu. External providers keep their own copies under their own policies. Checkfu’s retention mode does not erase provider-held mail, messages, files, or delivery logs unless an admitted provider operation explicitly does so and the result is observed. Credentialed live-provider qualification and provider-held erasure remain separate requirements; a retention mode does not establish provider support. Earlier releases recorded managed chat-channel presentation attempts. Those historical records remain readable until retention or erasure removes them. Session deletion drains any linked attempts before erasure can complete.Export
GET /v1/sessions/{id}/export can return only what the caller is authorized to
read and what remains in durable custody. The export accounts for unavailable
sequence positions rather than fabricating content.
An export is a new downstream copy. Once written to your filesystem, object
store, SIEM, or data warehouse, it is governed by your retention and erasure
controls. A later Checkfu erasure cannot reach that copy.
See Export retained Session and audit records for
the current export boundaries.
Deletion and erasure
Use the terms precisely:- Archive changes lifecycle or mutability while retaining the resource.
- Delete removes the addressed logical resource according to its typed contract.
- Erase disposes of protected content and identity links across every sink included in the erasure contract.
Current limitation
Expired Session content is unavailable when its retention key can no longer be read. Key expiry does not itself delete immutable archive objects: encrypted bytes and structural Session and Workspace identifiers can remain. Session erasure separately removes owned R2 archive objects in bounded batches; failed physical cleanup stays pending for alarm retry. Per-original content-expiry cleanup for payloads copied into native task and Memory intent records is not implemented. Expiry or deletion of a source does not itself remove every native copy. A native continuation’s authority deadline limits use; it is not proof that copied payloads have been physically deleted. Native copied-content TTL support requires the admitted content policy and earliest applicable content expiry to follow each copy, with cleanup covering its writers, readers, history, and recovery sinks. Until those paths are installed and qualified, source expiry is not a native-copy deletion guarantee. The namespace erasure path below is separate. Native erasure can record deletion of the active namespace when the original store birth is retained, entered local owners have joined, and the original namespace eraser succeeds. Content cleanup still remains pending: deletion of recovery copies for that original store generation is currently unverified. Active namespace deletion alone does not acknowledge the durable content worklist or establish complete native-content erasure. Legacy native copies without that original birth evidence remain unavailable for this erasure path; reopening a store does not supply the missing provenance. Retirement, access denial, and protected-vault cleanup alone do not establish removal of native copies. This path does not establish physical runtime drain, removal of provider-held copies, or completion across other registered sinks. Session erasure owns a durable sink worklist covering retained Session stores and any historical presentation attempts. Failed cleanup remains pending and resumes on an alarm; key shredding waits for acknowledgements. A Bundle export is admitted only on the live export epoch, and every body page it streams rechecks erasure, so a release that loses to deletion fails instead of completing. These controls do not establish that every downstream copy disappears synchronously. Broader completion evidence and custody outside registered Session-owned sinks remain separate, especially provider copies and remote revocation that can remain pending. Therefore:- stop new work and revoke relevant access before requesting erasure;
- cancel or quarantine in-flight exports and provider operations;
- treat downstream exports as separately governed copies;
- retain the Audit evidence for each disposal step; and
- do not describe erasure as complete until the deployment’s current evidence covers every required sink.