Data Retention Cleanup Fabricated Deletion Automation: "Deleted" Without Deleting Anything

Letting an organization set a maximum retention age for its own data, and then automatically enforcing that limit, is a real, meaningful control — both an operational one (bounding how much historical data accumulates) and, depending on what the data contains, a compliance-relevant one. The entire value of that control depends on the enforcement mechanism actually reaching the real data store holding the organization's real records. A cleanup function that reports a specific, plausible-sounding count of rows deleted looks, from every angle a person checking on it would normally use, exactly like a cleanup function that actually deleted something — the number itself carries no signal about which table, if any, it actually came from.

Centriu Axiom's retention-policy feature lets an organization configure, per data resource, a maximum age past which rows should be automatically removed — evidence records captured during a session, exports of a completed session, and individual job-event log entries. A dedicated cleanup function reads an organization's configured policies and, for each one, is meant to delete every row of the relevant resource older than the policy's own cutoff date, then report how many rows were actually removed.

Before this fix, that function's entire implementation operated on `_store` — the same in-memory JavaScript object used throughout the product's own mock/demo mode — with a `switch` statement filtering `_store.evidence`, `_store.sessionExports`, `_store.audit` or `_store.jobEvents` directly by comparing each entry's timestamp to the cutoff, and computing `deleted` as the array's length before the filter minus its length after. There was no check anywhere in this function for which environment or data mode the product was actually running in. Triggering "Run Cleanup" for a real, live organization — using the product's genuinely production-configured Supabase-backed path everywhere else — still reached this exact function, which still only ever touched the in-memory mock array. The organization's real `axiom_evidence`, `axiom_session_exports` and `axiom_job_events` tables, holding the organization's actual production data, were never queried and never modified by this operation, at any point, regardless of how the retention policy was configured or how many runs had already reported success.

The practical consequence is a control that appears, from every angle an operator would normally check, to be working exactly as intended: the cleanup action completes without error, reports a specific, plausible-looking count of rows removed (the mock array does contain some seeded rows, so the count is a real number, just not one describing the real database), and the organization's retention policy shows as actively enforced in whatever configuration screen displays that status. Meanwhile, the organization's actual data — the exact records the policy exists to age out — accumulates without limit in the real database, contradicting both the operational intent of the feature and, for any organization treating retention as a data-minimization control, the substance (if not necessarily the letter, depending on how the policy was represented to that organization) of what the feature was supposed to guarantee.

The fix introduces a real environment check and a genuine, scoped SQL delete for the production path. A mapping (`RETENTION_TABLE_MAP`) associates each resource name with its real table and the specific timestamp column used to age it out — evidence maps to `axiom_evidence` on `captured_at`, exports map to `axiom_session_exports` on `exported_at`, job events map to `axiom_job_events` on `created_at`. For each configured policy, the fix issues a real `DELETE ... WHERE <that column> < cutoff` against the mapped table, with `.select('id')` appended specifically so PostgREST returns the actual rows that were deleted — meaning the `deleted` count reported back is now the genuine length of that returned set, not a value computed from an unrelated in-memory array. One resource, `audit_logs`, is deliberately left out of the table mapping entirely: the fix's own account is explicit that this is correct, not an oversight — the audit log is an append-only table with no organization-scoped delete policy in the database, immutable by design, specifically so that a record of what happened cannot itself be quietly erased by the same mechanism that is supposed to be governed by what happened. For that one resource, and for any resource not present in the mapping, the function now reports a truthful zero deleted, rather than continuing to report a plausible-looking but disconnected number.

Before the fix, an organization configuring a 90-day retention limit on its captured evidence, and later triggering a manual cleanup run, would see a specific count — a genuine number, computed from a real filter operation — reported as rows deleted, with no way to tell from that screen alone that the filter had run against an in-memory demo array rather than the organization's actual evidence table. The organization's real evidence older than 90 days remained in the database, unaffected, no matter how many times cleanup reported success. After the fix, the identical action issues a real, scoped delete against the organization's actual table, and the number reported is the number of rows the database itself confirms were removed.

Centriu Axiom's data-retention cleanup now performs a real, scoped SQL delete against an organization's actual evidence, session-export and job-event tables, with the reported deleted-row count read directly from the database rather than fabricated from an unrelated in-memory array — closing a gap where a configured retention policy could report successful enforcement indefinitely while the organization's real data was never actually purged.

This automation governs Centriu Axiom's own automated retention-cleanup mechanism for evidence, session exports and job events specifically — it does not retroactively purge data that should have been deleted during the period this defect was live (an organization with that specific concern would need its own manual review of records now past their configured cutoff), and it does not extend automated deletion to the append-only audit log, which remains immutable by deliberate design.

Computing a "rows deleted" figure from the length of an array before and after a JavaScript filter is fast, simple, and — critically — indistinguishable in its OUTPUT from a real database delete's own affected-row count, which is exactly what let this defect go unnoticed by anyone reading the reported number alone. Reading the count directly from the database's own response to a real delete statement (via `.select('id')` on the delete) costs nothing extra in complexity and ties the reported number to the one thing it actually needs to represent: rows that genuinely no longer exist in the organization's real data.