Task library RRETENTION Privacy engineering · Phased project Expire support attachments without losing control of exceptions A fictional support service keeps uploaded diagnostic files indefinitely. The exercise policy expires attachments 30 days after case closure, while a separately authorized investigation hold pauses removal. These are invented product rules, not legal advice or compliance certification.
Practice brief · Version 5
Project scope 10 tickets / 3 phases
Total focused work estimate 30h 15m + setup
Suggested stack TypeScript · PostgreSQL · Object storage adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.
Choose a bounded subset for an assessment or practice session. Prerequisites and remaining project work must be agreed separately.
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned.
Recommended next step Start with RRETENTION-101 Open the first ticket for its prerequisites, acceptance criteria, verification plan, and an editable task draft.
What the engineer takes away Practice temporal policy, deletion races, exception authority and truthful recovery reporting.
What the team gains Develop inspectable retention behavior that a company can review against its own approved data policy.
Before you start Create synthetic cases, attachment metadata and a fake object store with controllable failures. Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed. Delivery agreement Ten scoped tickets using local synthetic records. Policy approval, real account access and production deletion are outside the exercise.
AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.
Delivery phases PHASE 1 Make retention decisions explainable and correctly scoped.
PHASE 2 Recheck authority and recover partial failures.
PHASE 3 Measure backlog and rehearse policy changes without obscuring retained data.
Define expiry and exceptions Make retention decisions explainable and correctly scoped.
RRETENTION-101 Entry ticket; project setup still required Estimated field mix
Privacy engineering 70% Backend 30% RRETENTION-102 Depends on RRETENTION-101 Estimated field mix
Privacy engineering 60% Storage systems 40% RRETENTION-103 Depends on RRETENTION-101 Estimated field mix
Security 50% Privacy engineering 50% Apply removal safely Recheck authority and recover partial failures.
RRETENTION-104 Depends on RRETENTION-101, RRETENTION-102, RRETENTION-103 Estimated field mix
Privacy engineering 40% Developer tooling 30% Security 30% RRETENTION-105 Depends on RRETENTION-103, RRETENTION-104 Estimated field mix
Privacy engineering 50% Database engineering 30% Backend 20% RRETENTION-106 Depends on RRETENTION-102, RRETENTION-105 Estimated field mix
Privacy engineering 40% Distributed systems 30% Storage systems 30% RRETENTION-107 Depends on RRETENTION-101, RRETENTION-105 Estimated field mix
Privacy engineering 60% Data engineering 40% Verify ongoing retention Measure backlog and rehearse policy changes without obscuring retained data.
RRETENTION-108 Depends on RRETENTION-104, RRETENTION-106 Estimated field mix
Privacy engineering 60% Site reliability 40% RRETENTION-109 Depends on RRETENTION-104, RRETENTION-105, RRETENTION-107 Estimated field mix
Privacy engineering 60% Site reliability 40% RRETENTION-110 Depends on RRETENTION-106, RRETENTION-108, RRETENTION-109 Estimated field mix
Privacy engineering 40% Site reliability 30% Distributed systems 30% Use this project CSV keeps grouping and dependency keys as descriptive fields. Import mapping depends on your tracker configuration.