AI Disclosure & No-Training Statement

0. Purpose & scope

This document explains, in plain language and grounded in code, how the Arcqtype AI "Coach" works, what data the Coach processes, what "memory" means, and the verified fact that no user conversation is ever used to train or fine-tune the AI model. It is written so that (a) counsel can finalize a user-facing AI disclosure and a public "no-training" statement, and (b) a future engineer can confirm the claims still match the code.

Arcqtype is a youth-athlete platform: many users are minors, and launch posture is 13+. The AI disclosure is therefore minor-facing and intersects with the COPPA / guardian-consent flow and the under-13 backend-path alignment decision. This document is the technical companion to the minors third-party-AI disclosure in legal/coach-chat-legal-signoff-packet.md §3(B) and the provider/subprocessor docs.

0A. 2026-07-29 provider correction

The final user-facing AI disclosure must reflect these locked launch-readiness rulings:

• Coach now uses OpenAI GPT-5-mini through an OpenAI-only provider registry. DeepSeek has no active fallback, shadow, or rollback path. Any DeepSeek detail retained in dated engineering records describes former state only.
• The privacy promise should say "we never sell personal data".
• For minors and linked guardians, high-severity self-harm, suicide, disordered-eating/RED-S, abuse, or comparable crisis signals may trigger crisis resources and automatic guardian notification where legally and operationally permitted, with the athlete told in chat.
• Arcqtype is launching as a 13+ general App Store app, not Kids Category.

---

1. The plain-language statement (engineering draft — counsel to finalize)

How Coach works. Arcqtype's "Coach" is an AI assistant powered by OpenAI GPT-5-mini. When you send a message to Coach, your message — along with relevant context about you that Arcqtype has stored (your profile, training, and prior things you've told Coach) — is sent to OpenAI's API so it can generate a reply. OpenAI returns the reply; Arcqtype shows it to you. We don't train the AI on your conversations. Your messages are used to generate your replies and to power Coach's memory of you *inside Arcqtype* — they are never used to train, fine-tune, or otherwise improve the AI model itself. What "memory" means. Coach can "remember" things you tell it (for example, your preferred name, your equipment, your schedule constraints). That memory is stored in Arcqtype's own database, not in the AI model. It exists so Coach can give you consistent, personalized help. You can see what Coach remembers, and you can flag anything that's wrong. *[For under-18 users: a parent or guardian should review and consent to Coach's use of a third-party AI service. — confirm consent vs. disclosure-only with counsel; see §6.]* *[Data-handling, retention, no-training, and data-residency details for the final provider to be confirmed by counsel and vendor paperwork — see §5 and third-party-subprocessors.md.]*

---

2. How the Coach actually works (grounded)

2.1 It is a third-party API call

The Coach is not an Arcqtype-hosted or Arcqtype-trained model. Coach replies are produced through the OpenAI provider seam — see arcqtype-api/src/providers/openai-coach-client.ts and src/services/chat/model-provider-registry.service.ts.

The active Coach model is OpenAI GPT-5-mini, configured through OPENAI_COACH_MODEL; the provider registry posture is openai-only.

Each request carries its own messages and context. Conversation continuity comes from Arcqtype assembling and re-sending its own stored context (see §3), not from a per-user model session.

2.2 Provider request shaping

The OpenAI provider seam strips former-provider request extras before egress and sends the OpenAI request shape defined by openai-coach-client.ts. Public disclosure must not promise access to or storage of hidden reasoning; only user-visible responses and Arcqtype-side records described below are in scope.

2.3 What gets sent to OpenAI on each turn

The request body contains chat messages plus Arcqtype-assembled athlete context. The exact field inventory must be re-verified against the current context builders before publication.

Open question for counsel (§5): whether and how OpenAI retains, logs, or otherwise processes the payload is a vendor-contract and live-settings question engineering cannot settle from Arcqtype code. Final wording must be verified against the executed OpenAI agreement and deployed settings.

---

3. What "memory" means (grounded) — and why it is NOT training

This is the crux of the no-training statement, so it is spelled out precisely.

"Coach memory" is Arcqtype-side context that we store in our own Supabase/Postgres database and re-inject into each request as part of the prompt. It is *retrieval and prompt-assembly*, not model weight updates. Three storage mechanisms:

3.1 Durable facts — coach_project_memory_items (+ _sources)

Source-backed facts extracted from the athlete's own Coach chat, stored per user. Schema: arcqtype-api/migrations/218_coach_project_memory.sql:22-63. Key properties:

• Closed fact set. Only 10 fact types are allowed (DB CHECK constraint, 218_…sql:40-53; mirrored in project-knowledge.service.ts:7-18): preferred_name, identity_preference, contact_candidate, recruiting_contact_candidate, equipment_access, schedule_constraint, nutrition_preference, exercise_preference, school_interest, personal_context. It is not a free-form transcript dump.
• Source-backed. Each fact links to short (≤240-char) quotes from the athlete's own scoped chat, so the athlete can see *why* Coach believes something.
• Athlete-scoped & private. Sources are constrained to actor_surface = 'athlete' and conversation_visibility_scope = 'athlete_private'. Row-Level Security is enabled and only the backend service role can touch these tables; the app never reads them directly.
• Status lifecycle supports forgetting/redaction. A fact's status can be active, superseded, forgotten, redacted, or low_confidence. Only active facts are read into context.

3.2 Pre-computed context snapshot — coach_context_snapshots

One row per athlete holding pre-assembled context blocks (profile, nutrition, projections, percentiles, a rolling 30-day timeline, commitments, and a permanent safety-critical critical_memory block). Schema: migrations/066_coach_context_snapshots.sql:5-26. It is rebuilt from Arcqtype's own data when relevant events fire. It is a cache of *our* data, not model output stored for training.

3.3 Per-conversation rolling summary — chat_conversations.rolling_summary

A bounded narrative summary of a single conversation, hard-capped at 2,400 characters in code. Refreshed on a cadence, injected on overflow turns. Again: stored in our DB, fed back as prompt context.

3.4 Why this is categorically not "training"

• Arcqtype calls a hosted OpenAI model through an API. There is no fine-tuning job, no training pipeline, and no weight-update code in the backend. "Memory" is read back into the prompt of a later request; it is not a model-weight update.
• Removing or down-statusing a memory fact stops it from being injected into future prompts (only active is read — project-knowledge.service.ts:297). If it were training data, you couldn't "un-train" it by flipping a row; the fact that you can demonstrates it is retrieval, not training.
• Internal investigation wf_1952fda5-9d8 (2026-06-17) reached the same conclusion at code level: the model is never weight-trained on user data; in this codebase "training" refers only to prompt/retrieval/tool/fixture work, not model fine-tuning.

---

4. User visibility & control over memory (grounded — including what is NOT yet shipped)

The disclosure should only promise what the app actually does today. Current shipped state:

4.1 Shipped today

• Inspect. GET /api/coach/memory returns the athlete's own stored Coach writes/memory (id, created_at, tool, status, reason, field, value, conversation/message links) — athlete-scoped, athlete-role-gated. Route: arcqtype-api/src/routes/coach-memory.routes.ts:20-62; mounted at app.ts:377; selection in coach-memory.service.ts:46,59.
• Dispute / flag. POST /api/coach/memory/:id/dispute lets the athlete flag a specific Coach write as wrong, with a 1–500-char reason.
• Account deletion cascades memory. Memory tables are REFERENCES public.users(id) ON DELETE CASCADE, so deleting the user account deletes the durable memory facts and their sources. (Confirm the full account-deletion flow in legal/account-deletion-data-retention.md.)

4.2 Spec'd but NOT yet shipped (do not state as live in the disclosure)

The "How Coach Understands Me" trust feature — a per-fact Forget action and a Reset what Coach knows action — is specified in the active sprint: a planned DELETE /api/coach/memory/:id and POST /api/coach/memory/reset. As of 2026-06-17 those write/erase routes are status: pending and not mounted (the live router exposes only GET / and POST /:id/dispute — coach-memory.routes.ts).

Wording guard for counsel: the schema *supports* forgetting (the forgotten/redacted statuses exist), and inspect + dispute + account-deletion-cascade are live, but a one-tap user-driven "forget this fact" / "reset everything Coach knows" control is not yet user-facing. The disclosure should say the athlete can see what Coach remembers and flag errors today; promise self-service erasure only once T3.2/T3.3 ship, or phrase it as "you can ask us to remove it" / route it through the existing data-rights / deletion mechanism. Open question §6.4.

---

5. Data-handling / residency — open, not assertable from code

• What engineering can assert: chat messages plus assembled athlete context are sent to OpenAI to generate replies. Arcqtype's copies of conversations and memory live in Arcqtype's Supabase/Postgres.
• What engineering CANNOT assert without vendor paperwork/settings: OpenAI's retention, logging, processing location, and provider-side use of API inputs. Arcqtype's lack of a training pipeline is a separate fact from any OpenAI contractual commitment.

---

7. Maintenance / re-verification checklist

Re-verify these before relying on this draft (each is a single code check):

• [ ] Provider registry remains OpenAI-only and active model remains GPT-5-mini.
• [ ] Model id(s) — env.ts:34,41.
• [ ] Former-provider request extras remain stripped before OpenAI egress.
• [ ] No fine-tuning / training pipeline exists in the backend (grep for training/fine-tune over src/ returns only playbook copy, not a training job).
• [ ] Memory tables, closed fact set, RLS, and CASCADE still as described — migrations/218_coach_project_memory.sql, 066_…, 306_….
• [ ] Live memory routes — coach-memory.routes.ts (update §4 the moment DELETE/reset ship).

*Internal references: arcqtype-api/src/providers/openai-coach-client.ts, src/services/chat/model-provider-registry.service.ts, migrations/218_coach_project_memory.sql, migrations/066_coach_context_snapshots.sql, migrations/306_conversation_rolling_summary.sql, src/services/chat/project-knowledge.service.ts, src/services/chat/snapshot-builder.service.ts, src/routes/coach-memory.routes.ts, src/config/env.ts; sprint spec shared-docs/specs/2026-06-17-coach-chat-launch-trust-and-memory-sprint.md; sign-off packet shared-docs/legal/coach-chat-legal-signoff-packet.md; investigation wf_1952fda5-9d8.*