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.

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, and transfer lifecycle metadata. It excludes source content, record snapshots and search text, opaque institutional contexts and payloads, 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.

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.

3.3 KiB Raw Blame History