# noCV engineering task library Content version 5 Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs. Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence. ## RRETENTION — 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. **Field:** Privacy engineering. **Suggested stack:** TypeScript, PostgreSQL, Object storage adapter. **Engineer value:** Practice temporal policy, deletion races, exception authority and truthful recovery reporting. **Company value:** Develop inspectable retention behavior that a company can review against its own approved data policy. **Delivery agreement:** Ten scoped tickets using local synthetic records. Policy approval, real account access and production deletion are outside the exercise. ### Setup prerequisites - 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. ### Define expiry and exceptions Make retention decisions explainable and correctly scoped. #### RRETENTION-101 — Calculate attachment expiry from the case closure instant **Task · Medium priority · Foundational** noCV practice brief v5 · RRETENTION-101 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define expiry and exceptions. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 70% · Backend 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Files uploaded long before a case closes are being removed too early because the prototype starts the retention clock at upload. Acceptance criteria - Use case closure plus 30 elapsed days as the exercise expiry instant. - Keep open cases ineligible and represent missing closure data explicitly. - Return the policy version and reason with each eligibility decision. Implementation constraints - Use UTC instants and an injected clock; do not substitute local calendar dates. Verification - Evaluate immediately before and at expiry. - Evaluate open and missing-closure fixtures without scheduling deletion. Deliverables - Retention decision function and boundary fixtures Rollout and recovery: Run decisions in preview mode before enabling any removal path. Project prerequisites: 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. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### RRETENTION-102 — Inventory every storage location used by one support attachment **Task · Medium priority · Foundational** noCV practice brief v5 · RRETENTION-102 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define expiry and exceptions. Depends on: RRETENTION-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Storage systems 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Removing the primary upload leaves its thumbnail and a cached diagnostic preview behind. Acceptance criteria - List primary object, derived previews, metadata and any backup copy in a bounded data-flow inventory. - Assign an owner and retention behavior to each location. - Mark unknown or external copies explicitly instead of declaring removal complete. Implementation constraints - Use the fictional architecture and local adapters; do not discover or copy real customer data. Verification - Trace one synthetic upload through each declared location. - Add an unknown derived location and verify the inventory marks coverage incomplete. Deliverables - Attachment lifecycle map and location registry Rollout and recovery: Review the registry before wiring purge adapters; new derived stores require an inventory update. Project prerequisites: 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. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### RRETENTION-103 — Require scoped authority to place an attachment on investigation hold **Story · Medium priority · Intermediate** noCV practice brief v5 · RRETENTION-103 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define expiry and exceptions. Depends on: RRETENTION-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Privacy engineering 50%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Any support member can currently set a permanent hold with no reason, and the flag has no owner for later review. Acceptance criteria - Require tenant-scoped hold authority, a bounded reason category and a review date. - Append hold creation and release records with actor and policy version. - Deny a foreign-tenant or ordinary-member hold command before mutation. Implementation constraints - Keep free-text case content out of generic audit logs; an audit records the privileged action and safe identifiers. Verification - Create and release a hold as the authorized synthetic operator. - Attempt both commands from another tenant and an unprivileged member; verify no change. Deliverables - Hold commands and authorization regressions Rollout and recovery: Introduce hold management before purge activation so active exceptions can be represented. Project prerequisites: 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. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Apply removal safely Recheck authority and recover partial failures. #### RRETENTION-104 — Preview the attachment purge set with stable decision reasons **Story · Medium priority · Intermediate** noCV practice brief v5 · RRETENTION-104 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply removal safely. Depends on: RRETENTION-101, RRETENTION-102, RRETENTION-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Developer tooling 30% · Security 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Operators cannot tell why two similarly aged attachments are treated differently by the retention job. Acceptance criteria - Return bounded pages of eligible, held and ineligible records with policy and decision timestamp. - Keep preview tenant-scoped and omit file contents and unrestricted object URLs. - State that preview is advisory and execution rechecks current eligibility. Implementation constraints - Use stable cursor ordering; a preview must never claim to lock the future purge set. Verification - Compare expiry and hold fixtures with the decision function. - Place a hold after preview and verify the preview itself causes no deletion. Deliverables - Purge-preview endpoint and scoped pagination tests Rollout and recovery: Expose preview to authorized local operators first; disable the view independently of lifecycle records. Project prerequisites: 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. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### RRETENTION-105 — Recheck holds when a queued attachment purge begins **Bug · High priority · Advanced** noCV practice brief v5 · RRETENTION-105 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply removal safely. Depends on: RRETENTION-103, RRETENTION-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Database engineering 30% · Backend 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. An attachment becomes held after the purge queue is populated, but the worker trusts the old eligibility flag and removes it anyway. Acceptance criteria - Re-evaluate current policy and hold state before issuing removal. - Define coordination between hold creation and a purge already crossing its irreversible boundary. - Return an explicit conflict or too-late state without claiming a newly created hold restored deleted bytes. Implementation constraints - Model the race using a controlled storage adapter; document the exact serialization boundary. Verification - Pause before removal, place a hold and verify the object remains. - Race hold creation with confirmed removal and verify the declared conflict outcome and truthful audit. Deliverables - Purge/hold transition protocol and race tests Rollout and recovery: Keep deletion disabled until both race orderings pass; preserve metadata for any ambiguous external operation. Project prerequisites: 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. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### RRETENTION-106 — Retry partial attachment removal without forgetting derived copies **Bug · High priority · Advanced** noCV practice brief v5 · RRETENTION-106 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply removal safely. Depends on: RRETENTION-102, RRETENTION-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Distributed systems 30% · Storage systems 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The primary object is gone but thumbnail removal timed out. A retry treats the missing primary as success for the entire attachment. Acceptance criteria - Track per-location progress and idempotent removal outcomes. - Distinguish not-found from authorization and transport failure. - Mark the purge complete only when every required location is confirmed or an explicit unresolved exception remains. Implementation constraints - Keep evidence of unresolved copies in restricted operational records; do not expose storage credentials in failure text. Verification - Fail thumbnail removal after primary success, retry and verify both locations are reconciled. - Inject a forbidden response and confirm it remains unresolved rather than being treated as already absent. Deliverables - Per-location purge state and partial-failure regressions Rollout and recovery: Retry only incomplete locations; stop promotion when a provider cannot give a trustworthy deletion outcome. Project prerequisites: 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. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### RRETENTION-107 — Record a reopened case without silently resetting attachment history **Bug · High priority · Advanced** noCV practice brief v5 · RRETENTION-107 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply removal safely. Depends on: RRETENTION-101, RRETENTION-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Data engineering 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Reopening a case overwrites its closure timestamp. Support can no longer explain whether an attachment was eligible when a purge started. Acceptance criteria - Append case lifecycle events and derive the current retention clock under an explicit reopening rule. - Preserve previous decisions and completed removal history. - Prevent reopening from implying deleted attachments can be recovered. Implementation constraints - Define the exercise rule before coding: reopening pauses eligibility; a later closure starts a new 30-day period for remaining attachments. Verification - Reopen before expiry and verify ineligibility, then close again and verify the new boundary. - Reopen after confirmed purge and show the attachment remains removed with its original decision history. Deliverables - Reopening policy and historical decision tests Rollout and recovery: Version the policy and preview changed eligibility before activating the new clock behavior. Project prerequisites: 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. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Verify ongoing retention Measure backlog and rehearse policy changes without obscuring retained data. #### RRETENTION-108 — Report retention backlog without listing customer file names **Chore · Medium priority · Intermediate** noCV practice brief v5 · RRETENTION-108 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify ongoing retention. Depends on: RRETENTION-104, RRETENTION-106. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Site reliability 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The only retention report exports every filename to a general analytics dashboard. Acceptance criteria - Expose aggregate eligible, held, failed and completed counts plus oldest eligible age. - Keep filenames, object keys and case content out of generic metrics. - Provide authorized drilldown through the scoped operational view instead of metric labels. Implementation constraints - Use bounded outcome categories and distinguish zero eligible records from unavailable measurements. Verification - Reconcile aggregate counts with a synthetic fixture containing each outcome. - Insert sensitive-looking filenames and verify no value reaches the metric payload. Deliverables - Retention metrics and sanitized payload tests Rollout and recovery: Run aggregate reporting beside the restricted preview; remove the old filename-based dashboard after validation. Project prerequisites: 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. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### RRETENTION-109 — Rehearse a shorter retention policy without deleting on preview **Task · Medium priority · Expert** noCV practice brief v5 · RRETENTION-109 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify ongoing retention. Depends on: RRETENTION-104, RRETENTION-105, RRETENTION-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Site reliability 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Product proposes reducing the exercise retention period from 30 to 14 days. Applying the constant immediately would make a large backlog eligible at once. Acceptance criteria - Create a new policy version and produce a tenant-scoped impact preview. - Define activation time, bounded purge batches and preserved hold semantics. - Document that rollback can stop future deletion but cannot restore confirmed removed objects. Implementation constraints - Treat 14 days as a proposed fictional rule requiring review in the exercise workflow, not a real-world policy recommendation. Verification - Compare old and new decisions at activation boundaries with active holds. - Cancel activation and verify no objects were removed by the preview; rehearse stopping after one controlled purge batch. Deliverables - Policy-change plan, impact report and stop procedure Rollout and recovery: Require the explicit local activation command after review; retain previous policy and append the activation record. Project prerequisites: 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. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### RRETENTION-110 — Verify retention recovery after an interrupted purge run **Task · Medium priority · Expert** noCV practice brief v5 · RRETENTION-110 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify ongoing retention. Depends on: RRETENTION-106, RRETENTION-108, RRETENTION-109. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Site reliability 30% · Distributed systems 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The purge process crashes between provider acknowledgement and state persistence. The dashboard cannot tell which objects remain. Acceptance criteria - Reconcile uncertain per-location states through the declared provider contract. - Preserve held and not-yet-eligible objects while converging repeated retries. - Produce a report separating confirmed removal, retained exceptions and unresolved provider outcomes. Implementation constraints - Use synthetic objects and deterministic crash points; a completed job record alone does not prove every copy is gone. Verification - Interrupt before and after each storage acknowledgement and compare actual fixture objects with recorded states. - Repeat reconciliation and verify no duplicate privileged transition and no newly removed held object. Deliverables - Crash matrix, reconciliation procedure and truthful retention report Rollout and recovery: Enable scheduled local purge only after recovery cases pass; unresolved states remain visible for authorized review. Project prerequisites: 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. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence.