Data Retention & Deletion Policy

Last updated: 2026-07-25

> How to read this document. This is the Data Retention & Deletion Policy (this "Policy") of Recovea, Inc., a Delaware corporation — the document that states, honestly and category-by-category, how long Recovea keeps each kind of data, why, how it is deleted, and what (if anything) survives deletion. It is written to match Recovea's actual deployment — United States, AWS us-east-1 (N. Virginia) — and the actual data model of the Service as it operates today. > > This Policy is a summary-and-schedule instrument. The controlling agreements are: the Data Processing Agreement ("DPA") for Customer Personal Data Recovea Processes on the Customer's behalf (processor-side); the Privacy Policy for personal data for which Recovea is the controller; the Security Statement for the live security posture; the BYO-Key Addendum for Provider Key handling and Provider data-retention; and the Terms of Service / Master Services Agreement ("MSA") for the commercial relationship. Where this Policy and the DPA appear to conflict on processor-side processing, the DPA controls. Where this Policy and the Security Statement appear to disagree about what is live today, the Security Statement controls — it is the conservative anchor and no surface may exceed it. The immutable-Ledger erasure carve-out (§5) is stated identically across this Policy, the DPA, the Privacy Policy, the Security Statement, and the Acceptable Use Policy ("AUP"). > > The single most load-bearing — and most honest — section of this Policy is §5: the append-only, hash-chained Ledger versus the right to erasure. Recovea deletes the deletable (account personal data, Provider Keys, opt-in captured bodies, paid-tier cache content, identifiers) and is transparent that the content-free, cryptographically hash-chained Ledger is append-only and tamper-evident — it cannot be silently edited or selectively deleted without breaking the chain that makes it trustworthy. Erasure is handled by tombstoning plus a sanctioned operator path (recoveactl erase-customer), and the content-free integrity record is retained only as permitted by law.

1. Scope, parties, and roles

1.1 Who. This Policy is published by Recovea, Inc., a Delaware corporation, with notice address at 2810 N Church St STE 89986, Wilmington, DE 19802 ("Recovea," "we," "us," "our"). It applies to data Recovea processes in providing the Service — the Recovea AI-spend gateway (api.recovea.ai), the dashboard, account and identity functions, the metering Ledger, and billing — to a business customer ("Customer," "you"). Recovea is a bootstrap-funded U.S. company; nothing in this Policy concerns investment or securities.

1.2 Business use only. The Service is offered to businesses and organizations (18+) for commercial use only and is not intended for personal, family, or household use. This Policy is written accordingly.

1.3 Controller / processor roles; DPA incorporation.

• For personal data inside the Customer's inference traffic — the request/response content proxied in-path ("Inference Content"), and the per-request cost metadata ("Usage Data") generated to meter it (together, to the extent they contain personal data, "Customer Personal Data") — the Customer is the controller and Recovea is the processor, and the DPA governs. Where Recovea Processes Customer Personal Data on the Customer's behalf, the DPA is automatically incorporated into and forms part of the Agreement; it includes the CCPA/CPRA service-provider terms and the U.S.-state addendum by default.
• For personal data Recovea handles for its own account, billing, prospect, marketing, and personnel purposes (Authorized User and admin account data, billing contacts, support correspondents, site visitors), Recovea is the controller and the Privacy Policy governs.
• Where this Policy and the DPA differ on processor-side processing, the DPA controls. The carve-out in §5 is worded identically across this Policy, the DPA, and the Privacy Policy.

1.4 Hosting / location (US only). All Service data is hosted on AWS in us-east-1 (N. Virginia), United States. Recovea is a U.S. corporation. For U.S. Customers there is no cross-border transfer of personal data. This Policy does not reference the EEA, the UK, Switzerland, or any non-U.S. region. International-transfer mechanics live only in the DPA / a standalone transfer addendum and are dormant at launch; this Policy makes no independent transfer representation.

1.5 Honest current state (early access). The Service is offered on an early-access basis. Retention and deletion tooling is described here as it actually operates today; capabilities labeled Planned are not promised, warranted, or to be relied upon. At v1, parts of the erasure workflow are operator-run and partly manual (the sanctioned operator path, §5.5), and the opt-in body time-to-live ("TTL") is cron-enforced and not yet independently audit-verifiable from the data layer (no purged_at audit field a reviewer could inspect). We state this candidly rather than implying a guaranteed, provable retention bound. The Security Statement controls on what is live.

1.6 Regulated / special-category data not permitted. The Customer must not submit protected health information (HIPAA), PCI cardholder data, biometric identifiers, government-issued identifiers, children's data, or other special-category or regulated data through the Service unless separately agreed in a signed writing. Recovea is NOT a HIPAA Business Associate, and the Service is not HIPAA- or PCI-validated. The Customer is solely responsible for compliance and for not transmitting such data. See the AUP, the Terms of Service / MSA, and the DPA.

1.7 No standalone rights; relationship to the agreements. This Policy is informational and operational. It is incorporated into and read consistently with the Terms of Service, MSA, DPA, Privacy Policy, and Security Statement; it does not create rights or remedies beyond those instruments, enlarge Recovea's warranties, or narrow the disclaimers and liability allocations in them. Nothing here is a warranty of uptime, availability, restorability, savings, or any financial outcome. To the extent this Policy and a signed Order Form or the MSA address the same subject, the Order Form/MSA controls per the order of precedence in the Agreement.

1.8 Defined terms. Capitalized terms used but not defined here have the meaning given in the Terms of Service, the MSA, the DPA, and the Privacy Policy. Terms used below — Service; Customer; Customer Personal Data; Authorized User; Subscription; Fees; Provider; Provider Keys; Inference Content; Usage Data; the Ledger; Levers; Verified Savings; in-path; Aggregated/De-identified Data; paid-tier cache; Order Form; DPA; BYO-Key Addendum; AUP — are used consistently across the Recovea legal pack.

2. What Recovea processes, by tier (the data model this schedule applies to)

2.1 Free tier — in-path, observe-only (metadata persisted only). On the Free tier the Service is in-path and observe-only: once the Customer points its base URL at the Service, the Customer's inference traffic transits Recovea on the live request path and is metered, but no Levers are applied and no spend-control enforcement operates on Free. The transit-vs-storage discipline of §2.2 applies equally to Free: the payload is in Recovea's memory during the round-trip (transit is not storage), and Recovea persists Usage Data only (model, token counts, computed cost, usage patterns, timestamps). Recovea does not persist prompt/completion bodies on Free, and no cache and no opt-in body capture exist on Free. Fees (if any) and tier features are set out in the Order Form / pricing page.

2.2 paid tier (paid) — in-path; transit vs. storage stated honestly. On the paid tier the Service is in-path: to fulfil a request, Recovea transits the request/response payload between the Customer's application and the Customer's own Provider, signing the upstream call with the Customer's Provider Key (the inbound Recovea key rcv_ / rcva_ is stripped before the upstream call). Fees are set out in the Order Form / pricing page. Recovea is precise about transit vs. storage:

• Transit (always, on in-path requests). The payload is in Recovea's memory during the round-trip. This is inherent to being an inline gateway. Transit is not storage.
• Usage Data / the Ledger (always persisted, content-free). For every in-path request Recovea persists content-free cost metadata (model, token counts, finish_reason, timestamps, computed cost, Levers applied, any savings deltas) on the Ledger — an append-only, hash-chained record. The Ledger contains no prompt or completion content and no account personal data in its chained rows.
• Request/response bodies — not captured by default; opt-in only. Full request/response bodies are not captured or stored by default. Body capture is opt-in only and, where enabled, is subject to a short TTL then purged (§4).
• paid-tier cache / dedup Levers (response content keyed by a request hash). On the paid tier, the byte-identical exact-cache and dedup/single-flight Levers — the only Levers live at launch — store response content keyed by a request hash for the cache TTL to serve byte-identical repeat requests at lower cost; the entry is then evicted. Cached responses are byte-identical and are never synthesized by Recovea. This content is tenant-isolated, is never used to train, fine-tune, or improve any model, and is processor-side data governed by the DPA.

> Body-persistence statement (read precisely). On the default in-path path, Recovea persists Usage Data metadata plus, on the paid tier, the cache keyed by request hash (which stores response content for the cache TTL). Recovea does not persist full request/response bodies by default. Recovea does not claim that bodies are "never stored": the paid-tier cache stores response content for the cache TTL, and opt-in capture stores bodies for the body TTL. This statement is stated identically across the Privacy Policy, DPA, Security Statement, and this Policy.

2.3 Categories of data, role, and storage posture.

3. Retention schedule

The periods below are the retention windows by category. The schedule matches the Privacy Policy, the DPA, the Terms of Service / MSA, and the Refund & Cancellation Policy exactly — no two surfaces may state different windows for the same category. The principle throughout is data minimization: Recovea retains each category no longer than reasonably necessary for the disclosed purpose, plus any legally required period.

The "retention by tier" windows describe how far back the queryable / visible Usage Data goes (and when account-linked Usage Data is deleted); the content-free, hash-chained integrity record is retained per §5 with the identifier severed on erasure. The two statements are consistent and do not contradict each other.

4. Inference Content, Provider Keys, opt-in body capture, and the paid-tier cache

4.1 Default: bodies not stored. By default the Service does not store request or response bodies. On the in-path tier they are transited in memory to fulfil the request and are not written to durable storage. Absent opt-in (§4.4) and outside the paid-tier cache (§4.5), there is no body corpus at rest.

4.2 Provider Keys. The Customer's Provider Key is stored as ciphertext (AES-256-GCM, with the tenant UUID as additional authenticated data), decrypted in memory only to sign the Customer's own upstream calls, never returned to the client, never logged in plaintext, and shown in plaintext only once at entry. It is deleted/overwritten on removal, replacement, or account deletion. The Customer brings and owns its Provider accounts and keys and pays the Providers directly; Recovea is a neutral conduit and never resells, marks up, sponsors, funds, or takes custody of Provider tokens or Provider spend, and is not a party to the Customer's relationship with any Provider. See the BYO-Key Addendum.

4.3 No training on Customer content, Service outputs, or the Ledger. Recovea does not use Customer data, Inference Content (prompts or completions), Usage Data, opt-in captured bodies, paid-tier cache content, Service outputs, or the Ledger to train, fine-tune, or improve any AI model. This is contractual and architectural (bodies are not retained by default, so there is no body corpus). See the Privacy Policy, the DPA, the AUP, and the Terms of Service.

4.4 Opt-in body capture (consent, TTL, withdrawal, audit). If — and only if — the Customer expressly enables body capture, captured bodies are stored for a time-limited window (24-hour TTL) and then purged by a scheduled (cron-enforced) job. Opt-in is scoped and withdrawable: on withdrawal, Recovea stops capturing prospectively and purges previously captured bodies on the next purge cycle, subject only to the §7 legal-hold exceptions. Honest limitation: the TTL is cron-enforced and is not yet independently audit-verifiable from the data layer — a purged_at audit trail (so a reviewer could confirm the exact purge time of a captured body) is Planned, not live.

4.5 paid-tier cache content. On the paid tier the byte-identical exact-cache and dedup/single-flight Levers store response content keyed by a request hash for the cache TTL (24 hours) to serve byte-identical repeats, then evict it. Cache content is tenant-isolated (cache namespaces salted per tenant; cross-tenant isolation verified per the Security Statement), is deletable on request or account closure (§5.4 / §6), is never used to train any model, and is processor-side data governed by the DPA.

5. The append-only, hash-chained Ledger versus erasure — the honest carve-out (do not skip)

5.1 What the Ledger is. Recovea maintains an internal Ledger of per-request cost and usage metadata (model, token counts, computed cost, Levers applied, savings deltas, timestamps). The Ledger is hash-chained and append-only: each entry is cryptographically linked to the prior entries so the record is tamper-evident — an entry cannot be altered or removed after the fact without breaking the chain and making the alteration detectable. Append-only audit records of privileged operator actions and key-lifecycle events are maintained on the same discipline.

5.2 Why it cannot be silently edited or selectively deleted. The integrity and trust value of the Ledger — the very thing that lets a Customer or an independent third party rely on it as a measurement of record and as the basis for Verified Savings — depends on its immutability. If individual rows could be edited or deleted on demand, the chain would no longer be tamper-evident and the Ledger would be worthless as proof. Therefore Recovea does not edit or delete individual Ledger entries in the ordinary course, and cannot do so without breaking the chain. (Database triggers refuse UPDATE / DELETE against the chained tables.)

5.3 The Ledger is content-free. This carve-out is honest precisely because the Ledger is content-free: it records metadata only (cost / usage) and does not contain request or response bodies, prompt or completion content, account personal data, or Provider Keys. The personal data a deletion request is most concerned with — message content, payloads, account identifiers — is not in the Ledger, and exported Usage Data is likewise content-free metadata (§6.5).

5.4 What is deletable vs. what persists. Stated plainly:

• Deletable on request: account personal data (Authorized User / admin name, email, org, authentication identifiers), the stored Provider Key (ciphertext), any opt-in captured bodies, paid-tier cache content, support data, and account-level identifiers — see §5.5, §6.
• Persists (append-only, content-free): the hash-chained Ledger entries and append-only audit records, which contain metadata only — no payload content and no account personal data. On a verified erasure the identifier linkage is severed (the customer identifier is set to null / tombstoned, customer_id → null, schema-enforced ON DELETE SET NULL), so the retained rows persist in pseudonymized / de-identified form and are not tied to the Customer's identity.
• Non-re-identification commitment. Recovea maintains the severed Ledger rows in de-identified form, will not attempt to re-identify them, and prohibits re-identification. Recovea applies reasonable technical and organizational safeguards (severance of the customer identifier; access controls; tenant isolation; append-only, content-free storage) to keep the severed rows from being reasonably linked back to any individual or Customer. This commitment is given to satisfy the de-identification standard at Cal. Civ. Code §1798.140(m) (CCPA/CPRA).

5.5 Erasure = tombstoning + a sanctioned operator path. On a verified deletion request or account closure, erasure is performed by tombstoning the account and running a sanctioned operator path — today, recoveactl erase-customer — which deletes the deletable categories (§5.4) and severs the identifier linkage to the content-free Ledger (customer_id → null). The content-free integrity record is retained only as permitted by law. The audit/Ledger tables are trigger-protected against UPDATE/DELETE and customer_id is ON DELETE SET NULL. At v1 this path is operator-run and partly manual — automated, audit-verifiable erasure tooling is Planned (§1.5).

5.6 No blanket-deletion promise; the deletion-exception basis. Recovea does not promise to "delete all your data within X days" if that were read to include the content-free immutable Ledger — that promise would be structurally unkeepable and dishonest. Recovea promises instead the honest, specific model in §5.4–§5.5 and §6: delete the deletable, sever / pseudonymize the identifier linkage, and retain only the content-free, tamper-evident integrity record as permitted by law. Retention of that content-free integrity record falls within recognized exceptions to the right to delete under Cal. Civ. Code §1798.105(d) — including completing a transaction and providing the requested service, detecting security incidents and protecting against malicious or illegal activity, complying with a legal obligation, and other internal lawful uses reasonably aligned with the consumer's expectations — and within comparable exceptions under other applicable U.S. state privacy laws. The carve-out is disclosed identically in the DPA, Privacy Policy, Security Statement, and AUP.

5.7 Customer-facing audit-artifact status (no over-promise). Recovea offers a Ledger export + offline re-derivation capability (the export and the standalone verifier ship now). Independent, third-party verification of the Ledger is a reserved future capability that Recovea reserves the right to offer and is not represented as live. This Policy describes the Ledger's immutability honestly without over-promising a customer-visible, independently re-derivable proof beyond what ships today.

5.8 Aggregated / De-identified Data. Recovea may create and retain Aggregated / De-identified Data — statistical, aggregated, or de-identified metadata that cannot reasonably identify any individual or Customer. Such data is retained indefinitely and is outside the scope of deletion / erasure, subject to the non-re-identification commitment in §5.4. This is a standard, disclosed carve-out and does not include payload content, account personal data, or Provider Keys.

6. Deletion on termination and on request; export

6.1 How to request. A Customer (or an individual exercising a data-subject right via the controller) may request deletion by emailing privacy@recovea.ai, or via in-product account-closure controls where available. The data-rights process is described in the Privacy Policy.

6.2 What we delete. On a verified deletion request — and, on account closure, after the export window (§6.5) — Recovea deletes or anonymizes the deletable categories in §5.4 (account personal data, the stored Provider Key, opt-in captured bodies, paid-tier cache content, support data, account-level identifiers) within 90 days, subject to the §7 exceptions.

6.3 What persists, and why. Consistent with §5, the content-free, hash-chained Ledger and append-only audit records persist (metadata only; no payload content; no account personal data), with the identifier linkage severed / tombstoned (customer_id → null) so the retained rows are not tied to the Customer's identity. As stated in §5.4, Recovea maintains the severed rows in pseudonymized / de-identified form, will not attempt to re-identify them, and prohibits re-identification. Recovea will tell the requester plainly what was deleted and what content-free integrity record remains.

6.4 Verification and timing. Recovea will take reasonable steps to verify the requester's identity and authority before deleting and will respond within the period required by applicable U.S. state privacy law (generally within 45 days, extendable once by an additional 45 days where permitted, with notice). If a data subject contacts Recovea directly about Inference Content (processor-side data), Recovea will, where it can identify the Customer, refer the request to that Customer and assist per the DPA. Appeal rights, where applicable under U.S. state law, are handled per the Privacy Policy.

6.5 Export window / portability (content-free metadata). On termination or account closure, Recovea makes the Customer's data (including its Usage Data / Ledger history and account data) available for export for 30 days (the "export window"), after which deletion proceeds per §6.2. During the Subscription term the Customer may export its Usage Data / Ledger history and account data via the dashboard or on request. Exported Usage Data is content-free metadata consistent with §5 (no prompt/response bodies). Export formats are machine-readable JSON and/or CSV, plus the open recovea-chain-v1 ledger format consumable by the standalone verifier binary.

6.6 Deletion on termination (reconciled windows). On termination or account closure: an up-to-30-day export window (§6.5); deletion of the deletable categories within 90 days thereafter (§6.2); removal from operational backups within the backup-rotation cycle (not exceeding 35 days, §7.1); and re-deletion on any restore (§7.1). The content-free Ledger persists per §5 with the identifier linkage severed. Termination and any associated refund mechanics are governed by the Terms of Service / MSA and the Refund & Cancellation Policy; this Policy governs only the data-handling consequences.

7. Backups, legal hold, and statutory-retention overrides

7.1 Backups + re-deletion on restore (honest current state). Backups today are nightly database dumps (pg_dump). Restore from backup has not been tested at production scale; Recovea makes no RTO / RPO commitment and does not represent that data can be restored within any particular time or without loss (Security Statement). Deletable personal data present in operational backups is removed on the ordinary backup-rotation cycle (not exceeding 35 days) rather than by a targeted surgical purge from each individual historical backup. If a backup is restored after a deletion has been processed, Recovea re-applies the deletion (re-deletes the affected data) within thirty (30) days of completing any restore, so that data the Customer asked to delete does not silently reappear.

7.2 Legal hold / litigation hold (override). Notwithstanding the schedule in §3 and the deletion model in §6, Recovea may suspend deletion and preserve specific data where reasonably necessary to comply with law or valid legal process, satisfy tax/audit obligations, enforce or perform an agreement, establish or defend legal claims, or address security or fraud. A legal hold overrides the ordinary retention/deletion windows for the affected data for as long as the hold is required; when released, the data returns to the ordinary schedule and is deleted or anonymized.

7.3 Statutory-retention override (tax/accounting). Billing/invoice and other records that law requires Recovea to keep (e.g., tax and accounting records) are retained for the statutory period (7 years) regardless of an account-closure or deletion request, then deleted or anonymized. These are content-free financial records. Recovea's tax posture is U.S. sales-tax / economic-nexus only.

7.4 Order of precedence for retention. Where they conflict, the longest lawful basis controls the retention of a given record: a legal hold (§7.2) overrides a statutory-retention requirement (§7.3), which overrides the ordinary schedule (§3), which overrides a deletion request (§6). Nothing in §7 expands what Recovea stores in the ordinary course; it governs only when deletion is lawfully deferred.

8. Sub-processors and onward retention

8.1 Recovea's own sub-processors. Recovea's engaged sub-processors at launch are limited to those actually engaged: Amazon Web Services (hosting / compute / storage, identity via AWS Cognito, and Amazon SES for transactional email; us-east-1, USA) and Stripe (payments). Health-check and cron monitoring is AWS-native (CloudWatch/SNS) within the AWS engagement and adds no separate sub-processor. Each retains data only as needed for its function and under its own terms. The authoritative inventory is the Subprocessors list; onward retention obligations are in the DPA. A sub-processor change is notified with 30 days' advance notice plus an emergency carve-out of "as much notice as practicable," with a bounded exclusive remedy (terminate the affected portion + pro-rata refund) — stated identically across the DPA, Privacy Policy, Subprocessors, and Refund & Cancellation Policy.

8.2 BYO-Key Providers are NOT Recovea's sub-processors. The LLM Providers the Customer routes to (OpenAI, Anthropic, OpenRouter) are reached under the Customer's own Provider accounts and keys, at the Customer's direction. They are the Customer's processors / customer-directed recipients / independent controllers, with Recovea acting as a neutral conduit — not Recovea's sub-processors — and so are not within the scope of this Policy's retention schedule. Each Provider retains data per its own terms; where a Provider offers zero-retention or data-handling options, Recovea passes those through where available. The Customer is responsible for its Providers' retention and data-handling. See the BYO-Key Addendum. This conduit / customer-processor characterization reads identically across the DPA, Subprocessors, BYO-Key, Privacy, Security, and Export documents.

9. Security and integrity measures (honest current posture)

9.1 In place today (LIVE). Encryption in transit (TLS); AES-256-GCM at rest under AWS KMS envelope encryption with a per-tenant KMS encryption context (the tenant-UUID is additionally used as authenticated data, including for the Provider Key, so the tenant is bound at both layers); in-memory decrypt only; no body storage by default (opt-in only, TTL-bounded); the inbound rcv_ / rcva_ key stripped before the upstream call and rotatable/revocable; an egress allowlist limiting the gateway to Provider and AWS domains; a closed SSRF class; verified cross-tenant isolation; opaque server-side session / fail-closed auth (Cognito verified once at the edge; raw Cognito tokens never reach the browser); nightly pg_dump; an append-only key-lifecycle audit; and Ledger export + offline re-derivation.

9.2 Planned, not live (do not rely on as present). BYO-CMK (customer-managed keys — stored Provider Keys are protected today by live Recovea-managed AWS KMS envelope encryption; BYO-CMK is Planned; no surface may imply BYO-CMK is live); a purged_at audit trail making the opt-in body TTL independently verifiable; automated, audit-verifiable erasure tooling; independent third-party verification of the Ledger; multi-AZ / HA and tested DR with defined RTO/RPO; SSO/SAML/SCIM; region pinning beyond the single region; and SOC 2 / ISO 27001 / PCI (Recovea holds no such certification today — "aligned to" / roadmap only, never asserted as held). These are Planned and not warranted here. The Security Statement controls on the live posture.

9.3 No absolute-security guarantee; breach notification (both roles). No method of storage or transmission is perfectly secure; Recovea cannot guarantee absolute security.

• Processor-side (Customer Personal Data). Where Recovea acts as processor, personal-data breach notification is "without undue delay" and is governed by the DPA's breach-notification clause; Recovea notifies the Customer (controller), who handles any onward notification to affected individuals and authorities.
• Controller-side (account / billing data). Where Recovea is the controller of personal data (account, billing, support, and other data described in §1.3), Recovea will, in the event of a qualifying breach, notify affected individuals and the relevant authorities as and when required by applicable U.S. state breach-notification law, consistent with the Privacy Policy — these duties are not routed solely to the DPA's processor-side clause.

10. General (legal terms)

10.1 No warranty; AS-IS. THIS POLICY DESCRIBES OPERATIONAL PRACTICES AND IS PROVIDED ON AN "AS-IS" AND "AS-AVAILABLE" BASIS. TO THE MAXIMUM EXTENT PERMITTED BY LAW, RECOVEA DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT, AND MAKES NO GUARANTEE OF UPTIME, AVAILABILITY, DATA RESTORABILITY, SAVINGS, OR ANY FINANCIAL OUTCOME. Nothing in this Policy is a service-level commitment. This disclaimer is mirrored and not narrowed across the Terms of Service, MSA, and Security Statement.

10.2 Limitation of liability; allocation. This Policy creates no independent liability. Any liability arising in connection with the retention, deletion, backup, or export practices described here is subject to the limitations of liability set out in the MSA, Terms of Service, and DPA, which are incorporated by reference and control — including the mutual exclusion of indirect, incidental, special, consequential, exemplary, and punitive damages (and lost profits/revenue/goodwill/data); the general cap (the greater of the total Fees paid by Customer to Recovea in the 12 months before the event and US $25,000); the enhanced (super) cap of 2× the general cap for breach of confidentiality and breach of data-protection / security obligations; and the uncapped exclusions (indemnification obligations; Customer's payment obligations; Customer's breach of the license / AUP / IP-ownership terms; and a party's fraud or willful misconduct; a party's gross negligence remains subject to the caps to the fullest extent permitted by applicable law, per the savings clause stated there). To the extent of any conflict on liability, those instruments — not this Policy — govern.

10.3 Changes to this Policy. Recovea may update this Policy as the product and the law evolve; material changes are notified per the Terms of Service. The "Last updated" date reflects the latest revision. Planned capabilities are not commitments, and Recovea will not retroactively reduce a published retention protection to the Customer's detriment without notice consistent with the Agreement. By continuing to use the Service after an update takes effect, the Customer accepts the updated Policy, subject to any change-of-terms mechanism in the Agreement.

10.4 Precedence. The DPA controls for processor-side processing of personal data; the Privacy Policy controls for controller-side processing; the Security Statement controls on the live security posture; the BYO-Key Addendum controls on Provider Key handling and Provider retention; a signed Order Form and the MSA control over this Policy where they address the same subject. This Policy is read consistently with all of them. The immutable-Ledger carve-out (§5) is stated identically across this Policy, the DPA, the Privacy Policy, the Security Statement, and the AUP.

10.5 Assignment. The Customer may not assign this Policy or the underlying Agreement except as permitted by the MSA / Terms of Service. Recovea may assign in connection with a merger, acquisition, reorganization, or sale of all or substantially all of its assets, provided the successor is bound by retention and deletion commitments no less protective than those here.

10.6 Force majeure. Recovea is not liable for any delay in deletion, backup rotation, re-deletion-on-restore, or export caused by events beyond its reasonable control (including infrastructure or Provider outages, denial-of-service events, natural disasters, or government action), but will resume the affected practice as soon as reasonably practicable and will not use a force-majeure event to retain personal data longer than lawfully permitted.

10.7 Severability. If any provision of this Policy is held unenforceable, that provision is modified to the minimum extent necessary or severed, and the remainder stays in effect.

10.8 Governing law; dispute resolution. This Policy is governed by the laws of the State of Delaware, USA, excluding its conflict-of-laws rules; the U.N. Convention on Contracts for the International Sale of Goods does not apply. Dispute resolution is governed exclusively by the Terms of Service / MSA, and this Policy adds nothing to and subtracts nothing from it. Under that architecture, disputes are resolved by binding arbitration before the American Arbitration Association (AAA) under its Commercial Arbitration Rules, by one arbitrator, seated in Wilmington, Delaware (judgment on the award enforceable in any court of competent jurisdiction), with a class-action / collective / representative waiver and court carve-outs (Delaware state or federal courts, Wilmington) for injunctive / equitable relief for IP or confidentiality matters and for small-claims matters. The parties intend the AAA Commercial Arbitration Rules to apply, subject to the Agreement's Consumer-Rules fallback and mass-arbitration protocol (Terms of Service §24.2 and §24.7 / MSA §23.2 and §23.6): if the AAA or a court of competent jurisdiction determines that the AAA Consumer Arbitration Rules apply to a dispute involving an individual, those rules govern that dispute and Recovea pays the filing, administrative, and arbitrator fees the AAA consumer fee schedule assigns to the business (this is a B2B, business-property service). This Policy states no independent forum.

10.9 E-sign / electronic delivery consent. The Customer consents to receive this Policy, updates to it, retention / deletion notices, export-window notices, and related communications electronically (by email to the account's designated contacts or by posting in-product or on the Recovea website), and agrees that electronic delivery satisfies any legal requirement that such communications be in writing, consistent with the federal E-SIGN Act and applicable state UETA. The Customer may withdraw consent to electronic delivery only by ceasing use of the Service.

10.10 Notices. Retention / deletion questions and data-rights requests: privacy@recovea.ai (the "Privacy Contact"; Recovea is U.S.-only and does not designate an EU DPO or Art. 27 representative at launch). Security reports: security@recovea.ai. Legal notices to Recovea: legal@recovea.ai and the notice address at 2810 N Church St STE 89986, Wilmington, DE 19802.

10.11 Entire understanding (within the pack). This Policy, together with the Terms of Service, MSA, DPA, Privacy Policy, Security Statement, BYO-Key Addendum, and Subprocessors list, constitutes the parties' entire understanding regarding data retention and deletion and supersedes prior statements on the subject.

11. Forward-looking regulatory tracking (counsel-monitored)

This note flags retention / deletion-adjacent legal developments to track with counsel; none changes Recovea's launch posture, and none represents a commitment, a roadmap, or a forthcoming capability.

• Expanding U.S. state privacy laws. New and amended comprehensive state privacy statutes (beyond California's CCPA/CPRA — including Virginia, Colorado, Connecticut, Utah, Texas, and others now or soon in force) continue to harden deletion, data-minimization, and purpose-limitation duties and to shorten response timelines. The tiered schedule (§3) and the sanctioned erase path (§5.5) should be re-confirmed against the then-current map of state laws.
• CPRA data-minimization / retention-disclosure enforcement. California regulators increasingly scrutinize stated retention periods and require retention no longer than reasonably necessary for the disclosed purpose. The retention periods in §3 are concrete and should be kept consistent across the pack.
• U.S. state AI laws (including Colorado's). State AI statutes may impose record-keeping duties on automated/AI systems that could interact with the content-free integrity record in §5. Recovea remains an infrastructure / observability conduit — not a provider, developer, or deployer of a high-risk AI system — and deployer duties sit with the Customer. Track and reconcile.
• Erasure jurisprudence (only if non-U.S. Customers later onboard). The honest carve-out in §5 (content-free integrity record retained, identifier severed) should be re-tested against evolving regulator guidance on the right to erasure versus integrity / accounting retention before any non-U.S. sale. These mechanics remain dormant at launch.
• Verifiable retention controls. The current honest limitations — the opt-in body TTL is cron-enforced but not yet independently audit-verifiable, and automated audit-verifiable erasure is not yet live — are known gaps. Closing them (a purged_at audit trail; automated, audit-verifiable erasure) converts candid caveats into provable controls and reduces substantiation risk.

> Account data, Provider Keys, opt-in captured bodies, and paid-tier cache content are deletable; the content-free, hash-chained Ledger is append-only and tamper-evident; erasure is handled by tombstoning + the sanctioned operator path (recoveactl erase-customer) with the identifier severed (customer_id → null) and the severed rows maintained in de-identified form (no re-identification), and the content-free integrity record is retained only as permitted by law. Exported Usage Data is content-free metadata. Must read consistently with the Privacy Policy, DPA, Security Statement, BYO-Key Addendum, and Subprocessors list.