# Records Domain Boundary

## Purpose

Records management for file plans, records classification, retention schedules, disposal holds, and archive handoff.

## Owns

- file plans
- records classification
- retention schedule application
- disposal holds
- archive handoff state
- legal record identity

## Does Not Own

- document binary storage
- DMS editing workflows
- generic privacy policy engine

## Integration Candidates

- files
- dms
- docs
- policy
- audit
- transparency

## Implemented State

The native kernel currently provides:

- versioned file-plan nodes and record classes;
- stable record identities, immutable OCC-guarded revisions, volumes, exact
  filed items, and chronology;
- independent valid and recorded time with current/at/all temporal reads;
- tenant, purpose, actor/capacity, source authority, institutional context,
  provenance, and idempotency fields;
- provider-neutral exact-source capabilities, initially implemented by Files
  file versions and Cases revisions;
- tenant APIs, search projection, uninstall/retirement guards, and a Records
  workspace using shared WebUI controls.
- immutable close/reopen, retention, hold, appraisal, and independently
  approved disposition transitions;
- archive-neutral manifests, bounded receipts, and a clearly marked transfer
  simulation that does not claim custody;
- Core recovery-ledger adoption, atomic terminal evidence, Audit projection,
  source and package restore diagnostics, catalog administration, volumes, and
  lifecycle UI.

Restricted object grants remain a separate governed slice. A target-tested
archive adapter and any destructive effect remain deliberately unimplemented;
approved destruction is only a pending lifecycle state.

## First Implementation Slice

Complete restricted access and one target-tested archive provider without
moving source-module ownership into Records. Extend the executable reference
journey across assisted service, decision, filing, hold, restore, search, and
archive simulation before claiming production maturity.

The complete native/external boundary, temporal and purpose-aware record model,
disposition lifecycle, German public-sector provider profiles, and staged
implementation are specified in [eAkte Architecture](EAKTE_ARCHITECTURE.md).