Privacy Policy

1. Who we are

Arcqtype is a youth-athlete training and recruiting platform. It provides an AI "Coach," personalized training and nutrition guidance, an ARQ athletic score, recruiting-pathway tools ("My Path"), and community/leaderboard features for junior-high, high-school, and collegiate athletes.

• Operator: _[legal entity name — the prior HTML used "Arcqtype, Inc."; confirm]_
• App Bundle ID: com.miau.arcqtype
• Privacy contact: _[confirm address — see §13; code uses support@arcqtype.app while the legacy HTML policy used privacy@arcqtype.com. These domains disagree.]_

This Policy explains what we collect, why, who we share it with, how long we keep it, how we treat minors, and your rights.

---

2. Information we collect

2.1 Information you provide (account & profile)

Stored in our database. Grounded in arcqtype-api/migrations/001_initial_schema.sql and 005_athlete_profiles_v2.sql.

• Category — Examples (actual columns) — Source
• Identity — First name, last name, date of birth (required), biological sex, profile photo URL — users
• Account status — is_minor flag, subscription tier, last login — users
• Location & school — School name, city, ZIP, state, search radius — users; school_nces_id, GPA
• Sport profile — Sport(s) (up to 3), positions, desired position, skill/playing level, season status, years in sport, academic grade — athlete_profiles
• Physical baseline — Height, weight, strength baselines (squat/bench/deadlift/pull-ups) — athlete_profiles
• Sport-specific metrics — Flexible per-sport metrics in a JSONB field (e.g., velocity) — athlete_profiles.sport_metrics
• Goals — Primary/secondary goals, sport-specific targets, recruitment goal (D1/D2/D3/NAIA/JUCO/etc.) — athlete_profiles
• Social / recruiting handles — Instagram, Twitter/X, TikTok, Hudl handles; highlight/recruiting video URL — athlete_profiles
• Style of play — Self-described style descriptors + free text — athlete_profiles

2.2 Content you create in the app

• Category — What it is — Source
• Coach chat messages — The messages you send to the AI Coach and its replies, stored as conversation history — chat_messages; conversation tables referenced in migrations 120/153/218
• Workout & training logs — Exercises, sets, reps, weights, completed sessions — workout_logs and related (referenced throughout workout.routes.ts)
• Journal entries — Daily training notes, mood, emotional attachments — journal_entries
• Nutrition / pantry data — Meal plans, grocery/pantry items, water intake — migrations 015, 044, 045, 058
• Uploaded documents / media — Photos, videos, and documents you share with Coach or upload (e.g., stats screenshots, training plans) — athlete-document.routes.ts, storage cleanup in user-storage-cleanup.service.ts
• Community content (UGC) — Crews, challenge participation, leaderboard entries, crew activity — challenges, challenge_participants, crews, crew_members, crew_activity; leaderboard_stats

2.3 Health & wearable data (HealthKit)

With your permission, the iOS app reads health metrics from Apple HealthKit and syncs daily snapshots to our backend. The iOS permission strings are:

• Read: "Arcqtype reads your health data to personalize recovery scoring, training recommendations, and sleep insights."
• Write: "Arcqtype records workout sessions to keep your training log accurate and improve recovery recommendations."

The specific health metrics stored are (all optional — iPhone-only users won't have cardiac data): sleep hours & quality, resting heart rate, heart rate variability (HRV, ms SDNN), active calories, steps, workout minutes, plus a computed recovery score/label. Recovery logs additionally store sleep duration, sleep-quality rating, HRV, resting HR, soreness areas, and completed recovery protocols. The source column records whether a record came from HealthKit or manual entry (Phase 1 is healthkit only).

The app declares HealthKit read and write scopes. Counsel should confirm the disclosure matches the actual HealthKit data types requested in the entitlement and Apple's Privacy Manifest. (See privacy-manifest-notes.md, listed as "needed" in the legal index.)

2.4 Other device permissions requested (iOS)

From Arcqtype/Info.plist:17-24:

• Camera — "capture photos and videos to share with Coach in chat."
• Location (when in use) — "show nearby camps, showcases, and recruiting events."
• Microphone — "voice coaching during workouts."
• Speech recognition — "talk to Coach Arq hands-free during workouts."

The app declares ITSAppUsesNonExemptEncryption = false.

2.5 Authentication & device/technical data

• Sign-in: Sign in with Apple and Google Sign-In. Authentication is brokered through Supabase Auth.
• Server request logs: The backend (hosted on Render) logs API requests for debugging and abuse prevention. _[Retention period — the legacy HTML said "30 days"; engineering could not independently verify a 30-day Render log retention setting. → Open question (§13).]_
• Usage / cost tracking: Internal usage and API-cost counters and a per-user monthly chat quota (5,000 messages — arcqtype-api/CLAUDE.md "Gotchas").

We do not run third-party advertising and engineering found no ad-network or data-broker SDK in the iOS project. This claim is grounded in the absence of such dependencies in project.pbxproj; counsel should still confirm against the final shipping build and Privacy Manifest.

---

3. How we use your information

• Provide the service: assign your Archetype, compute your ARQ score, build personalized training and nutrition plans, power the AI Coach, track workouts, and surface recruiting guidance.
• Recovery & health insights: compute recovery scores and adjust training using HealthKit/recovery data.
• Personalize: surface nearby camps, showcases, and resources using your location and sport.
• Community features: show leaderboards, crews, and challenges you opt into.
• Communicate: account and consent emails (Resend is the email provider — message-email-fallback.service.ts). _[Marketing email opt-in policy to be confirmed by counsel.]_
• Safety & compliance: enforce guardian consent for minors, moderate community content, and meet legal obligations.

---

4. The AI Coach and third-party AI processing

Current-code state (verified 2026-07-29): the AI "Coach" is powered by OpenAI GPT-5-mini through the OpenAI-only provider seam. When you message Coach, your message plus context assembled by the backend is sent to OpenAI to generate a response.

Engineering-verified facts (code-level audit 2026-06-17, ref. workflow wf_1952fda5-9d8; corroborated in shared-docs/legal/coach-chat-legal-signoff-packet.md §4):

• Arcqtype does not use your conversations to train or fine-tune an AI model. Arcqtype has no model-training or fine-tuning pipeline. Provider-side commitments require separate verification against OpenAI's executed agreement and live settings.
• Each athlete's "memory" is stored in our own database (Supabase), is being made user-inspectable and erasable, and is fed back only as context — it is never exported for model training.

Consent gate: Before any third-party-AI-bound Coach endpoint runs, the backend requires durable, un-revoked external-AI consent. If consent is missing or revoked, the request is blocked with EXTERNAL_AI_CONSENT_REQUIRED and the app re-presents the consent modal. You can grant or revoke this consent at any time.

Provider terms — open question for counsel. OpenAI data residency, retention, provider-side training posture, and contractual safeguards must be confirmed against the executed agreement and live settings. Do not publish those claims from engineering inference.

Open question: the legacy HTML claimed "We do not send your name, school, or social handles to our AI provider — only sport-relevant profile data." Engineering has not re-verified that exact field set against the current context builder. Counsel/engineering must confirm the OpenAI prompt-payload inventory before re-asserting it. (See §13.)

Crisis safety disclosure (draft for S4 launch posture): when Coach detects a high-severity self-harm, suicide, disordered-eating/RED-S, abuse, or comparable safety signal, it should refuse to provide harmful coaching, surface appropriate crisis or health resources (including 988/NEDA where applicable), and notify a linked parent/guardian where legally and operationally permitted. The in-chat copy must tell the athlete when guardian notification occurs. _This is a locked launch-readiness posture, not yet a verified live-code claim in this draft._

---

5. Who we disclose data to

Arcqtype intentionally discloses data inside its youth-athlete ecosystem when necessary to provide coaching, training, guardian, school, and recruiting features. Those disclosures are not sales and are not transfers to advertisers or data brokers. The following three-tier boundary is a binding product ruling; counsel must convert it into final public and minor-specific language without broadening it.

5.1 Ecosystem disclosure boundary

• Tier — Data — Permitted recipients and conditions — Prohibited disclosure
• 1 — Identity and recruiting attributes — Name, profile photo, school, sport, positions, grade/class year, performance metrics, ARQ score, and recruiting profile attributes — Authorized coaches, schools, trainers, linked parents/guardians, and recruiters only through the product surfaces and relationship scopes intended for them. Athlete visibility settings govern exposure. Recruiter access for a minor requires guardian co-consent in addition to the athlete's visibility choice. — No recipient may exceed the athlete's visibility/relationship scope. Minor-specific disclosure and co-consent wording are counsel-owned.
• 2 — Derived readiness signal — A precise current readiness/recovery score derived server-side from the athlete's underlying health/training inputs — Authorized coaches and linked trainers may receive the current score. — No readiness history; no raw inputs; no recruiter access. Schools, parents/guardians, or other roles receive this tier only if a separately governed product surface and counsel-approved disclosure authorize it.
• 3 — Raw health evidence — Sleep hours, HRV, resting heart rate, symptoms, injury detail, medical notes, journal text describing what happened, and other source evidence used to derive readiness — Athlete and linked parent/guardian only. — Never disclosed to coaches, schools, trainers, or recruiters.

The Tier-2 score must be derived at the server boundary. A recipient cannot reconstruct or drill into raw Tier-3 evidence from the Tier-2 disclosure. Product code, consent, and visibility enforcement must stay at least as strict as this table.

5.2 Service providers

We also disclose data to service providers required to operate Arcqtype. A standalone subprocessor list is maintained in the legal lane; this table is grounded in the SDKs and provider clients actually present in the code.

• Provider — Purpose — Data involved — Grounding
• Supabase — Database + authentication (Postgres) — Account, profile, training, health, chat, and community data — Backend stack; auth.users
• OpenAI — Current OpenAI-only Coach runtime and utility AI call sites — Coach messages + assembled context; task-specific utility payloads — src/providers/openai-coach-client.ts; src/services/chat/model-provider-registry.service.ts; openai.service.ts
• RevenueCat — Subscription management — App user ID, subscription/purchase events — iOS RevenueCat SDK; webhook
• Apple — Sign in with Apple, HealthKit, App Store payments — Apple ID token, HealthKit data (on-device unless synced), purchase records — iOS auth + HealthKit
• Google — Google Sign-In — Google account identifier / ID token — GoogleSignIn SDK
• Render — Backend API hosting — API request data and server logs — Deploy target
• Resend — Transactional email (consent, account) — Recipient email + message content — message-email-fallback.service.ts; RESEND_API_KEY
• Nuke / NukeUI — On-device image loading/caching (iOS) — Image URLs/data on device — iOS SDK — _client-side library, likely not a data "share"; counsel to classify_
• Lottie — On-device animation rendering (iOS) — None (local animation files) — iOS SDK — _client-side, likely not a subprocessor_

We never sell personal data. We never transfer personal data to advertisers or data brokers. Ecosystem disclosures in §5.1 and service-provider processing in §5.2 are limited operational disclosures, not advertising or data-broker transfers. Confirm this promise against the final shipping build and maintained subprocessor list before publication.

Open question: the legacy HTML asserted "We have data processing agreements with all of them." Engineering cannot verify which DPAs are executed. Counsel to confirm before re-asserting.

---

6. Children's privacy & minors (COPPA)

Arcqtype is designed to serve student-athletes age 13 and older under the 2026-07-09 launch posture. It is not being positioned as an App Store Kids Category app. Date of birth is a required field at account creation, which drives age-based handling.

Publication gate: the current backend still contains an under-13 verified-consent path, while iOS terminally rejects under-13 signups. Counsel/product/engineering must align these before publication so this policy does not promise a path that the app does not offer or omit a path that the backend still accepts.

6.1 Under-13 — hard server-side gate (COPPA)

A user whose effective age is under 13 (or whose date of birth is unknown/null) cannot save a profile without verified guardian consent. This is enforced server-side, not just in the UI:

• checkUnder13Consent computes age from the date of birth and, if under 13, requires a valid, unexpired, non-revoked guardian consent token issued from guardian_consent_tokens. Missing token → the save is blocked with 403 guardian_consent_required.
• Unknown / null date of birth triggers the under-13 gate — engineering treats unknown age as under-13 to avoid a compliance gap.
• A minor cannot bypass the gate by editing their date of birth upward mid-onboarding once a profile is complete; the gate uses the stored date of birth.
• Every successful profile save that touches a minor's data writes a coppa_audit_log row recording the fields touched and the consent token used.

Guardian consent tokens are short-lived (default 24-hour expiry, 052_coppa_consent_tokens.sql:24) and tie a guardian email to the athlete's account. A companion guardian_consents record stores guardian name, email, relationship, and a verification token (default 72-hour expiry, 001:96-116).

6.2 Under-18 (13–17)

Users 13–17 are minors but, per the current code, are not blocked from saving a profile by a server-enforced gate — the only server-enforced COPPA layer is the under-13 token requirement above. A previously existing "post-onboarding under-18 guardian gate" was removed in a prior sprint. The iOS app does route under-18 users through a Guardian Verification screen.

Open question for counsel: the legacy HTML promised a richer under-18 flow ("require a parent or guardian email at account creation and send a notification") and a 7-day auto-deletion if under-13 consent is not received. Engineering verified the 24-hour token expiry and the under-13 hard gate, but did not verify (a) the "7-day then delete" automation, or (b) a guaranteed under-18 guardian-email-at-signup requirement on the backend. Counsel should align the published promises with what the code actually does, or engineering should build the gap. (See §13.)

6.3 Parental / guardian rights

Parents and guardians may request to review their child's data, request deletion, and revoke consent. _[Operational contact + verification process for these requests to be defined by counsel — see §11 and §13.]_

---

7. Your privacy rights

7.1 All users

• Access / portability: You can export your data. The app provides a CSV export endpoint. _[The legacy HTML promised JSON export "via Settings → Export My Data"; engineering verified a CSV export. Counsel/product to reconcile the format claim.]_
• Correction: Update your profile at any time in-app.
• Deletion: Delete your account in-app. See §8.

7.2 Account & data deletion (App Store requirement)

DELETE /api/users/account runs a hybrid deletion:

1. Storage cleanup — uploaded files (photos, videos, documents) are erased first. 2. Database hybrid delete — a server-side function account_delete_hybrid (migration 210) cascades private athlete data, breaks cross-app relationship rows, removes recruiter-visible state, and anonymizes retained audit / safety / payment rows rather than deleting them. 3. Auth user delete — the underlying Supabase Auth user is deleted.

Most personal tables are also wired with ON DELETE CASCADE to the users row (e.g. health_metrics, recovery_logs, athlete_profiles, chat_messages), so deleting the account removes the dependent rows.

Note: certain audit, safety, and payment rows are anonymized and retained rather than fully deleted. The retention basis/period for those buckets must be stated by counsel (see §9 and §13).

7.3 California (CCPA/CPRA), EEA/UK (GDPR), and other jurisdictions

_[Counsel to finalize jurisdiction-specific rights, legal bases for processing, the distinction between statutory "sharing" and the product disclosures in §5, "right to opt out of sale/sharing," and the complaint/appeal process. The legacy HTML's CCPA/GDPR sections are a starting structure only and must be re-validated against current data flows.]_

---

8. Data retention

• Data type — Retention (engineering-verifiable)
• Active account & profile data — Kept for the life of the account
• Account deletion — private data — Cascaded/deleted on DELETE /api/users/account (§7.2)
• Account deletion — audit/safety/payment — Anonymized and retained (migration 210) — _[period: counsel to state]_
• Uploaded files (photos/videos/docs) — Erased during account deletion storage cleanup
• COPPA audit log — Retained as a compliance record — _[period: counsel to state]_
• Guardian consent tokens — Short-lived (24h expiry); consent records retained _[period: counsel]_
• Server / API request logs (Render) — _[period not verified in code — Open question §13]_

Engineering could not verify the specific retention windows the legacy HTML stated (e.g., "API logs 30 days," "crash/analytics 90 days," "parental consent 3 years"). Counsel should set these against actual infrastructure configuration, not the prior text.

---

9. Data security

• Data is transmitted over HTTPS/TLS.
• iOS auth tokens are handled by the platform auth flow (Supabase PKCE; Apple user ID cached in the iOS Keychain — Arcqtype/CLAUDE.md "Auth Flow").
• API endpoints require authentication on every user-data request.
• Some tables enforce row-level security for direct authenticated access (e.g. recovery_logs, 031), but the backend uses the Supabase service-role key, which bypasses RLS — primary access control is enforced in the API/service layer, not RLS.

Open question: the prior HTML stated "encrypted at rest (AES-256 via Supabase)" and that "even database administrators cannot bypass RLS." The second claim is inaccurate given the service-role pattern. Counsel should describe encryption and access control in a way that matches the architecture. (See §13.)

No system is perfectly secure. Report vulnerabilities to _[security contact — confirm address]_.

---

10. Community / user-generated content

Arcqtype includes social features — crews, challenges, and leaderboards. Content and stats you post may be visible to other users per your participation. We provide moderation tools: you can report content, block and unblock users, and admins can issue takedowns. A full UGC/community moderation policy is maintained separately.

Leaderboard visibility is privacy-filtered server-side.

---

11. How to contact us / exercise rights

• Privacy / data requests: _[confirm address — code uses support@arcqtype.app; legacy HTML used privacy@arcqtype.com. Pick one and make it real. Open question §13.]_
• Minor account requests: _[dedicated channel/subject line — counsel to define]_
• Security issues: _[confirm address]_
• Response time: _[counsel to commit]_

---

12. Changes to this Policy

We may update this Policy. For material changes we will update the "Last updated" date and provide in-app notice; for changes affecting minors' data we will re-obtain guardian consent where required. _[Counsel to finalize notice mechanism and the "continued use = acceptance" language.]_

---