A useful soft-delete decision record tells the agent that closed accounts must remain recoverable for 30 days, explains why, identifies the rejected hard-delete option, links affected data and declares only the constraints that CI can objectively check.
The scenario
A user asks to close an account. Product policy promises that the account can be restored for 30 days. After that period, a separate purge process may remove retained data according to the applicable policy.
Without the decision record, an agent implementing a new endpoint might reasonably interpret 'delete account' as immediate physical deletion. The record must convert the product promise into engineering context before the agent chooses the storage operation.
The accepted record
The record should name the user-facing behaviour, the restoration window and the affected boundary. It should state that immediate hard deletion was considered and rejected because it makes the restoration promise impossible. Consequences include a recoverable account state, treatment of dependent records and a delayed purge path.
id: ADR-014
title: Preserve closed accounts for 30 days
status: accepted
Decision: account closure enters a recoverable state.
Rejected: immediate hard deletion.
Reconsider when: the restoration promise changes through review.The retrieval interaction
Before editing deletion code, the agent asks whether a closed account may be hard-deleted. The repository returns ADR-014 and its related retention records. The agent cites the identifier in its plan and proposes a state transition rather than a destructive operation.
The stable citation matters: a reviewer can inspect the exact accepted record instead of trusting the agent's paraphrase.
The enforcement boundary
CI may be able to detect direct hard-delete calls in account-closure code or require tests for restoration. It cannot automatically prove that the entire user experience satisfies every nuance of the policy. Report the objective checks and leave the remainder as explicit review obligations.