Disciplines · Decisions (ADRs)

ADR-0050: OSHUN Studio Data Retention and Lifecycle Controls

Studio workflows now produce large volumes of operational data: workflow events, audit evidence, incident records, policy outcomes, generated artifacts, and cross-domain lineage metadata across Yemaya, Isis, Hathor, Aja, Bellona, and

Accepted · 2026-02-23
10sections4 minread
Markdown source
On this page

Status: Accepted
Date: 2026-02-23
Authors: OSHUN Studio Architecture, OSHUN Data Platform Engineering, OSHUN Security and Compliance, OSHUN BFF Engineering, OSHUN Web Engineering
Reviewers: Domain Leads (Yemaya, Isis, Hathor, Aja, Bellona), Project Obsidian Program Design, Legal and Privacy

Context and Problem Statement#

Studio workflows now produce large volumes of operational data: workflow events, audit evidence, incident records, policy outcomes, generated artifacts, and cross-domain lineage metadata across Yemaya, Isis, Hathor, Aja, Bellona, and Project Obsidian.

Retention behavior currently varies by system and workflow. Without a canonical retention and lifecycle control model, Studio risks:

  • inconsistent legal/compliance outcomes across domains
  • unclear archival and purge ownership boundaries
  • over-retention of sensitive artifacts and audit evidence
  • under-retention that degrades investigations and governance continuity
  • weak operator ergonomics for lifecycle transitions and exception handling

Decision Drivers#

  • Compliance and legal readiness: retention and legal-hold behavior must be deterministic and auditable.
  • Security and privacy: sensitive data should not outlive justified policy windows.
  • Operational consistency: one lifecycle vocabulary across Studio domains.
  • Cost and performance: archival tiering and purge discipline reduce storage and query pressure.
  • Traceability: every retention decision and lifecycle transition must be reviewable.

Considered Options#

Option 1: Domain-Local Retention Policies#

Each domain owns independent retention windows, archival tiers, and purge flows.

Pros:

  • Strong local autonomy and rapid domain iteration.

Cons:

  • High policy drift risk and uneven compliance posture.
  • Difficult cross-domain evidence and legal-hold coordination.

Option 2: Infrastructure-Only TTL Enforcement#

Rely primarily on datastore/object-store TTL without explicit Studio lifecycle governance.

Pros:

  • Lower short-term implementation complexity.

Cons:

  • Weak operator visibility and policy explainability.
  • Insufficient support for legal-hold exceptions and governed purge approvals.

Option 3: Canonical Studio Retention and Lifecycle Control Program (Chosen)#

Adopt one policy-aware retention and lifecycle model spanning classification, retention window assignment, archival tiering, legal holds, purge execution, and telemetry/audit evidence.

Pros:

  • Consistent cross-domain governance and compliance behavior.
  • Better operator ergonomics and incident/legal response readiness.
  • Clear ownership boundaries and deterministic lifecycle transitions.

Cons:

  • Requires central policy governance and sustained contract maintenance.

Decision Outcome#

Chosen option: Option 3.

Studio data retention and lifecycle requirements:

  1. Classification and policy binding for all governed records and artifacts.
  2. Lifecycle transition contract for active, archived, legal-hold, and purge stages.
  3. Approval-aware exceptions for hold extension, early purge, and emergency overrides.
  4. Deterministic purge verification with rollback and incident safety controls.
  5. Telemetry/audit continuity for every retention and lifecycle action.

Normative Rules#

Data Classification and Retention Binding Rule#

  • Every governed dataset or artifact must carry a retention class, owner, and retention policy identifier.
  • Retention windows and archival tier targets must be policy-derived and versioned.
  • Missing or invalid policy bindings must fail retention workflows closed.

Lifecycle Transition Governance Rule#

  • Lifecycle transitions must be explicit and reason-coded (active, archived, legal_hold, purge_pending, purged).
  • Transition preconditions must include actor role, policy tier, and evidence references for sensitive operations.
  • Illegal transition attempts must be denied and audit-emitted.
  • Legal hold actions must preserve current data and suspend purge processing.
  • Hold apply/release operations require traceable approver identity and rationale.
  • Exception actions (retention extension or emergency purge) must be policy gated and time-bounded.

Purge Execution and Verification Rule#

  • Purge operations must run through staged execution with dry-run and verification outcomes.
  • Purge completion requires deterministic evidence of scope, success ratio, and failure residue.
  • Purge failures must trigger incident workflows and block closure until revalidation succeeds.

Audit, Telemetry, and Evidence Export Rule#

  • Retention and lifecycle actions must emit structured telemetry and audit events.
  • Missing telemetry/audit continuity must trigger degraded-observability handling.
  • Governance exports must include lifecycle state, policy version, actor metadata, and timestamps.

Architecture Implications#

  • Studio introduces first-class retention/lifecycle workspace controls in web surfaces.
  • BFF and data services require canonical retention policy and lifecycle APIs.
  • Security/compliance services must integrate legal-hold and exception approval workflows.
  • Data platform pipelines must support tiering, purge orchestration, and evidence export continuity.

Acceptance Criteria (OST-00297)#

OST-00297 is complete only when:

  1. ADR exists at docs/adr/ADR-0056-oshun-studio-data-retention-and-lifecycle-controls.md.
  2. ADR defines options, trade-offs, and selected strategy.
  3. ADR defines classification/binding, lifecycle transitions, legal hold and exception controls, purge verification, and telemetry/audit rules.
  4. ADR aligns with ADR-0007 through ADR-0049, especially ADR-0012, ADR-0029, and ADR-0049.
  5. ADR aligns with existing audit/compliance and governance control surfaces.
  6. ADR explicitly covers Yemaya, Isis, Hathor, Aja, Bellona, and Project Obsidian.

Consequences#

Positive#

  • Consistent and auditable retention governance across Studio domains.
  • Stronger legal/compliance readiness for investigations and regulated exports.
  • Better storage discipline through explicit archival and purge lifecycle.

Negative#

  • Increased policy-governance overhead and lifecycle coordination work.
  • Requires sustained ownership clarity between web, BFF, data, and compliance teams.
  • docs/adr/ADR-0013-oshun-shell-architecture-and-domain-adapters.md
  • docs/adr/ADR-0018-analytics-taxonomy-and-event-naming.md
  • docs/adr/ADR-0035-oshun-studio-audit-and-compliance-surfaces.md
  • docs/adr/ADR-0041-oshun-studio-review-and-approval-workflows.md
  • docs/adr/ADR-0042-oshun-studio-file-and-media-ingestion.md
  • docs/adr/ADR-0055-oshun-studio-security-hardening-program.md

References#

  • apps/oshun/web/src/components/studio/StudioAuditComplianceSurfacesWorkspace.tsx
  • docs/releases/v1/specs/studio-audit-and-compliance-surfaces-dependency-and-data-contract-map.md
  • docs/releases/v1/specs/studio-audit-and-compliance-surfaces-user-journeys-and-edge-cases.md
  • docs/releases/v1/specs/studio-domain-dependency-and-data-contract-map.md
  • docs/releases/v1/runbooks/on-call-runbook.md