# 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 implemented by Files versions,
  Cases revisions, Forms Runtime submissions, and Decisions 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.
- an executable assisted/digital resident-parking-permit reference package
  that proves equivalent filing semantics, URL resume, search, temporal
  reconstruction, and evidence integrity after database backup/restore.
- revisioned, effective-dated restricted-record grants for accounts,
  memberships, groups, roles, function assignments, and delegations, with
  exact read/write/manage actions and allowed purposes. Current grants govern
  historical reads and idempotent replays; search requires `records.search`.

A target-tested archive adapter and any destructive effect remain deliberately unimplemented;
approved destruction is only a pending lifecycle state.

## Data-subject requests

Records publishes `privacy.dsar.records`. A record-subject search must include
an exact record, revision, item, volume, chronology, hold, disposition,
transfer-package, or authoritative source-module reference. A canonical
account, identity, or membership match identifies staff accountability
activity only; creating, filing, reviewing, or transferring an eAkte does not
make that staff member the subject of its contents.

The provider exports bounded record identity, revision, filing, chronology,
hold, disposition, transfer, and the subject's own restricted-access grant
lifecycle metadata. It excludes source
content, record snapshots and search text, opaque institutional contexts and
payloads, grant reasons, digests, replay keys, launch URLs, approval identifiers, archive
manifests and receipts, and unrelated records. Exact source content remains in
the source owner's DSAR provider. Record revisions and lifecycle evidence are
immutable retention evidence; the current record fact receives a
non-executable manual-review action. Actual correction, closure, appraisal,
hold, disposition, or transfer must use the governed eAkte lifecycle.

## Next Boundary Slice

Complete one target-tested archive provider without moving source-module
ownership into Records. The executable reference journey
already covers assisted/digital intake, decision, filing, hold, restore,
search, and archive simulation; it is evidence for the native boundary, not a
claim of target archive conformance or transferred custody.

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