Decide how long each kind of data is kept. Swiftward deletes it on time and records every deletion.
Some data you have to keep for years, because an auditor or a customer who disputes a decision can ask about it long after it was made. Personal data you have to delete once you no longer need it. You set a retention period for each kind of data, and Swiftward moves and deletes the data on that schedule.
Built into the Swiftward service you run. A retention period is one line in a declaration.
Archive first, delete later
persistence:
backend: postgres
archive:
backend: clickhouse
after: "30d"
purge:
after: param("decisions.retention_days") archive.after says when a record moves from the main database, Postgres, to the archive, ClickHouse. A search covers both, so you find a decision from three years ago the same way as one from this morning. If you must keep decisions for seven years, they can spend one month in the main database and the rest of the time in the archive.
purge.after says when the record is deleted from both. You can write a fixed period, such as "30d", or use a parameter. A parameter can be changed without redeploying Swiftward, and it can be different for each tenant.
The EU AI Act asks a deployer of a high-risk AI system to keep its logs for at least six months (Art. 26(6)). Set the period for decision records to at least that.
What is kept, and for how long
| Data | How long it is kept |
|---|---|
| The event queue: events waiting to be evaluated | a few days. A row is deleted only after its event is processed, and the event itself stays in its decision record. |
| Decision records: the event as it arrived, the verdict, the rule that decided, and the frozen policy version it ran on | the longest, often years, and most of that time in the archive. |
| Review cases: the material a person was asked to judge, and their decision | short, because this is the most sensitive data. An open case stays in the main database, and only a decided case moves to the archive. |
| The operations and changes audits: who did what, and each row before and after a change | set for each tenant by your team that runs the Swiftward deployment. A tenant can see its period and cannot change it. |
| The retention log: every archive and delete run: which data, which tenant, up to which date, and how many rows | set it at least as long as the longest period above, so that every deletion can still be explained. |
Archiving and deleting can carry a condition, as the event queue and review cases show: a row goes only when it matches.
Verification tells a planned deletion from tampering
Decision records, both audits and decided review cases carry tamper-evidence. A deletion on schedule leaves a gap in them, and so would an attacker.
The retention log tells the two apart. When you verify the audit trail, a record deleted on schedule is counted as deleted, and a record missing for any other reason is reported to you.
Before you choose the periods
A review case is deleted when its retention period ends, decided or not. Give the rule that opens the case a timer shorter than that period. When the timer runs out, the case gets the answer you set in advance, so every case has a decision before it is deleted.