Arcqtype

Legal

Third-Party Subprocessors

Effective: Pending attorney review · Last updated July 29, 2026 (draft) · counsel-review draft

Draft — pending attorney review. This document reflects how Arcqtype is built today but has not yet received final legal sign-off. Wording may change before launch.

Purpose & scope

This document enumerates every external service that receives or processes Arcqtype user data, the categories of data each one receives, and where that data is processed. It is the engineering source-of-truth feed for the subprocessor list that appears in the public Privacy Policy and for any Data Processing Addendum (DPA) we sign with customers/guardians.

Two important framing facts that shape this whole list:

1. Backend is the single data hub. The iOS app never queries the database directly — all app data flows through the Arcqtype backend API. The iOS Supabase SDK is used only for authentication/session management, not for reading or writing app data (confirmed: grep for direct.from. This means most subprocessors receive data *from the backend*, not directly from the device. 2. Arcqtype does not train AI models on user data. Chat messages are sent to OpenAI's API to generate responses. Arcqtype has no model-training or fine-tuning pipeline; final provider-side no-training/retention wording must be verified against the executed OpenAI agreement and live settings.

Open question for counsel — classification: Some entities below are arguably independent controllers rather than processors/subprocessors (notably Apple for Sign in with Apple, and Google for Google Sign-In, each of which sets its own privacy terms with the end user). Counsel should confirm which entities belong on a "subprocessor" list versus a broader "third parties we share data with" disclosure. This draft lists all of them so nothing is missed; the legal classification is a human decision.

2026-07-29 provider correction

The Integrated Launch-Readiness Program locks these changes for counsel review:

---

Subprocessor inventory

1. OpenAI (current Coach runtime + utility AI provider)

Open questions for counsel (OpenAI): - Execute/review DPA and ZDR paperwork, or document the retention posture if ZDR is not approved before launch. - Confirm final public wording for API no-training, retention, residency, and subprocessors. - Confirm whether Coach prompts may include HealthKit-derived or consumer-health data, and what separate consent is required.

2. Former processor: DeepSeek (historical audit record; inactive)

Historical counsel record: assess any disclosure, retention, deletion, or cross-border obligations arising from the period when DeepSeek processed Coach payloads. This is not a current subprocessor approval request.

3. Supabase (database, auth, file/session storage)

Open questions for counsel (Supabase): - Confirm the Supabase project region (data residency). Engineering can read it from the dashboard on request; it is not in source control. - Supabase BAA/DPA status and sub-processors of *its* own (Supabase runs on AWS) — a vendor-contract question. - The backend uses the service-role key, which bypasses Row-Level Security. Access control is enforced in application code, not the database. Counsel should note this when describing technical/organizational measures.

4. RevenueCat (subscription / purchase management)

Open questions for counsel (RevenueCat): - What identifier Arcqtype sends to RevenueCat as the app-user-id, and whether that constitutes sharing a persistent identifier for a minor. - RevenueCat DPA / region terms — vendor-contract question.

5. Apple — Sign in with Apple (SIWA) + HealthKit + APNs + App Store billing

Apple appears in four distinct roles, which counsel may want to disclose separately:

CRITICAL — HealthKit data leaves the device to our own backend (not to Apple). The iOS app reads HealthKit metrics on-device, then syncs a selected snapshot to the Arcqtype backend via POST /api/health/sync. The synced fields are explicitly: sleep_hours, sleep_quality, resting_heart_rate, hrv, active_calories, steps, workout_minutes, plus body metrics including weight via POST /api/health/body-metrics. Backend routes: health.routes.ts, recovery.routes.ts, sleep.routes.ts. This means HealthKit-derived health data is stored in Supabase and may appear in the Coach prompt context sent to OpenAI. Counsel must treat this as health-data sharing with our backend and downstream processors, not purely on-device use. Apple's HealthKit guidelines also restrict using Health data for advertising/data-mining — a compliance check for counsel.

Open questions for counsel (Apple): - Whether HealthKit-derived data is permitted to enter the OpenAI prompt context under Apple's HealthKit terms and applicable health-data law, especially for minors. Engineering can confirm/scope exactly which health fields, if any, reach the prompt builder if counsel needs the answer. - Whether Apple SIWA should be disclosed as an independent controller vs. a subprocessor.

6. Google — Google Sign-In

Open questions for counsel (Google Sign-In): - Independent-controller vs. subprocessor classification. - Whether allowing Google Sign-In for under-13 users raises COPPA/Google account-age issues (Google accounts have their own minimum-age terms).

7. Render (application hosting / compute / logs)

Open questions for counsel (Render): Render DPA status and log-retention period (vendor-contract question). Confirm whether any PII is written to logs beyond identifiers/metadata — engineering can audit log call sites if counsel needs a definitive answer.

8. Resend (transactional email)

Open questions for counsel (Resend): - Sending a minor's first name and the guardian's email/name to Resend as part of the COPPA consent flow should be confirmed as permissible data minimization (it is arguably the minimum necessary to obtain consent, but counsel should bless it). - Sending message-body previews by email — counsel should confirm this is acceptable for any minor-to-minor or trainer-to-minor messaging, and that the unsubscribe/notification-preference link satisfies requirements.

---

Content-discovery / enrichment services (likely NOT user-data subprocessors — flagged for counsel)

These services are used by backend content pipelines, not per-user data flows. Engineering's read is that they receive search queries about sports/regions/events, not user PII — but counsel should confirm the classification.

9. Brave Search API

Open question for counsel: Confirm Brave Search is correctly excluded from the user-data subprocessor list (it receives event-discovery queries, not user records). If any user-specific term ever gets into a query, this changes.

10. Google Places API — configured but not actively used

Open question for counsel: Because the Places key is dormant, it likely does not belong on the live subprocessor list yet. Engineering should remove the unused env var or document its intended use; counsel should be re-notified if it goes live (it would receive location/place queries that may be user-driven).

---

Supporting / infra notes (not separate subprocessors, but relevant)

Pending: Sentry (observability / error tracking)

Open questions for counsel (Sentry): DPA, retention window, subprocessor list, and whether a self-hosted Relay is required before any health-adjacent/minor data can be sent.

---

Summary table (for the public-facing subprocessor list draft)

---

Maintenance rule

Per legal/README.md:17: every legal-relevant product change — including adding/removing a third-party processor — must update this doc in the same unit of work. When a new external service that touches user data is wired in, add a row here and notify counsel before it goes to production. When Google Places is activated, promote it from "dormant" to a full row.