Data Lifecycle

Requirement A lifecycle record MUST name classification, retention, deletion trigger, purge owner, hold, export, restore, backup, owner, and status.

Rationale The contract establishes the data lifetime and the owner of each later action. Retention bounds are Limit records, and a draft names its decider and decide-by date.

Requirement A lifecycle implementation MUST use hard delete when no accepted retention or restore requirement applies.

Rationale Hard delete is the smallest lifecycle state when no later business action needs retained data.

Requirement A soft-deleted or archived record MUST have a business reason and explicit state transition.

Rationale The state transition makes retained data behavior visible in the aggregate model.

Example Archive changes aggregate state after the authorization and audit checks succeed.

Requirement A lifecycle implementation MUST NOT use a hidden boolean as its sole lifecycle behavior.

Rationale A hidden flag omits the business transition, authorization, and audit boundary.

Requirement A Domain aggregate MUST expose delete, archive, and restore as explicit behavior when those operations apply.

Rationale Explicit behavior gives lifecycle transitions one business owner.

Requirement A lifecycle operation MUST apply its documented authorization, recording its audit as an audit record when audit is selected and a standalone record otherwise.

Rationale Retention and deletion can have legal and business consequences.

Requirement A lifecycle rule MUST NOT rely only on persistence filters or property setters.

Rationale Storage behavior cannot replace an aggregate-owned lifecycle transition.

Requirement A normal query MUST exclude deleted or archived records.

Rationale Normal product behavior does not expose records outside their active lifecycle state.

Requirement An administrative or restore query MUST use a named path with explicit authorization.

Rationale Privileged recovery and administration require a distinct access boundary.

Requirement A lifecycle specification MUST define post-deletion behavior for cross-aggregate references, exports, and unique constraints.

Rationale References and reuse rules can outlive the record that originally owned a value.

Requirement A Marten lifecycle implementation MUST define document state, filtered queries, indexes, purge transformations, and contract evolution.

Rationale Marten storage needs explicit lifecycle behavior beyond an aggregate transition.

Requirement An EF Core lifecycle implementation MUST define columns, query filters, partial indexes, migrations, and named filter behavior.

Rationale Relational storage needs explicit query and uniqueness behavior for retained records.

Requirement A selected persistence provider MUST test normal and lifecycle query paths.

Rationale Provider behavior can differ between active and retained records.

Requirement A purge or archive operation MUST be resumable, bounded, cancellation-aware, and observable.

Rationale Long-running lifecycle work needs safe interruption, progress, and retry behavior.

Requirement A retention job MUST record progress and preserve data under legal hold.

Rationale A legal hold overrides scheduled deletion until its documented release.

Requirement A legal-hold release MUST record actor, data covered, reason, and resumed retention: an audit record when audit is selected, a standalone record otherwise.

Rationale A hold suspends an erasure obligation, and its release resumes that obligation. Without a record, no one can state when the suspension ended. A subject's erasure request then has no answer date. The release is also the point where data becomes deletable again. The next retention run needs an unambiguous release record.

Example A release record names the hold, the release date, and the retention date the covered data now carries.

Requirement Backup and replica operations MUST follow the documented deletion guarantee.

Rationale Retained copies affect the practical meaning of a deletion promise.