3.6 KiB
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.
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.
Next Boundary Slice
Complete restricted access and 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.