# ADR-0050: OSHUN Studio Data Retention and Lifecycle Controls

**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 and Exception Control Rule

- 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.

## Related Decisions

- `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`