- Executive Summary
- Policy And Current Enforcement
- Access And Redaction
- Hold, Expiry And Deletion Procedure
- Ownership And Rollout
Executive Summary
Retain the minimum redacted evidence needed to diagnose acceptance failures and explain a release decision. This document defines an engineering policy proposal and its enforcement gaps. It does not enable deletion, change bucket lifecycle rules or claim existing database rows already expire. Approval of retention periods and an implementation rollout remain separate from writing this policy.
Policy And Current Enforcement
Periods start at artifact creation. Incident/release holds override normal expiry until the named owner releases the hold. Proposed periods below are operational defaults for owner approval, not a legal retention determination.
| Artifact | Proposed Default | Current Repository Behavior | Required Enforcement Work |
|---|---|---|---|
| Synthetic screenshots and visual diagnostics | 28 days | SCREENSHOT_MAXIMUM_AGE=28 controls the existing screenshot cleanup path |
Verify cleanup runs and covers the actual storage location; do not assume all artifacts are covered |
| Redacted network metadata, payload shapes and DB count summaries | 30 days | Embedded scheduled evidence currently follows owning rows | Add reviewed artifact/row expiry with dry-run inventory and holds |
| Downloaded CI report artifacts | 30 days, approved exception at most 90 | Retention input/labels are not a universal LTI storage pruner; individual CI upload settings control artifacts | Verify each uploader and storage policy |
| Redacted run summaries and release decisions | 90 days; retain held release evidence until owner disposition | ScheduledTest, Task and ReportTable retain history indefinitely in compatibility behavior | Archive/export safely before introducing expiry |
| Scenario definitions, specs and reviewed contracts | Version-controlled history | Repository/catalogue lifecycle | Keep normal source control and access policy |
| Agentic scenario attachments | 28/30 days by artifact type | Currently retained with owning step/scenario | Add explicit expiry without deleting parent scenarios |
| API access audit | Separate security policy | Anonymous entries have existing 7-day pruning; authenticated history is indefinite | Security owner must approve any change; this policy does not alter it |
Backups inherit the organization's separately approved backup policy. Artifact expiry must document any backup-restoration exposure and eventual backup expiry rather than promise immediate erasure from every copy.
Access And Redaction
Use authenticated internal evidence storage. Keep raw donor/member identifiers, email addresses, payment data, cookies, tokens, authorization headers and personalized query strings out of retained output. Prefer synthetic aliases, count deltas, bounded status codes, payload field names and opaque internal run references. Redact before storage, not only when exporting a summary.
Do not make buckets, reports or screenshots public to simplify review. Asana comments link to controlled evidence and summarize findings without reproducing sensitive material. A redacted renderer cannot sanitize the original report retroactively.
Hold, Expiry And Deletion Procedure
- Inventory artifact ID, storage location, creation/expiry time, owning run and hold state. Do not enumerate donor content into the inventory.
- Produce a dry-run manifest scoped to acceptance artifacts. Check referenced release/incident records and record approver.
- Validate a bounded sample, preserve required evidence and test restoration of the manifest/metadata under the approved backup process.
- Delete only approved expired artifact IDs using a separately reviewed job. Never cascade-delete scenario, donation or member rows to remove a screenshot.
- Record counts, failures and a redacted audit record. Alert on failed expiry and storage growth; do not silently mark the work done.
This PR executes none of these deletion steps. Synthetic business-data cleanup is a distinct workflow and requires its own authorization.
Ownership And Rollout
The E2E owner maintains evidence classes, the platform owner implements lifecycle enforcement, and the security/data owner approves retention exceptions and access. Before activation, create an implementation task with the accepted periods, hold mechanism, dry-run results, restore test and monitoring. Review the inventory quarterly and after any new artifact type or provider integration.