Data ownership
Removing a module: keep or toss
If you untick an element in the launcher, your data for it is not deleted unless you decide so. The default is to keep it, safely archived.
Status
Built (repo) Built as tested code in the packaging engine, the app core, Simca Logistics and the launcher's removal model (ADR-0005, with retention rules from ADR-0007). Designed There is no screen yet, no restore-backup screen, and no transport between the launcher and the app (an order is a JSON file today).
| Keep (the default) | Toss | |
|---|---|---|
| What happens | The tables are renamed, made read-only and excluded from normal screens. For Logistics, the database file moves aside read-only with a checksum. | The tables are dropped. For Logistics the database file is deleted. |
| Can it be undone | Yes. Adding the element again restores identical data. | Only from the backup taken before the delete. |
| What it needs | Nothing. | The element id typed, a verified backup first, an export for books and personal data, and (for tax-relevant data) a passed retention check and a Spanish acknowledgement. |
Rules that always hold
- No data is deleted without an explicit choice and a verified backup. There is no delete-all, no delete by omission, and a plan file cannot change the default.
- The whole order is checked first: if anything is wrong, nothing changes. Then one transaction does the work, so a failure part-way rolls everything back.
- A smaller build refuses to start over data it does not know about, instead of silently ignoring it.
- Kept data can be deleted later as a separate step with the same confirmations.
- Every action is written to a local log. Nothing is sent anywhere.
Honest limits
- Deleted data is not securely erased: SQLite and the disk may leave traces. Use disk tools if you need secure erase.
- Removal is by whole element. There is no partial delete (for example "older than five years") and no per-record erase.
- Kept archives pile up; there is deliberately no automatic expiry.
- Backups outside Simca are your responsibility, and the launcher must warn if the backup is on the same disk.
Tax-relevant data is further limited by retention rules: see retention and deletion (Peru). Also: entry, data ownership.