RETENTION & DELETION
Data Retention & Deletion Standard
Purpose-based retention, deletion across active systems, backup expiration, de-identification, legal holds, and future product/research/model-development record classes.
Status: Current governance standard for applicable RTH public operations. Product-specific controls apply when the relevant product or program is enabled.
1. Purpose limitation drives retention
RTH does not use one universal retention period for every record. Each record class should have an approved purpose, owner, retention trigger, deletion method, backup treatment, and legal-hold rule.
2. Current public-site records
Website inquiries, consent records, transaction records, support correspondence, security logs, and other public-site records are retained only as long as reasonably needed for the request, relationship, accounting/tax, dispute, fraud/security, legal, or operational purpose that applies. RTH periodically reviews whether records remain necessary.
3. Future SuperstarIQ records
Before external product data collection begins, RTH will approve and publish product-specific retention rules for account data, user-entered information, imported health/wearable data, generated summaries, AI conversations, audit records, consent, model-routing evidence, and connected-source metadata. User-facing controls should allow deletion where appropriate without erasing records RTH must lawfully preserve.
4. Research records
Research data is retained according to the approved protocol, consent, sponsor/institutional requirements, publication/reproducibility needs, and applicable law. A research retention period can differ from ordinary product retention and must be disclosed before participation.
5. Model-development data
Training, fine-tuning, preference, safety, and evaluation datasets require a specific retention assignment. Dataset snapshots used for a released model may need to be preserved for audit/reproducibility while access is tightly restricted. Personal data should not be placed into long-lived model-development datasets by default.
6. Deletion workflow
Deletion should address primary databases, object storage, vector indexes, caches, derived copies that remain personal data, queued jobs, and vendor systems under RTH control. Deletion evidence should record what was deleted, what remains, why it remains, and when backup copies are expected to expire.
7. Backups
Backups are for resilience, not routine processing. Deleted information may remain in protected backups until scheduled expiration when immediate selective deletion is not technically feasible. Restores must reapply applicable deletion requests before restored data returns to ordinary use.
8. Legal holds
A documented legal hold can suspend ordinary deletion for records reasonably related to litigation, investigation, audit, or another preservation duty. Legal holds must be scoped, access-controlled, periodically reviewed, and released when the preservation duty ends.
9. De-identification
When RTH converts personal data into information that is reasonably designed not to identify or be linked to a person, RTH will use documented de-identification controls and will not attempt to re-identify it except for permitted testing of those safeguards.
Privacy and data requests: privacy@restartingtheheart.com. Do not send medical records, passwords, authentication codes, government identifiers, or other unnecessary sensitive information by ordinary email.
General questions may use the RTH contact page.