Recovea — Sub-processors Inventory

Last updated: 2026-08-05

0. Purpose, status, and how to read this document

This document is the authoritative, current inventory of the third parties (Sub-processors) that Recovea, Inc., a Delaware corporation ("Recovea," "we," "us," "our"), engages to deliver the Services. It exists to give Customers and their security, privacy, and procurement teams a single honest source of truth about who Processes data on Recovea's behalf, what data they touch, where, and under what engagement status.

It is incorporated by reference into the Data Processing Agreement (the "DPA," see data-processing-agreement.md, §6) and is summarized for convenience in the Privacy Policy (privacy-policy.md, §7) and the Security Statement (security-statement.md, §10). The convenience summaries may lag this document; this document controls the inventory facts.

Operating posture (US-only). Recovea is a bootstrap-funded United States company serving business customers only (18+); the Services are not for personal, family, or household use. Nothing here concerns investment or securities. All Recovea-engaged Processing occurs in the United States (AWS us-east-1, N. Virginia), except that billing-contact data provided to the payments processor may be Processed by that processor on its own infrastructure under its own terms (§7). This document does not reference the EU or any non-US region as a place of Recovea-engaged Processing. The dormant EEA/UK/Swiss international-transfer contingency (§7.3) lives in the DPA and applies only if and when Recovea onboards an EEA/UK/Swiss-established Customer.

0.1 Status discipline (a hard rule, not a courtesy)

Recovea keeps its Sub-processor list deliberately short and labels each vendor with an honest engagement status. The taxonomy is binary:

• Engaged — governing terms are in force and the vendor actually Processes Recovea or Customer data in production today. A row is not marked Engaged until both are true.
• Planned — the vendor or service is genuinely selected and named ahead of time for transparency, but it is not yet engaged and receives no data today. (A vendor that is selected but not yet contracted is folded into Planned and the distinction is disclosed in prose.)

This discipline cuts both ways. We do not flip a vendor to Engaged before it is under contract and Processing data; equally, we do not leave a vendor as Planned if it is, in fact, live. The underlying cloud host (AWS) is Engaged today because the production environment runs on it.

Pre-listing does not run the objection clock. Pre-listing a vendor as Planned is a transparency courtesy. It does not, by itself, constitute the change-notice required by §5 and does not start the objection window. A flip from Planned to Engaged triggers a fresh §5 change-notice and a new objection window before the vendor Processes any Customer Data. The authoritative table in §2 carries one fixed status per row and contains no conditional ("Engaged if…") values.

1. Scope and definitions

1.1 Sub-processor. A third party engaged by Recovea that Processes Customer Personal Data or other Customer Data on Recovea's behalf in connection with providing the Services, as that role is defined in the DPA and applicable Data Protection Laws (including the role of "Service Provider" or "subprocessor" under the CCPA/CPRA and analogous US state privacy laws).

1.2 What this list covers. Third parties engaged by Recovea to deliver the Services. It does not purport to list every internal tool Recovea uses that never touches Customer Data, and it does not list the Customer's own LLM Providers, which are not Recovea's Sub-processors (§3).

1.3 The Services (one line). Recovea is an in-path AI-spend gateway: a Customer changes one base_url to route its LLM API traffic (OpenAI-compatible /v1, Anthropic /anthropic, OpenRouter long-tail) through Recovea (api.recovea.ai) using the Customer's own Provider API keys (BYO-Key — Bring Your Own Key). The Customer pays its Providers directly; Recovea does not resell, rebill, mark up, sponsor, fund, or take custody of Provider tokens or Provider spend, and is not a party to the Customer's Provider relationships. The Services are the umbrella offering and may include optimization, additional features and capabilities Recovea may offer; any such capability is governed by the terms in effect when Recovea makes it available and is not active or licensed under this document unless Recovea expressly states otherwise.

1.4 Controller / processor split (stated identically across the pack). "Customer Personal Data" means Personal Data that Recovea Processes on the Customer's behalf in providing the Services — namely the Personal Data of Authorized Users contained within Inference Content and Usage Data. With respect to Customer Personal Data, the Customer is the controller and Recovea is a processor (and Sub-processors engaged by Recovea are sub-processors). With respect to Recovea's own account, prospect, marketing, and personnel data, Recovea is an independent controller. Recovea engages Sub-processors only as needed to provide the Services.

1.5 Data categories referenced below (consistent with the DPA and Privacy Policy):

• Account & authentication data — account/user email, Authorized User seat/role assignments, authentication identifiers.
• Usage Data (cost metadata) — model, token counts, finish_reason, computed cost, request patterns, timestamps. Not request/response bodies.
• Billing data — billing-contact details and invoice amounts, handled via the payments processor.
• Inference Content — the request/response (prompt/completion) content proxied in-path on the paid tier. Body-persistence (definitive): request and response bodies are not persisted as a durable body store by default. On the paid in-path tier, Inference Content transits the hosting layer so the gateway can meter it and apply cache/dedup Levers; bodies are Processed in memory and are not written to durable storage except where a Customer enables the paid-tier response cache, in which case the cache stores response content keyed by a request hash for a configurable time-to-live (TTL), after which the cached entry is automatically evicted. Apart from that opt-in cache, only Usage Data metadata (not bodies) is persisted. This statement is identical in data-retention-and-deletion-policy.md and §4.1.

1.6 The Ledger. Recovea maintains a hash-chained, append-only, content-free metering Ledger — metering facts only (model, token counts, computed cost, timestamps), never Inference Content bodies and never account PII. Its immutability underlies the honest deletion carve-out in the DPA and data-retention-and-deletion-policy.md.

1.7 Provider Keys. The Customer's own upstream Provider API keys, encrypted at rest with AES-256-GCM (tenant UUID as additional authenticated data) and decrypted in memory only to sign the Customer's own upstream call. Key wrapping uses AWS KMS envelope encryption, live today with a per-tenant KMS encryption context and tenant-bound AEAD (see §2.1); BYO-CMK (customer-managed keys) is planned and not live today.

1.8 Capitalized terms not defined here have the meanings given in terms-of-service.md, the DPA, and byo-key-and-provider-terms.md.

2. Current Sub-processor list (authoritative)

> Region note. AWS-hosted infrastructure runs in us-east-1 (N. Virginia), United States — the actually deployed region, and the sole data-hosting location for Recovea-engaged Processing. This list reflects production, not aspiration; the DPA residency/transfer clause is aligned.

> Due diligence. Before engaging any Sub-processor, Recovea performs reasonable, proportionate diligence (security and data-protection review) and contracts for data-protection terms no less protective than those Recovea owes the Customer under the DPA (§6). Recovea is a small-team company and scales this diligence as it grows; it does not represent a formal third-party-risk-management program (TPRM) it does not run. Recovea keeps a written vendor-review note for each Engaged Sub-processor.

2.1 AWS — honest key-management note. AWS is Engaged today as the host of the live production environment. Provider Keys are protected with AWS KMS envelope encryption, live today: each key is sealed under a KMS-wrapped data key with a per-tenant KMS encryption context, and the sealed record additionally binds the tenant in the AEAD's authenticated data (AES-256-GCM), so the tenant is bound at BOTH layers. The KMS key policy is split-plane: the control plane may only generate data keys and the gateway may only decrypt, each under the tenant-scoped context. BYO-CMK (a customer-managed key with a customer-held kill switch) is planned and not live today, and nothing here implies it is. The Security Statement is the conservative anchor and agrees.

2.2 One legal entity, multiple services (AWS hosting + Cognito + SES). AWS hosting, Amazon Cognito, and Amazon SES are all services of the AWS entity but are listed as separate rows because they involve different purposes and different data, so a Customer objecting under §5 may object to one without objecting to all. They are itemized for objection granularity and to match the Privacy Policy.

2.3 Health-check and cron monitoring is AWS-native — NOT a Sub-processor. Liveness and cron-job ("dead-man's-switch") monitoring is performed entirely within AWS, using AWS-native CloudWatch alarms (on a Recovea/DeadMan heartbeat metric each job emits on success) and AWS SNS alerts delivered to Recovea's own operational contact (email/SMS). It runs inside the already-Engaged AWS environment (row 1), and the alert signals are operational metadata only (e.g., "job ran / heartbeat received," timestamps) containing no Customer Data, no Usage Data, no Inference Content, no Provider Keys, and no Ledger. Recovea engages no external uptime, status-page, or cron-monitoring vendor (no Healthchecks.io, Pingdom, Datadog, or equivalent); there is no external monitoring Sub-processor. The public status page at status.recovea.ai is likewise served from Recovea's own AWS environment (S3 behind CloudFront, row 1) and is maintained by a person rather than by any probe or monitoring service, so it adds no Sub-processor and receives no Customer Data.

2.4 No eval / routing Sub-processor today. No eval or routing Sub-processor is Engaged today, and none Processes any Customer Data. Recovea may in future engage additional AWS-native services within us-east-1 to support optimization, verification, benchmarking, or routing capabilities; any such engagement that Processes Customer Data will run the §5 change-notice first and be added to §2 as Engaged only once both contract and live Processing are true.

2.5 No other Sub-processors. Recovea engages no Sub-processors other than those listed above as Engaged. If that changes — including any flip of a Planned item to Engaged — the change-notice and objection process in §5 applies before the new Sub-processor Processes any Customer Data.

2.6 PostHog — honest analytics-scope note (two surfaces, one project). Until 2026-08-05 this row scoped PostHog to the marketing website and stated that it identifies nobody. That described one of the two surfaces PostHog actually runs on, and it is corrected here rather than left to lag the code.

• Marketing website. Anonymous and aggregate. No identifier is assigned to the visitor, nothing is stored on the device, and nobody is named.
• Authenticated dashboard. Identified product analytics. Because the user is signed in, events are keyed to a pseudonymous account identifier, with the workspace identifier and plan tier attached. That identifier is an internal opaque id — it is not an email address, a person's name, a workspace name, or any customer-assigned label, and it is meaningless to anyone without Recovea's own account records.
• Both surfaces stay cookieless. Persistence is in page memory only, so nothing is written to the device on either surface — no cookie, no local storage. Identification lives in the event stream, not on the visitor's machine. This is what keeps the Cookie Policy's §7.2 no-banner conclusion intact, and it is load-bearing: switching the dashboard to device storage would reopen that conclusion.
• Autocapture and session recording are off, everywhere. No DOM text, no input values, no screen recording. Recovea's own analytics library reads only allow-listed data-rcv-* attributes.
• The property contract is closed. Event properties come from a fixed allow-list in Recovea's analytics library — a property outside it is a build error, not a review comment — and a runtime filter drops values matching Recovea keys, Provider keys, bearer tokens, email addresses, and JWTs. No spend figure, cost figure, token count, prompt, or completion is an allowed property.
• Page identifiers. The dashboard page an event occurred on is sent as a named route pattern (/requests/:id), not a resolved URL. The vendor's client library additionally attaches page-URL properties by default; Recovea suppresses these on the authenticated surface at its own library layer, and where that suppression is not in force the only additional field the vendor receives is the resolved dashboard URL — which can carry a record identifier, and never a spend value, prompt or completion content, or a customer-assigned name.
• GPC and DNT are honored on both surfaces, and honored by not initializing the analytics client at all — not by initializing it and staying quiet.

2.7 Sentry — Engaged on 2026-08-05, and what was true at the flip. Row 6 was pre-listed as Planned earlier the same day, before any reporting endpoint existed anywhere, because §14's "new tooling" rule requires the §5 change-notice to run before Processing rather than after. It flipped to Engaged once all five conditions below were satisfied. They are recorded here with the evidence for each, in the form it was checked, so that a reader can test the claim rather than take it:

• (a) Governing terms are in force. The Recovea organization and its browser projects exist under the vendor's published Terms of Service and Data Processing Addendum, accepted at organization creation — a project, and therefore a reporting endpoint, cannot exist without them.
• (b) No session replay, no performance tracing, no IP-address storage. Replay and tracing are off by construction rather than by flag: neither integration is registered in the reporting client and no trace sample rate is set, so there is nothing to sample and nothing to switch off later by accident. IP-address storage is disabled at the vendor ORGANIZATION level — applied to new events across all projects, not project by project — confirmed against the vendor console by Recovea's founder on 2026-08-05, with screenshot evidence retained in Recovea's records. sendDefaultPii is off, so the client attaches no personal data by default.
• (c) Redaction reaches where the secret actually is. Error text is redacted before it leaves the browser for Recovea keys, Provider keys, bearer tokens, email addresses, and JWTs — on the exception message and on stack-frame values, not only on log messages, and redacting the whole matched token rather than its leading characters. The evidence is the pinned version of Recovea's own analytics and error library (@recovea/telemetry ≥ 0.2.3) in both browser applications: an earlier version redacted a match and left the remainder of a key readable, which is why the pin is part of the condition and is enforced by an automated build check rather than by remembering it.
• (d) Browser surfaces only. Error reporting runs in the marketing website and the authenticated dashboard, and nowhere else. No Sentry SDK runs in the gateway or in any other in-path service — by decision, not by omission: the gateway carries Inference Content, and a crash report raised inside it could capture that content in a way no redaction rule should be trusted to catch. This is a standing constraint on row 6, not a description of launch day.
• (e) The §5 change-notice has run. It published with this document's v7 entry on 2026-08-05, ahead of the flip. Recovea had no active Customers at either publication, so the §5.2 window had no addressees; §12 records that position rather than treating a notice that had nobody to reach as a notice that never had to be given.

Row 6 states what Sentry may receive; §4.8 states what it may never receive. The flip widens neither.

3. BYO-Key — the Customer's own LLM Providers are NOT Recovea's Sub-processors

> This is the most important distinction in this document. The BYO-Key design depends on it.

3.1 The Services are BYO-Key: the Customer brings and owns its own upstream LLM Provider accounts, relationships, and API keys — e.g., OpenAI, Anthropic, OpenRouter, and others as the Customer configures. The Customer's inference runs on the Customer's own Provider accounts, and the Customer pays those Providers directly.

3.2 Those upstream LLM Providers are engaged by the Customer, under the Customer's agreements with them. They are the Customer's processors (or independent controllers) and customer-directed recipients — NOT Recovea's Sub-processors. They are therefore not listed in §2. This characterization is structurally load-bearing for the BYO-Key design and the entire Sub-processor / transfer / retention architecture, and it reads identically across the DPA (§1.4), Privacy Policy, Security Statement, AI-Governance, Export, Retention, and byo-key-and-provider-terms.md.

3.3 Recovea acts as a neutral conduit: it proxies the Customer's requests through to the Customer's chosen Provider using the Customer's own Provider Key, decrypts that key in memory only to sign the Customer's own upstream call, never returns the key to the browser or to any non-hosting Sub-processor, strips the Customer's inbound Recovea key (rcv_/rcva_) before the upstream call, and restricts gateway egress to an allowlist (Provider + AWS domains).

3.4 Where Providers offer zero-retention or data-handling options, Recovea passes those options through where available. The Customer is responsible for its own relationship with its Providers — including the Providers' terms of service, the Providers' data handling, and the Customer's own spend caps and usage. Assurances about how OpenAI/Anthropic/OpenRouter handle data come from the Customer's contract with that Provider, not from Recovea. See byo-key-and-provider-terms.md.

3.5 Why this matters for this list. Because the Providers are the Customer's processors, Recovea's change-notice obligation (§5) does not cover the Customer adding or switching its own Providers — that is the Customer's decision under the Customer's own Provider agreements. Conversely, Recovea cannot unilaterally route a Customer's traffic to a Provider the Customer has not configured.

4. What Sub-processors never receive

4.1 No bodies handed to a payment, email, or identity Sub-processor as a body store. Health-check/cron monitoring is AWS-native and receives operational metadata only (§2.3). Inference Content transits the hosting layer (AWS) in-path on the paid tier because that is how the gateway meters and (on the paid tier) applies cache/dedup Levers. Consistent with §1.5: request/response bodies are not persisted as a durable body store by default; bodies are Processed in memory; the only durable body store is the opt-in paid-tier response cache, which stores response content keyed by a request hash for a configurable TTL and then evicts it. Otherwise only Usage Data metadata is persisted. This is stated identically in the Retention Policy.

4.2 Stripe receives billing data only — billing-contact details and invoice amounts. Never Usage Data, Inference Content, Provider Keys, or the Ledger.

4.3 Cognito receives identity data only — account/user email and authentication identifiers. Never traffic data, Inference Content, Provider Keys, or the Ledger.

4.4 The mail-delivery Sub-processor (Amazon SES) receives email data only — account email address and transactional message content/metadata. Never traffic data, Inference Content, Provider Keys, or the Ledger.

4.5 The Ledger stays content-free. The hash-chained, append-only, immutable metering Ledger is content-free by design and is not shared with any Sub-processor as a body store.

4.6 Provider Keys are not exported. Provider Keys are sealed with live AWS KMS envelope encryption (tenant-bound at the KMS context and the AEAD layer) and decrypted in memory only to sign the Customer's own calls. They are never returned to the browser or handed to a non-hosting Sub-processor.

4.7 No training on Customer Data, Service outputs, or the Ledger. No Sub-processor receives Customer Data or Inference Content for the purpose of training any AI model, and Recovea does not use Customer Data, Inference Content, Service outputs, or the Ledger to train any AI model. Recovea may use Aggregated/De-identified Data — content-free usage metrics that identify no Customer or individual, qualifying as "aggregate consumer information" (Cal. Civ. Code §1798.140(b)) and/or "deidentified information" (Cal. Civ. Code §1798.140(m)), meeting GDPR anonymization thresholds, with a no-reidentification commitment — to operate, secure, and improve the Services. See DPA §7 and terms-of-service.md.

4.8 The analytics and error-reporting Sub-processors receive no traffic data. PostHog (row 5) and Sentry (row 6) receive no Inference Content or any prompt/completion text, no Usage Data (metering) records, no spend, cost, or token values, no Provider Keys, and no Ledger data. What PostHog receives is product-interaction facts — which page or feature was reached — keyed on the marketing website to nobody and in the authenticated dashboard to a pseudonymous account identifier (§2.6). What Sentry receives is error events and stack traces, and nothing from any in-path service (§2.7). Neither receives a session recording, because session recording and replay are off on both.

5. Change notice and objection rights (cross-referenced to the DPA)

5.1 General written authorization. The DPA (§6.1) provides the Customer's general written authorization for Recovea to engage Sub-processors, subject to this notice-and-objection process.

5.2 Change notice — 30 days. Recovea will give Customers at least 30 days' prior notice before adding a new Sub-processor or replacing an existing one (including any flip of a Planned item to Engaged), by (a) updating this document and (b) notifying each active Customer at the account/administrative email of record for that Customer. The opt-in subscription list (§5.5) is an additional channel, not the sole one. An emergency carve-out applies: where a replacement is required on shorter notice to maintain security or service continuity, Recovea will give as much notice as practicable. This 30-day period matches the DPA §6.4, the Privacy Policy §7, and refund-cancellation-policy.md verbatim.

5.3 Right to object. A Customer may object, on reasonable, good-faith data-protection grounds, to a new or replacement Sub-processor within the notice period (DPA §6.4–§6.5).

5.4 Objection → bounded exclusive remedy. If the parties cannot resolve a timely, reasonable objection within a commercially reasonable period, the Customer's sole and exclusive remedy is to terminate the portion of the Services that depends on the objected-to Sub-processor (the "affected portion"), effective on or before the date the objected-to Sub-processor would begin Processing. Recovea will refund any prepaid, unused Fees allocable to the affected portion on a pro-rata basis; where the Customer is billed monthly (in arrears or otherwise with little or no prepaid Fee), the remedy is termination of the affected portion without further charge for the terminated portion (so the remedy is not illusory in the absence of a prepaid balance). Because the hosting Sub-processor (AWS, row 1) underpins the entire Service, a timely, reasonable objection to AWS entitles the Customer to terminate the whole Service (with a pro-rata refund of any prepaid, unused Fees). Apart from this remedy, the Customer has no further liability, damages, or remedy. Nothing in this Section limits any right a Customer cannot waive under applicable Data Protection Laws. This bounded remedy is stated consistently across the DPA, Privacy Policy, this document, and the Refund Policy.

5.5 Subscribe to change notices (additional channel). In addition to the email-of-record notice in §5.2, Customers may subscribe to Sub-processor change notices by emailing security@recovea.ai with the subject "Subscribe: subprocessor changes." The canonical domain is recovea.ai. Subscribing is optional and does not affect the §5.2 notice that pushes to every active Customer's email of record.

6. Recovea remains responsible; flow-down terms

6.1 No-less-protective terms. Recovea imposes on each Sub-processor data-protection obligations no less protective than those in the DPA, to the extent applicable to the relevant Processing, in a written agreement.

6.2 Recovea remains responsible for the performance of its Sub-processors' data-protection obligations under the DPA, as if Recovea performed them itself.

6.3 Confidentiality and security. Recovea ensures that persons it authorizes to Process Customer Personal Data are bound by appropriate confidentiality obligations and that Sub-processors maintain technical and organizational measures appropriate to the risk, consistent with the Security Statement.

7. International transfers — dormant at launch (US-only)

7.1 All Recovea-engaged Processing of Inference Content, Usage Data, Account, and authentication data occurs in the United States (us-east-1). Billing-contact data provided to Stripe may be Processed by Stripe on its own (potentially non-US) infrastructure under Stripe's own terms. For US Customers there is no Recovea-engaged cross-border transfer.

7.2 Recovea does not make independent international-transfer representations in this document, the ToS, the MSA, or the Privacy Policy; those documents point to the DPA, where the transfer mechanics live and are dormant at launch.

7.3 Only if Recovea later onboards an EEA/UK/Swiss-established Customer would a transfer mechanism apply — the EU Standard Contractual Clauses (Module 2, controller-to-processor), the UK International Data Transfer Addendum / IDTA, and Swiss amendments, with the Customer as data exporter and Recovea as data importer, plus any required supplementary measures (the billing path via Stripe assessed separately). See DPA §13 and Annex IV, which are kept executable so the first non-US signer is covered. This contingency stays dormant and is activated only on EEA/UK/Swiss onboarding, stated identically in the DPA, Privacy Policy, and here.

8. Billing posture (honesty boundary)

8.1 At launch, Recovea charges only the subscription Fee set out in the applicable Order Form / pricing page (a no-cost, observe-only in-path tier (metered, metadata-only, with no Levers or spend-control enforcement) and paid in-path gateway plans). Pricing is not part of this inventory and is governed by the Order Form / then-current pricing page; this document states no dollar amount.

8.2 Any usage- or savings-contingent charge (including any verified-savings / outcome-based share) is OFF at launch — reserved and not active. If introduced, it is governed by a separate Order Form schedule, applies only on the Customer's separate, affirmative election, and is notified accordingly. No Sub-processor (including Stripe) bills any savings-contingent amount today. This document never asserts a savings, quality, or uptime guarantee; the cache/dedup Levers, where enabled, are labeled "measured/applied," never "verified."

9. Disclaimers; no third-party-beneficiary rights; precedence

9.1 No warranty as to Sub-processors. This inventory is provided for transparency. EXCEPT AS EXPRESSLY STATED IN THE DPA AND THE AGREEMENT, RECOVEA MAKES NO WARRANTY, EXPRESS OR IMPLIED, REGARDING ANY SUB-PROCESSOR'S SERVICES, AND THE SERVICES ARE PROVIDED "AS IS" AND "AS AVAILABLE." Recovea does not warrant the availability, uptime, or output of any Sub-processor or of the Customer's own Providers. Any liability arising in connection with this inventory is subject to the limitations, caps, and exclusions in the Agreement and the DPA (including binding arbitration before the AAA, seated in Wilmington, Delaware, and the limitation-of-liability terms), which control.

9.2 No third-party beneficiaries. This document creates no third-party-beneficiary rights in any Sub-processor or any other person.

9.3 No expansion of commitments. Nothing here expands the Services description, warranties, or commitments in terms-of-service.md, the MSA, the DPA, the Privacy Policy, or the Security Statement. "Planned" is not a commitment to ship on any date.

9.4 Precedence. Where this document and any other Recovea data-protection surface disagree about the Sub-processor inventory facts (identity, purpose, location, engagement status), this §2 list controls. Where they disagree about obligations (the duties Recovea or the Customer owe), the DPA controls. Within the overall contract stack, order of precedence is: a signed Order Form (where it so states) > MSA > DPA (for Processing of personal data) > BYO-Key Addendum (for Provider Key handling) > incorporated policies (including this document) > ToS body.

10. Honest current-state summary (no overclaim)

• AWS (hosting) is Engaged — production environment live in us-east-1 (N. Virginia), United States; sole data-hosting location.
• Amazon Cognito is Engaged as the live identity provider (raw Cognito tokens never exposed to the browser).
• Amazon SES is Engaged — the active transactional email sender.
• Stripe (Stripe, LLC) is Engaged as the live payments processor and never receives traffic data, Inference Content, Provider Keys, or the Ledger; Stripe's own Processing locations are governed by Stripe's terms.
• PostHog is Engaged on TWO surfaces — anonymous, cookieless, aggregate measurement on the marketing website, and identified product analytics inside the authenticated dashboard, keyed to a pseudonymous account identifier with workspace identifier and plan tier. Both surfaces are cookieless (nothing stored on the device), session recording is off, and PostHog receives no spend or cost values, no Inference Content, no Usage Data records, no Provider Keys, and no Ledger data (§2.6). The scope published before 2026-08-05 named only the marketing website and stated that nobody is identified; it described one surface of two, and is corrected.
• Sentry is Engaged since 2026-08-05 — browser error reporting on the marketing website and the authenticated dashboard, and nowhere else: no Sentry SDK runs in the gateway or any in-path service. Session replay and performance tracing are off, IP-address storage is disabled org-wide at the vendor, and error text is redacted before it leaves the browser. It was disclosed as Planned before a reporting endpoint existed rather than after; §2.7 records the five conditions as satisfied at the flip and §12 records the §5 notice.
• Health-check / cron monitoring is AWS-native — CloudWatch Recovea/DeadMan dead-man alarms + SNS alerts to Recovea's own ops contact, all within the Engaged AWS environment. No external uptime/status/cron-monitor is engaged. See §2.3.
• AWS KMS envelope encryption is live (per-tenant encryption context; tenant-bound AEAD; split-plane key policy). BYO-CMK is planned and not live.
• No eval/routing Sub-processor is Engaged today, and none Processes any Customer data; any future AWS-native optimization/verification/routing capability will run the §5 change-notice before Processing (§2.4).
• The Customer's own model Providers (OpenAI/Anthropic/OpenRouter) are NOT Recovea Sub-processors — they are the Customer's own processors / customer-directed recipients under BYO-Key (§3).
• Region is us-east-1 (United States) for all Recovea-engaged Processing (billing-contact data to Stripe excepted; §7.1).
• Body-persistence: bodies are not a durable body store by default; the only durable body store is the opt-in paid-tier response cache (response content keyed by a request hash, configurable TTL, then evicted); otherwise only Usage Data metadata is persisted (§1.5, §4.1).
• This document does not assert SOC 2, ISO 27001, or PCI certification, SSO/SAML/SCIM, HA/multi-AZ, tested DR, additional regions, or any SLA that is not real. (Role-based access control across the five workspace roles is enforced server-side; see the Security Statement §5.) Roadmap capabilities are labeled planned, never represented as live or certified.

11. Relationship to other documents

11.1 This list is incorporated into and governed by the DPA. On a conflict about obligations, the DPA controls; on a conflict about the vendor inventory facts, this §2 list controls (§9.4).

11.2 The convenience summaries in privacy-policy.md §7 and security-statement.md §10 may lag this document; this document controls the inventory facts. Any published website Sub-processors page must be kept consistent with this list (same vendors, same statuses, same region) before it is shared.

11.3 Companion documents: data-processing-agreement.md, privacy-policy.md, security-statement.md, byo-key-and-provider-terms.md, data-retention-and-deletion-policy.md, refund-cancellation-policy.md.

12. Updates and version history

12.1 Material additions or replacements follow the §5 notice-and-objection process before the new Sub-processor Processes Customer Data.

12.2 Recovea maintains this change log each time a row is added, removed, or flips status — it is part of the honesty record and the audit trail for the change-notice commitment.

13. Questions

Email security@recovea.ai (general security / Sub-processor questions) or privacy@recovea.ai (data-protection / Privacy Contact). Formal legal notices may be sent to legal@recovea.ai or to Recovea's registered address at 2810 N Church St STE 89986, Wilmington, DE 19802.

14. Forward-looking considerations

These are not present commitments — they flag horizon items so this inventory and its companions stay honest as the law and the product move:

• Sub-processor diligence up-market. Enterprise buyers may demand tighter diligence, shorter or auditable change-notice mechanics, and self-service subscription to Sub-processor changes. Revisit §5 mechanics accordingly.
• KMS / encryption maturation. AWS KMS envelope encryption moved from planned to live on 2026-07-17 and §2.1 and the Security Statement were updated together. The same rule now governs BYO-CMK: never let any surface imply customer-managed keys are live before they are, and when they ship, update §2.1 and the Security Statement in the same commit.
• Additional AWS-native capabilities. If Recovea later engages any AWS-native service that Processes Inference Content or other Customer Data (e.g., for optimization, verification, benchmarking, or routing), run the §5 change-notice before it Processes any Customer Data and add it here as Engaged only once both contract and live Processing are true.
• New tooling. Any future monitoring, analytics, error-tracking, support, or evaluation tooling that touches Customer data must run the §5 change-notice before Processing, and be added here only once Engaged. Sentry (row 6) is the first vendor to have run this rule end to end — pre-listed as Planned on 2026-08-05 before any reporting endpoint existed, with the conditions for engagement written down in §2.7 in advance, then flipped to Engaged the same day once each condition was satisfied and evidenced. Disclosing before wiring, and writing the conditions down before meeting them, is the pattern to repeat.

> Specific to: Recovea, Inc., a Delaware corporation — in-path AI-spend gateway (BYO-Key); AWS us-east-1 (US) hosting + Cognito (identity) + SES (transactional email); Stripe, LLC (billing); PostHog, Inc. (cookieless analytics — anonymous on the marketing website, identified in the authenticated dashboard); Functional Software, Inc. d/b/a Sentry (browser error reporting on the two web surfaces, Engaged 2026-08-05 — no replay, no tracing, no IP storage, never in-path); AWS-native health-check/cron monitoring (CloudWatch/SNS — no external monitor); no eval/routing Sub-processor engaged; the Customer's own model Providers (OpenAI/Anthropic/OpenRouter) as the Customer's processors, not Recovea Sub-processors. Companions: data-processing-agreement.md, privacy-policy.md, security-statement.md, byo-key-and-provider-terms.md.