Describe the feature
Add configurable retention policies for Kival data.
Organizations should be able to define how long selected categories of data are retained and when they become eligible for disposition.
Matching objects should be scheduled for disposition rather than removed immediately, with a review window before Kival applies its normal deletion/archive lifecycle. When an object enters that review window, Kival should surface it through the existing notification system so relevant users can review it before disposition.
Users who can read an object should be able to exempt it from automatic disposition. Exemptions are intentionally low-friction: they prevent accidental deletion, are recorded in Kival's event history, and can be reviewed or revoked by administrators according to organizational governance.
Retention execution should always re-check the current policy and exemption state before applying disposition.
The design should account for Kival's versioned and interconnected data model and avoid silently breaking provenance, object history, authorization semantics, or references between retained data.
Additional context
Retention configuration should live under the kivald admin retention ... command family.
Meaningful retention transitions should use Kival's existing event system, including scheduling, exemptions, exemption revocation, skipped disposition, and completed disposition. This should keep retention activity inspectable through the normal event stream and allow richer filtering or governance views later.
The retention model should be designed as a foundation for future compliance, legal-hold, e-discovery, and records-management capabilities, even where those workflows are not all implemented initially. The design should preserve clear disposition state, auditability, provenance, immutable history, administrative review, and the ability to prevent disposition through exemptions or future legal holds.
Retention applies to data governed by the active Kival deployment and its configured storage. Kival cannot guarantee removal from independent backups, database snapshots, object-store snapshots or versioning, exports, replicas, or other copies managed outside Kival's lifecycle. Organizations remain responsible for applying compatible retention and destruction policies to those systems.
Physical blob deletion should integrate with the blob integrity and garbage-collection tooling rather than introducing an independent cleanup path.
Retention should reuse Kival's existing lifecycle, notification, event, authorization, and durable background-work primitives rather than introducing parallel systems.
Describe the feature
Add configurable retention policies for Kival data.
Organizations should be able to define how long selected categories of data are retained and when they become eligible for disposition.
Matching objects should be scheduled for disposition rather than removed immediately, with a review window before Kival applies its normal deletion/archive lifecycle. When an object enters that review window, Kival should surface it through the existing notification system so relevant users can review it before disposition.
Users who can read an object should be able to exempt it from automatic disposition. Exemptions are intentionally low-friction: they prevent accidental deletion, are recorded in Kival's event history, and can be reviewed or revoked by administrators according to organizational governance.
Retention execution should always re-check the current policy and exemption state before applying disposition.
The design should account for Kival's versioned and interconnected data model and avoid silently breaking provenance, object history, authorization semantics, or references between retained data.
Additional context
Retention configuration should live under the
kivald admin retention ...command family.Meaningful retention transitions should use Kival's existing event system, including scheduling, exemptions, exemption revocation, skipped disposition, and completed disposition. This should keep retention activity inspectable through the normal event stream and allow richer filtering or governance views later.
The retention model should be designed as a foundation for future compliance, legal-hold, e-discovery, and records-management capabilities, even where those workflows are not all implemented initially. The design should preserve clear disposition state, auditability, provenance, immutable history, administrative review, and the ability to prevent disposition through exemptions or future legal holds.
Retention applies to data governed by the active Kival deployment and its configured storage. Kival cannot guarantee removal from independent backups, database snapshots, object-store snapshots or versioning, exports, replicas, or other copies managed outside Kival's lifecycle. Organizations remain responsible for applying compatible retention and destruction policies to those systems.
Physical blob deletion should integrate with the blob integrity and garbage-collection tooling rather than introducing an independent cleanup path.
Retention should reuse Kival's existing lifecycle, notification, event, authorization, and durable background-work primitives rather than introducing parallel systems.