86 lines
3.3 KiB
Markdown
86 lines
3.3 KiB
Markdown
# 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](EAKTE_ARCHITECTURE.md).
|