Data Lifecycle

A lifecycle record names every choice the team makes about a record's lifetime in one place: what kind of data it is, how long it stays, what triggers deletion, and how holds, exports, restores, and backups behave. Without that record, the choices scatter across tickets and memory, and a deletion runs before anyone checks the retention bound. Retention bounds live in setting records.

Reviewed forEach lifecycle record names classification, retention, deletion trigger, hold, export, restore, and backup.

Marked guidance: a reviewer answers this question.

When no use case needs the data back, removing the row deletes the least and keeps the least: no hidden state, no filtered queries, no purge job to write and watch. A team that keeps deleted rows just in case pays for retention without a requirement and answers subject-access exports with data it promised to delete.

An expense deleted without a retention duty removes the expense row in the delete transaction.

Reviewed forDeletions with no retention or restore requirement remove the row in the delete transaction.

Marked guidance: a reviewer answers this question.

A record that stays after deletion or moves to an archive still affects the product: it appears in some reads, skips others, and can return. A named state with a named transition shows that behavior in the aggregate itself, so a reader sees which transitions exist and which checks each one runs. Without the transition, the retained data is a row the code treats specially in scattered places.

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

Reviewed forEach retained record carries a business reason with a named state transition.

Marked guidance: a reviewer answers this question.

A boolean column that only the storage layer reads can flip without running the business checks: no authorization, no audit entry, no named transition a reviewer can find. The record then looks deleted in one query and active in another, depending on which filter the query remembered. An explicit lifecycle operation keeps the flag, where one exists, as an effect of the transition rather than the transition itself.

Reviewed forEach lifecycle transition runs through explicit behavior rather than a storage-only flag.

Marked guidance: a reviewer answers this question.

Delete, archive, and restore change what the business promises about a record, so the aggregate owns them the way it owns any rule: one method per operation, with the checks beside the change. When the operation lives anywhere else, two callers implement it two ways and the checks drift apart.

Reviewed forEach aggregate exposes delete, archive, and restore methods where those operations apply.

Marked guidance: a reviewer answers this question.

Deleting or restoring the wrong record harms a customer or breaks a legal duty, so each lifecycle operation checks that the actor may perform it.

Reviewed forEach lifecycle operation checks its documented authorization before changing the record.

Marked guidance: a reviewer answers this question.

The audit entry lets a reviewer answer who deleted what and when, which a subject-access or legal-hold dispute asks for first.

Reviewed forEach lifecycle operation writes an audit record, or a standalone record where audit is not selected.

Marked guidance: a reviewer answers this question.

A query filter or a property setter runs without the business checks: it filters rows in storage while the aggregate never learns the transition happened. The product then enforces lifecycle in two places that disagree, and a new query that skips the filter exposes data the lifecycle retired.

Reviewed forNo lifecycle transition runs through persistence filters or property setters alone.

Marked guidance: a reviewer answers this question.

An employee browsing expenses expects live data: deleted and archived records in that list confuse the employee and leak data the lifecycle retired. Normal queries therefore read only the active state, while the named privileged paths serve the records outside it.

Reviewed forNormal queries read only the active state, with deleted and archived records absent.

Marked guidance: a reviewer answers this question.

Restore and administration queries reach records normal queries cannot see, so they need a path of their own with checks of their own. Without the named path, a privileged read hides inside normal query code and inherits normal authorization, which grants too much to too many callers.

Reviewed forAdministrative and restore queries run through named paths with explicit authorization.

Marked guidance: a reviewer answers this question.

Other records can point at the deleted one, exports can carry its values, and a unique value such as an expense reference number can become available again. When the specification stays silent, each developer guesses: one nulls the reference, another keeps it, and a duplicate value slips through or a report breaks. Writing the behavior down gives every reference, export, and constraint one answer.

Reviewed forThe specification states post-deletion behavior for references, exports, and unique constraints.

Marked guidance: a reviewer answers this question.

A document store keeps whatever the aggregate writes, so the team states how each lifecycle state lands in the document: which state the document carries, which queries filter it, which indexes serve those queries, how a purge rewrites the document, and how the contract changes when the shape does. Without those choices, the business transition lands in storage by accident and each query invents its own filter.

Reviewed forThe document implementation states document state, filtered queries, indexes, purge transformations, and contract evolution.

Marked guidance: a reviewer answers this question.

A relational table keeps retained rows beside active ones, so the team states which columns mark the state, which query filters hide retained rows, which partial indexes keep active values unique, which migrations add all of it, and what each named filter means. Without those choices, a unique constraint blocks a legitimate reuse or a query returns rows the lifecycle retired.

Reviewed forThe relational implementation states columns, query filters, partial indexes, migrations, and named filter behavior.

Marked guidance: a reviewer answers this question.

Filters, indexes, and migrations behave differently per provider, and a filter that works on documents can fail on tables. Tests that read through both the normal path and the lifecycle path on the selected provider catch the difference before a customer does.

Reviewed forTests read through normal and lifecycle query paths on the selected provider.

Marked guidance: a reviewer answers this question.

A purge or archive job can run for hours across millions of rows, and a deployment, a failure, or an operator stops it midway. Resumable, bounded, cancellation-aware work restarts where it stopped instead of from the beginning, and observable progress tells the operator whether it moves or stalls.

Reviewed forPurge and archive work resumes after interruption within declared bounds, with visible progress.

Marked guidance: a reviewer answers this question.

A legal hold suspends the duty to delete: the named data stays until the hold releases, even when its retention date passes. A retention job that ignores the hold destroys evidence the organization had a duty to keep.

Reviewed forRetention runs leave held data in place past its retention date.

Marked guidance: a reviewer answers this question.

A retention run can stop midway through millions of rows, and recorded progress tells the next run where to resume. Observable progress tells the operator whether the job moves or stalls.

Reviewed forRetention runs persist progress that the next run resumes from.

Marked guidance: a reviewer answers this question.

A hold suspends the duty to erase, and releasing it resumes that duty from a date the team can name. Without a release record, nobody can state when the suspension ended, so a subject's erasure request has no answer date and the next retention run cannot tell which data is deletable again. The record also tells the retention job exactly which data resumed which retention date.

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

Reviewed forEach legal-hold release records actor, data covered, reason, and resumed retention.

Marked guidance: a reviewer answers this question.

A deletion promise covers every copy the product keeps, including backups and replicas that restore for months after the live row disappears. When backup behavior stays undocumented, the team promises erasure it cannot deliver and learns the gap during an audit or a restore.

Reviewed forBackup and replica operations follow the documented deletion guarantee.

Marked guidance: a reviewer answers this question.