​

Retention windows and deletion

​

The stores map

1. Defaults are inert for the three policy domains. A workspace that never touches the data-retention endpoint has no automatic message, conversation, or audit-log retention behavior — only recordings (bucket lifecycle) and video rooms (90-day recording settings) expire without opt-in.
2. Redaction and purge are different objects. Message retention redacts content and keeps billing-grade metadata; recording retention deletes media and keeps the call row; conversation delete removes the thread row. “Retention ran” never means “everything is gone.”
3. Survivorship is billing-safe by design. Status, delivery receipts, segment counts, and prices are not personal content — they survive every window so finance and dispute workflows keep working on redacted or purged rows.

​

Tenant-configurable knobs

GET /api/v1/settings/retention
PUT /api/v1/settings/retention
{ "recording_days": 30, "video_room_days": 90 }

• recording_days — the unified recordings window, clamped to 7–3650 days (7-day floor guarantees post-recording dispute lookback; the 3650-day ceiling cannot exceed the bucket lifecycle hard-purge). The sweep reads it; the bucket safety net caps every object at 365 days regardless.
• video_room_days — the video-room session-history window, 7–3650 days, default 90. It is a separate knob routed to a separate key, not part of the channel policy fields.

• messages — 7–3650 days, 0 to disable.
• conversations — 30–3650 days; the 30-day floor blocks deleting a thread that closed hours ago.
• audit_logs — 365–3650 days; the 365-day floor is regulatory (SOC 2 examination window), and the 2190-day fallback targets HIPAA’s expectation.

• Recording media at 365 days. The object-storage bucket lifecycle is a platform safety net — set any window you like under it, media still cannot survive past it.
• The audit floor. 365 days of audit evidence is non-negotiable; a mis-set shorter window returns a 422.
• Cross-knobs. Shrinking recording_days does not shrink messages or conversations, and disabling recording retention does not disable the policy domains. Each window is its own decision.

​

WORM archival export vs. operational purge

• Retention-lock replaces deletion. Anything you export before the window elapses is held by you, not by Orbit; the sweep still purges Orbit’s copy on schedule.
• The signed bundle, not the window, is your proof. The manifest stamps the lock promise (window, basis, version) so an auditor can verify the records were captured while the policy was in force.
• Archival and windows are decoupled by design. Windows answer “how long does Orbit hold this” — archival answers “how do I hold my own copy for longer.” An operator that has mirrored the signed bundle can let the operational sweep run and keep regulatory retention sovereign to its own store.
• Failure is loud. A bundle whose hash does not replay never lands silently in your archive; a mismatched current_hash or prev_hash verdict tells you the chain broke.

​

Legal hold

• Per-recording holds. PUT /api/v1/recordings/:id/legal-hold (with { hold: true|false, reason }) flips a flag on the recording row and, when the recording is a video-room artefact, propagates the same flag to the linked video-room session row — every sweep that could reap the underlying media honors it. The flag survives release as false (rather than being deleted) so the audit trail of who set and cleared the hold is retained on the row.
• Conversation-level aggregation. The same read merges to “hold the whole conversation” — the per-recording groups re-aggregate into one row behind GET /api/v1/recordings/conversation/:id/legal-hold, and a batched PUT toggles every linked recording in one call. A conversation with no held recordings yields heldRecordings: 0 — sweep-eligible on every row.
• The hold wins while it stands. Retention defines the normal-operation posture; the hold defines litigation preservation. Set workspace windows for the default and use holds for the exceptions.
• Reconcile holds before erasure. Open holds and in-flight erasure requests interact per-contact — reconcile them in your DSAR process rather than expecting the windows to fulfill either.

​

GDPR erase vs. window expiry

• DSAR erasure is contact-scoped and immediate-request-driven — a data-subject request runs its own workflow independently of the org-wide windows. It is not deferred until a window elapses, and it is not gated on a sweep cadence.
• Age-based windows are org-wide and scheduled — they enforce a posture, not a request.
• Per-record delete vs. window expiry. A GDPR erase deletes the contact’s records through its own path; a window’s expiry only flags rows as eligible for the next sweep.
• Posture check. A DSAR-scoped export surfaces whether a contact has erasure pending; the troubleshooting surface DSAR export failures distinguishes “nothing erased yet” from a genuinely failed export.

​

Boundary: platform-fixed vs. tenant-owned

​

Related