Privacy Policy

Business phone messages, calls and usage billing · sensitive · optional

• Business-owned phone numbers, country, capabilities, encrypted provider credentials, sender readiness, selected agents and activation settings
• Separate saved voice drafts and published configuration; optional AI-generated call summaries, selected internal staff email recipients, matched-contact notes, workflow enrollment and action outcomes
• Browser voice practice sends bounded microphone turns and up to three prior turns from tab memory to OpenAI; generated reply audio and text return to the browser. Durable test records contain request identity, status, frozen pricing and usage receipts, not practice audio or reply text
• Incoming and outgoing SMS bodies, correspondent numbers, explicitly linked CRM contacts, delivery receipts, send request identifiers, consent evidence, recipient time zones, opt-outs and human handoff status
• AI phone-call audio streamed between the caller, Twilio and OpenAI Realtime Mini; public business instructions, approved per-agent knowledge selections and bounded document excerpts, temporary tool exchanges, call direction, status, duration, provider identifiers and usage metadata
• Separate call consent evidence, withdrawal and suppression records; content-free callback deduplication and worker leases
• Signed sender-registration event identifiers, business subaccount, Messaging Service, campaign, brand and number mappings, provider timestamps, readiness state and payload hashes; raw registration event payloads and provider error text are not retained
• Encrypted owner-provided sender registration drafts: legal business name and type, country and operating region, business registration identifier, business address and website, authorized representative name, role, email and phone, mobile verification contact, sample messages and consent-flow URLs
• Registration authority and fee acceptance, immutable reviewed fee versions, provider profile and brand identifiers, durable submission steps and authoritative charge reconciliation receipts
• Dedicated phone Stripe account, test/live mode, deployment environment, payer and customer mappings, immutable billing-context fingerprints and attempted customer-creation identifiers
• Billing addresses collected and updated by Stripe for automatic phone tax; tax classification, base amounts, calculated tax and gross paid receipts used for funding and refund verification
• Phone rental quotes, confirmed Stripe checkout and refund references, prepaid credit, usage reservations, provider resource charges and OpenAI token-usage calculations with a frozen rate version; content-free per-response admission and attempt identifiers, reviewed response capacity, usage receipts, independently funded transfer destinations and combined settlement evidence

Controller: the Coach (we process on their behalf) · Sources: Authorized business staff, saved CRM contacts and people calling or texting the business; The business owner during explicit sender registration; Twilio, OpenAI and Stripe service receipts

Manually recorded internal product feedback · sensitive · optional

• Product association, reviewer display name, rating, feedback text, creation and edit dates, revision numbers

Controller: the Coach (we process on their behalf) · Sources: Authorized coach or team member manual entry, without purchase or identity verification

Mobile app update availability

• Installed application identifier, native version and build number; App Store account country; public store versions and check times
• Google Play update checks process device metadata, installed app version, and app modules and asset information under Google Play terms
• A reminder dismissal key and time stored on the device

Controller: LaunchSite OS · Sources: The installed native app and App Store account storefront; Public Apple listings and Google Play update availability

Network membership, learning paths and imports · sensitive · optional

• Coach-owned shelf folder names, optional descriptions and listing placement. Descriptions can contain sensitive coaching text. Members see folder metadata only through published listings already visible to them; placement never grants access
• Invited member onboarding name, email, selected Network, verified invitation identity and Terms acceptance version/time; membership-only account origin and default-disabled coaching and optional AI settings
• Coach-selected course order, dated cohort names and member assignments; invitation onboarding, historical signup requests, join/leave and learning activity used for aggregate Network reports
• Coach-published General and specialized knowledge categories, client and group assignments, document exclusions, lesson links, source revisions and course access status
• Owner-enabled course transcripts, caption text, timestamps and private derived audio
• Uploaded CSV email invitations and PDF, DOCX, text or Markdown course material, reviewed column mappings and signed draft confirmations

Controller: the Coach (we process on their behalf) · Sources: The invited member during email-verified invitation onboarding; The owning coach during explicit import and curriculum review; Recorded member joins, departures, lesson activity and settled payments

Optional AI network setup · sensitive · optional

• Coach-authored network briefs, selected document text and image observations, filenames, generated branding and private course lesson drafts
• Signed draft confirmations and content-free generation and execution receipts

Controller: the Coach (we process on their behalf) · Sources: Explicit coach descriptions and selected PDF, Word, text, CSV and image files; AI-generated drafts edited and confirmed by the coach

Platform support messages and engineering review · sensitive · optional

• Bounded support task briefs and canonical case/source links transferred to the operator's local T3 coding thread; pending launch state, source and brief revisions, claim identifiers, timestamps, and returned thread/run identifiers
• Bounded uncertainty and severity routing codes, suggested related request/PR/commit references, source-grounded reply drafts and guide references, fixed decline reasons, and content-free daily quiet counts including a coach subset
• Coach-reviewed module access or branded-app setup requests submitted through the existing support form
• Platform inbox and support-chat text, bug descriptions, page paths and an owned AI run reference
• Private platform-conversation photos and document attachments, including downloadable HTML guides, filenames, file sizes and types
• Server-derived requester role, governing plan and add-ons, managed-app availability, normalized page, known platform/build, predicted product guide and confidence, and content-free classification and owner-decision ledgers with exact source references and one-way replay equality hashes
• Opaque whole-request action bindings, exact-tap idempotency receipts containing a body hash, Late Info choices with exact event references, and explicit operator answer or assumption instructions
• Report receipts, AI classification labels with their confidence, classifier version and content-free usage, proposed task briefs and engineering plans, revision-bound planning and implementation approvals, administrator decisions, worker session handles and pull-request references
• Administrator Discord commands, bounded thread context, internal AI replies and explicit customer-reply receipts
• Operator-enabled fixed-text fix-live notices, sent once as the enabling administrator to the platform inbox or support chat conversation of a request whose own T3 Task pull request reached production, with a content-free receipt naming the request, conversation, message, pull request and release commit
• Daily release train lists of T3 Task pull request numbers, dev merge commits and dates, handed to the operator's local T3 thread to prepare a production release that ships only after the owner approves it there
• Decision cards in a private administrator Discord channel (request titles, one plan or task sentence, acceptance results, change size, and links to the request and its pull request), their Discord message identifiers, decision bindings and delivery receipts, and the short line naming who made each decision
• Opt-in community-channel message text, Discord author/channel/message identifiers, timestamps, reply links, edit fingerprints, attachment descriptors, transient screenshot bytes, derived visual observations and content-free usage
• Historical model-derived request titles and message groupings from the retired private-card planning action, with its content-free usage
• Historical screenshots attached to the Discord source messages of a community case or requester messages in its private platform inbox, previously downloaded for authorized engineering sessions
• Historical session records retained after retirement of the self-hosted Cezar support worker: each engineering session's task as the session received it (bounded support text, screenshot observations, task brief, plan and administrator instructions), its recorded activity, screenshots a Claude Code session opened and its code change
• Historical support-worker account labels, enabled state and priority, usage percentages and reset times, sign-in outcomes and administrator audit receipts
• Support pipeline health codes, waiting counts and timestamps, administrator pause reasons and reminders, and a private pinned operational status with environment, worker state and lane states

Controller: LaunchSite OS · Sources: Coaches, clients and platform support administrators; Members of operator-selected Discord community channels, including people without a LaunchSite account; Configured Azure vision observations, bounded Azure intake summaries, optional Azure example-based classification, Jev classification, plus historical Codex and Claude Code sessions from the retired support worker; Operator-enabled local T3 tasks using the configured Codex or Claude Code account

Managed app fulfillment status and operator planning · optional

• Opaque purchase, intake and provisioning references, app keys, payment eligibility, requirement codes and recorded build or review status
• Whether the required artwork, app records and saved credential references exist, without the artwork, credentials or business documents themselves
• Authenticated administrator console paths, source pull-request and workflow links, deterministic change receipts and internal fulfillment plans

Controller: LaunchSite OS · Sources: Existing managed-app purchase, intake, provisioning and release records; Operator-enabled OpenRig case tracking, Codex planning and Claude Code advice

Optional WordPress hosting and Shopify catalog connections · optional

• Website name, migration source address, administrator username and email, hosting status and an encrypted setup password
• Shopify shop address, display name, encrypted catalog access token and authorization state; product titles, publication status and public product links fetched on request

Controller: the Coach (we process on their behalf) · Sources: Coach-entered hosting settings; Shopify after store-owner authorization

Coach-controlled hosted WordPress content · sensitive · optional

• Website files, media, plugins and database content, including visitor or client information the coach chooses to collect through the hosted website

Controller: the Coach (we process on their behalf) · Sources: Coach imports and edits in WordPress; Visitors using the coach-selected WordPress forms and plugins

Optional Fullscript plans, resources and practice connection · sensitive · optional

• Encrypted practitioner access and refresh credentials, verified practice identifiers, granted permissions and explicit client-to-patient matches
• Patient names and email addresses used for coach-confirmed matching; released supplement directions, patient-facing messages, assigned resource references, eligible lab recommendation instructions and permitted order history
• Practice display settings, selected product collections, client overrides, synchronization metadata, coach-confirmed daily checklist mappings with stable row-to-recommendation identifiers and patient-creation request hashes and opaque identifiers

Controller: the Coach (we process on their behalf) · Sources: Fullscript after the coach authorizes the connection and explicitly matches a patient; Coach-selected presentation controls, reviewed patient-creation name/email and manually confirmed checklist timing; client-entered completion records

Private client workspace and optional AI · sensitive · optional

• Personal plans and reusable template revisions, assistant conversations, reviewed setup preferences and confirmed memories with provenance, confirmation times and optional expiry
• Private Zyx Markdown files and their versions, file purposes, conversation titles, source references, reviewed action proposals and outcomes
• Client-written Zyx skills: a name, a when-to-use line, Markdown steps, an on or off setting and version
• PROACTIVE_PREFERENCES.md: what the client wants Zyx to bring up without asking, what never to bring up, and the hours messages may arrive
• AGENTS.md working notes the client confirmed, and TOOLS.md notes beside a live list of connected apps and devices (names, connection state and last sync date, never readings)
• HEARTBEAT.md: recurring checks the client wrote, the notes Zyx sends when a check finds something, and run receipts (local date, slot, result, check count, the note sent and push outcome)
• Private Zyx chat photos, three still frames sampled from a short uploaded video, temporary microphone audio and its transcript, image dimensions and message references; client-uploaded lab reports, extracted values, client verification and educational explanations
• Timezone, brief preferences, consented calendar event details, daily brief cache and delivery status, optional weekly-review consent, saved summaries and bounded source activity snapshots
• Private companion photo thumbnail, optional emoji reactions, reviewed name proposals, automatic-memory opt-in and exact client message quotes; versioned weekly memory housekeeping
• Companion name, preset avatar, tone and written preferences; private uploaded or imported document originals, extracted text, access-scoped semantic embeddings, processing status and revisions
• Knowledge source IDs and revisions linked to saved answers and plans; signed plan activation before/after snapshots and history
• Selected snapshots explicitly shared with the current coach

Controller: LaunchSite OS · Sources: The client, their own saved activity, and their connected Google Calendar when separately permitted; Currently authorized coach knowledge and course lessons, the LaunchSite general coaching library and selected public reference material

Public research for coaching briefs · optional

• General health-topic search terms selected from a fixed list
• Public article addresses, titles and article text used to assess related published cases

Controller: the Coach (we process on their behalf) · Sources: Public research articles selected by Scientist through search results

Public reference research for the client companion · optional

• General coaching topic labels from a fixed list
• Allowlisted public page addresses, titles, bounded text and cited references

Controller: LaunchSite OS · Sources: Public reference pages found after the applicable general coaching library is insufficient

Connected mailbox correspondence · sensitive · optional

• Google/Outlook account identifiers and connection status
• Mailbox message lists, subjects and plain-text email threads, which may include health information supplied by the sender
• Coach-authored replies, provider drafts, content fingerprints, send-operation outcomes, encrypted authorization grants and read/star/archive state
• Provider message/thread identifiers and authentication, reply-matching and processing results

Controller: the Coach (we process on their behalf) · Sources: A mailbox its owner authorizes directly through Google or Microsoft; People corresponding with that mailbox

Historical chart tables and saved charts · sensitive · optional

• Selected numeric columns, dates, categories, original text, and units from a coach-reviewed CSV
• Historical chart snapshots of selected coaching data with source references

Controller: the Coach (we process on their behalf) · Sources: Previously uploaded and reviewed by the coach for a selected client; Previously generated from authorised coaching records

Optional public AI demonstration · optional

• A visitor’s short fictional meal-planning prompt and generated example
• An opaque network rate-limit key, attempt count and window time

Controller: LaunchSite OS · Sources: An adult visitor who confirms they want to use the public demonstration

Shared barcode food database and food photos · optional

• Food details a client types (or has read from a label photo) for a packaged product nobody has added yet: its barcode, name, brand, serving size and nutrition values, saved in a food database shared by every user of the platform, with no link to the account that added it
• A report that a scanned product’s data is wrong: the barcode, the reason chosen, an optional note of up to 500 characters and the reporting account
• A photo a client chooses to scan for food logging, either a meal or a nutrition label, sent to the disclosed AI provider to read the foods or the label
• Barcodes we asked Open Food Facts about and it did not know, remembered for 24 hours; and, in operational logs, the barcode, outcome and timing of each scan with no account identifier

Controller: LaunchSite OS · Sources: The client, when they add a product, report one, or scan a photo; Public reference datasets: USDA FoodData Central (public domain) and Open Food Facts (Open Database License)

Privacy requests, permissions, and review records · sensitive

• Account identifiers, request and review type, jurisdiction, assigned staff, due dates, evidence references and outcomes
• Purpose-specific permission statements and versions, recorded actions, receipt times and withdrawal events
• Coach-provided evidence provenance and asserted historical dates, labelled separately from in-app client confirmations

Controller: LaunchSite OS · Sources: The client, coach, authorized platform staff, and authenticated requests

Account erasure work and completion evidence · sensitive

• Account and subject identifiers, exact private object references, provider references, deletion states, retry attempts and completion or retention evidence
• Minimal deletion tombstones used to prevent restored backups from reactivating erased accounts

Controller: LaunchSite OS · Sources: Authorized deletion requests and the records and storage references held by the service

Coach-client agreement drafts and signed evidence · sensitive · optional

• Optional document email preferences and templates frozen on new agreements, first authenticated web-view time, queued email recipients and content, provider acceptance identifiers and attempt states
• Revisioned document expiry and allowed signature settings; sent expiry deadlines, frozen policy and reported capture methods, included in new signing evidence
• Optional coach-declared document amount and currency, retained through draft recovery and copying and frozen into sent wording and signature evidence; this does not request or authorize payment
• Private saved agreement draft titles and wording, revision numbers and CRM archive state, separate from editor autosave recovery
• The signed agreement text and resolved fields, signer identifiers, signature, signing time, content hash, amendments and void events
• The coach contracting entity (legal name, registration and tax numbers, address) as it stood when the agreement was sent, frozen into the same content hash
• Legacy signed rows captured at migration time, explicitly distinguished from a document recorded at the original signing

Controller: the Coach (we process on their behalf) · Sources: The coach and client during agreement preparation and signing; Existing signed records captured with their known limitations

Coach agreement acceptance records

• Authenticated account ID and email, typed signer name and title
• Full accepted document versions, acceptance statement, document hashes, server timestamp, IP address and browser user agent
• Historical wellness-attestation hashes and timestamps where full documents were not originally recorded

Controller: LaunchSite OS · Sources: Directly from the coach when accepting platform agreements; Automatically from the authenticated request and published platform documents

Coaching template creation and editing attribution

• Creator and latest content editor account identifiers, display-name snapshots and action dates on reusable training, meal-plan, supplement, habit, form (including intake, offboarding and assessment), instruction, protocol and agreement templates

Controller: the Coach (we process on their behalf) · Sources: Authenticated template saves, authorized teammate edits and confirmed AI saves

Gym staff record access scope

• Workspace and staff account references, an owner-applied assigned-record or site-record restriction, and the owner account that last applied it

Controller: the Coach (we process on their behalf) · Sources: Explicit staff role presets applied by the current gym owner

Gym site coaching template publications · optional

• Reusable workout or program references, publishing account, authorized gym site and publication date
• Explicit site publisher permissions recorded by the organization owner

Controller: the Coach (we process on their behalf) · Sources: Owner-assigned permissions and explicit publication actions by authorized coaching staff, including confirmed AI proposals

Gym staff revenue attribution reviews · optional

• Posted ledger line and account references, site, reviewed amount, staff allocations in cents, owner reviewer, reason, timestamp and revision

Controller: the Coach (we process on their behalf) · Sources: Explicit reviews by the current gym owner against existing posted revenue

Gym member menu preferences · optional

• Optional member tools hidden by the gym owner, the saved version, editor account and change date

Controller: the Coach (we process on their behalf) · Sources: Explicit settings saves by the current gym owner, including confirmed AI proposals

Gym membership import source and reconciliation records · optional

• Member and agreement identifiers, source system, original source record ID, import filename, verified importing account and time, and immutable agreement identity and content fingerprints

Controller: the Coach (we process on their behalf) · Sources: CSV rows mapped and reviewed by the authorized gym owner; Server-confirmed agreement saves and authenticated importer identity

Gym historical migration and opening balances · sensitive · optional

• Vendor person and record IDs mapped to existing contacts and members, original service dates and trainer references, historical payments and currency, recorded monetary balances and remaining sessions
• Historical visits, training, notes and communications, and original waiver text, signer, signing date and evidence reference
• Source filename, content hash, import control totals, review notes and importing, reviewing and activating account identifiers and times

Controller: the Coach (we process on their behalf) · Sources: Legacy CSV exports explicitly mapped and reviewed by the current gym owner

Gym provider consent and connection provenance · optional

• Retained gym workspace, current authorizing owner, provider kind and account reference, fresh authorization receipt, consent time, and single-use hosted connection intent with expiry and use time

Controller: the Coach (we process on their behalf) · Sources: Authenticated provider consent callbacks and verified hosted connection callbacks

Gym Google Calendar authorization and event provenance · optional

• Current gym owner, personal credential owner, fresh OAuth connection receipt, primary calendar identifier, review version and date, and calendar-event connection references

Controller: the Coach (we process on their behalf) · Sources: Authenticated Google consent callback, provider-confirmed primary calendar access and explicit current-owner authorization

Gym class bookings, service credit eligibility and waitlist notifications · optional

• Member and gym identifiers, class time and location, booking status, queue position and held-entry reason (inactive membership, unavailable credit or overlapping booking)
• Credit charge/refund ledger references, the actual staff actor and class attendance audit, and a private in-app promotion notice with delivery or superseded status

Controller: the Coach (we process on their behalf) · Sources: Authorized member or staff bookings and cancellations; Owner-configured fixed pass eligibility for named class types and locations, and separate allowed member booking locations; Server-verified class capacity, member status, credit eligibility and scheduling conflicts; Authorized staff standing preferences and gym-owner authored class board drafts explicitly published to eligible members

Shared gym operational notes, tasks and class boards · optional

• Contact-keyed lead and member notes, references to existing authorized client messages, operational tags, mentioned or assigned staff, task due dates and status, authenticated author and task-change audit events
• Generic private in-app notices with a link to an authorized member thread and read status
• Separate class board draft text, publication state, version and publishing actor

Controller: the Coach (we process on their behalf) · Sources: Notes, tasks, replies and shared class instructions entered by authorized gym personnel, including explicitly confirmed AI proposals

Account and profile information

• CRM availability schedule settings: coach-entered name, timezone, weekly working windows and date-specific hours or closures. Creation retry records separately hold the owning account and request identifiers, a normalized-payload hash, target schedule identifier, status, fixed rejection code and timestamps. This server retry record stores no schedule name or hours snapshot; the hash is pseudonymous retry metadata, not anonymous data
• Pending CRM schedule creation in browser session storage: the full normalized name, timezone, weekly windows, date-specific hours, expected default identifier and request identifier. The storage namespace is opaque and derived from the authenticated actor and owning workspace, independent of the current default schedule. The server verifies current access again; the namespace is not an authorization credential. Reopening checks a receipt without automatically submitting another creation
• Owner-created CRM business profiles: business name, creator and plan-owner identifiers, reserved workspace principal identifier, actor-bound creation request identifier, provisioning status, and owner-membership status and timestamps. These records keep business CRM data and connections separate from personal coaching records
• Browser-tab recovery copies of unsaved website/funnel setup, website names, native page canvas content and funnel journey labels, configuration and settings. Session storage is keyed by authenticated actor, workspace and editor; copies are not sent to the server by recovery. Copies older than 24 hours are refused and removed when their editor next opens, and matching copies are removed after confirmed save or explicit discard. Browser session restoration can retain session storage, so expiry is checked on read rather than promising deletion exactly at 24 hours. These drafts may contain coach-entered sensitive text; recovery does not publish or grant access.
• Workspace-owned website and funnel directory folders: names, update timestamps, resource membership links and conflict-detection revisions. Folder removal deletes organization links but preserves websites and funnels. Resource deletion removes its membership; workspace user deletion removes its folder organization. These folders do not grant access or publish content.
• Actor- and workspace-scoped website/funnel template Favorites: static kit identifiers, saved favorite state, revision and update time. Removing a favorite retains a false state and revision for conflict detection; these preference rows are removed when the referenced actor or workspace user record is deleted. These are separate from shared template publications and do not create a site or send messages
• For managed gyms: the member home location used to limit staff access, the organization owning the member book, and audited owner changes. A separate assigned coach does not determine organization ownership or broaden visibility
• Name, email address, and password (stored only as a salted hash)
• New coaching-team and employee invitations use single-use, expiring Auth setup links delivered through transactional email instead of a shared password. Link tokens stay in transient server memory and the recipient email; application records and telemetry do not store their plaintext values. An unused invitation may receive a replacement link. Established account passwords are unchanged
• Browser authentication persists in HttpOnly cookies. The browser keeps a short-lived access token in memory for authorized data and realtime requests; refresh credentials are not retained in localStorage or sessionStorage. Embedded browser previews keep their borrowed or minted sessions in memory. Installed apps retain their secure device credential storage
• Platform administrator authenticator enrollment and verification records held by Supabase Auth, session assurance, and recovery holds with opaque incident references. Setup keys and one-time codes are used for authentication and are not retained in application logs or analytics
• Retired platform-administrator Discord link for support approvals and replies: linked Discord account and server identifiers, administrator/session/authenticator identifiers, whether the link covered approvals, link time and expiry. Discord carries no support actions since October 18, 2026 (support is decided in LaunchSite), so no new link can be made and nothing checks an existing one. Existing link records remain until linked session or authenticator deletion, admin removal or a password change deletes them; expired metadata may remain until then. Content-free link/revocation audit records follow the existing security audit retention. The link contained no message text or authenticator secret
• Coach-created client invitation records: hashed single-use token, linked account and coach, email snapshot, expiry, and access/revocation status. New links expire after 48 hours; previously issued links retain their original expiry. Invitation records remain until the associated account is deleted. When temporary-password enforcement is enabled, generated credentials for newly created clients expire after 48 hours and require a client-chosen password before app data access. Existing client passwords are not backfilled or enrolled by resends. A private credential record holds the issue/expiry time, setup capability, operation claim and password-change receipt. Its initial-password hash and comparison fingerprint are cleared at completion; remaining metadata is deleted with the auth account. The fingerprint is removed from auth metadata before a token is issued. The complete invite message contains the email and newly generated password in transient coach-browser memory for manual copying to the client. Plaintext credentials are not saved in application storage or telemetry. The coach chooses the delivery conversation; LaunchSite does not send an SMS or WhatsApp message. Opening and accepting the invitation does not reset the password. A separate service-only intake requirement retains the client/account/coach association, current intake ID, issue time and completion time to enforce intake before web, native, database and protected file access. It survives pending form deletion, follows the current coaching relationship and is deleted with the associated client or user account. It stores no additional answers, credentials or video viewing data
• Optional profile pictures uploaded by a user or their coach
• Optional illustrated profile avatar choices, including chosen face style, skin tone, hair, facial features, makeup, glasses, sunglasses, headwear, jewelry, clothing and background colors; choices are encoded in the saved avatar image address and can be changed or replaced with a photo
• Coach practice name, brand, logo, and business profile including the postal address used in marketing footers and any separate contracting entity named on client agreements
• Coach-authored Networks portal name, logo, landing banner, welcome copy, and color settings; shared with the coach and their clients separately from individual community artwork
• For clients: phone number, date of birth and gender, entered by the client or their coach, and a preferred language and optional postal address (street, city, state or province, postal code and country) that their coach can record on the client profile
• Team membership and role (coach, team member, client)
• Measurement and workout unit preferences, with unit setup completion status and time
• Team resource visibility, new coach starter-kit selections, organization-managed practice asset settings, and records of resources copied during onboarding
• An unfinished coach invitation draft saved in the inviting coach’s browser: selected resource identifiers, recipient email, intended team role, workflow step, account/team scope, and last edit time. Resource contents and setting values are not stored in this draft
• Coach-saved workspace shortcut names and internal page addresses, private to that coach and retained until unpinned or the account record is deleted
• Coach-saved prospect audience, location scope and qualification preferences used for recurring Lead Scout searches, editable in the bot settings
• Images a coach uploads as a Launch Bot avatar, held in private storage and shown only inside that coach’s own workspace
• Optional public Fullscript storefront address and whether to show it to the coach’s clients; removing the storefront deletes its configuration row, and deleting the coach account cascades to that row. Backups follow the existing account retention policy

Controller: LaunchSite OS · Sources: Directly from you at signup; Profile pictures uploaded by you or your coach; Person-character appearance options selected by you or your authorized coach. Retired generated astronaut selections are cleared from account profiles and cannot be saved again; appearance is not inferred from health records or photos; From the coach or team owner who invited you; Entered by a coach on their client’s profile; Reusable coaching resources and recommended settings selected by an authorized team administrator for new coach onboarding; From a system the coach connected to their own workspace with a Partner API key; Written by a coach about themselves when they choose to appear in the coach directory

Client wellness and health-related records · sensitive

• Check-ins, symptoms, complaints, and wellness system-status grades
• Weight, body composition, blood glucose, temperature, daily water intake, and similar self-reported measures
• Supplement, peptide, nutrition, and training programming, including daily macro targets and optional per-meal allocations, ranges, timing and coaching notes
• On-device workout start time, pause state, elapsed duration, rest/set timer deadline, workout session identifier and optional exercise labels shared with the iOS timer extension. Lock-screen Live Activities and user-added home-screen widgets display workout duration, timer kind and remaining time, never exercise names or workout notes
• Client-pinned workout set notes saved as personal reminders for the same exercise and training template across devices
• Private food, meal and recipe favorites, catalog recipe copies, client-created food labels, and client-created meals and recipes with their ingredients, serving counts, any notes the client writes and the calories and macros calculated from them, saved for reuse in meal diaries across devices within the coaching workspace
• Coach-uploaded educational resources and course lessons, including any client wellness information included in a video, PDF, office document, text file, native slide text and images, or saved HTML/CSS presentation with a text-only PDF fallback
• Course quiz answers and attempts, assignment text and learner-supplied HTTPS links, assessment revision and passing score, instructor grades and feedback, and completion certificate records. These may contain wellness information if a learner or coach includes it; the platform does not fetch assignment links or treat certificates as accredited qualifications
• Menstrual or reproductive information, where a client chooses to provide it as intake
• Coach-defined intake follow-up rules and answers to visible questions. Changing an answer clears hidden follow-up answers and file references before submission; files already uploaded remain in private storage under the existing retention lifecycle. Coach previews hold temporary local answers and cannot upload or submit
• Coach notes and goals
• Dated protocol titles, dates, private notes, colors, selected plan templates and recorded plan-start outcomes, including coach-authorized reads and edits through a connected AI client
• Memory a coach’s Launch Bots and the Zyx Goal Coach keep for themselves: short notes and Markdown files (an index, the coach’s corrections, practice facts, and per-client observations such as what a review proposed and where each goal stands), every version retained, visible and editable by the coach, never shown to the client
• Measurable goal baselines, targets, dates, constraints and progress assessments derived from check-ins; coaching interventions and their source records
• System Status coach focus notes, review dates and links to assigned tasks or plans; private anatomy view bookmarks with coach-written annotations and camera settings
• Private conversation follow-up notes written by a coach, with a chosen reminder time and the conversation they refer to
• Records a coach keeps for each client week in Runway, a week-by-week view of each client: a goal label, a phase label, a target weight, a travel week mark, a weekly note and a done mark; coach decisions and follow-ups (what changed in the plan, what to test or re-check and when, an optional reminder the coach may add to a review they send, and a coach-defined tag); date windows of plan changes the coach chose to hide; how far ahead the client’s planned weeks run; week plan drafts waiting for the coach to review (a proposed phase, goal, target weight and travel mark for each planned week, with a short rationale); and the coach’s choice of which measurement columns Runway shows for a client
• A written reply a coach pastes into a Runway week and keeps on it (saved by default, the coach can untick it or clear it later), with who saved it and when; a link from a decision to the 1:1 call it was found in
• Scores a coach sets up for a written check-in question (a short label and what 1 and 10 mean) and, for each check-in, a 1 to 10 score for that answer with a short rationale and a quote from the answer of up to 200 characters, proposed by AI and editable by the coach, charted in Runway Metrics
• A check-in Briefing a coach generates in the check-in review (a status line, what is working, what to watch, what to focus on and what changed since earlier check-ins) and a Checklist of proposed items for that review, each with the source it came from and a quote of up to 300 characters, and the coach’s done or dismissed mark on each item
• Checklist items still open from a client’s earlier check-ins, shown again on later reviews until the coach marks them done or dismisses them (after 12 weeks or 6 later check-ins they move to an “Older open items” group), and, stored with a Briefing, AI suggestions that one of those items looks resolved, each with a quote of up to 300 characters from that check-in; the coach decides whether to mark it done
• For a confirmed Runway decision, the metrics the coach chose to watch for its result (up to 4 metric names; none means the defaults for the decision’s category)

Controller: the Coach (we process on their behalf) · Sources: Directly from the client; Entered or uploaded by the coach on the client’s behalf; Uploaded by the coach as Library resources or Networks course lessons; Sent by a system the coach connected with a Partner API key, or read back out by it; Historical daily readings, body measurements, food and workout logs, hydration, assigned habit/supplement completions, and original coach notes imported through a coach-authorized connected AI client (MCP); Eligible client records read or updated by an authorized teammate through in-app AI or that teammate's connected external AI client, under current team and resource permissions

Pre-participation health screening · sensitive · optional

• Answers to the standard PAR-Q+ readiness questions (heart condition, chest pain, dizziness, chronic conditions, prescribed medication, joint or bone problems, and medically supervised activity)
• Whether any answer was "yes", and the date the questions were answered
• The coach’s decision about a flagged screening, the reason they recorded for it, and who made it

Controller: the Coach (we process on their behalf) · Sources: Directly from the client, through the client portal

Lab files and extracted markers · sensitive

• Uploaded lab PDFs and images (for example serum, gut, hormone, or mycotoxin panels)
• Marker names, values, and reference ranges extracted from those files
• Saved chart snapshots containing selected confirmed results, units, report intervals, and source references
• The patient name and testing company printed on the report, and the panel type read from it

Controller: the Coach (we process on their behalf) · Sources: Uploaded by the client or the coach

Progress photos and movement video · sensitive

• Progress and body-composition photos
• Coach-assigned physique photo labels and their client assignments, retained with each submitted check-in
• Lift and movement video submitted for form review
• Pose landmarks derived from that video to draw form feedback
• Workout clips shared with the coach in one message per lift, with an optional client question and recorded workout context
• Non-clinical visual body-fat estimates, uncertainty ranges, comparability notes, and week-over-week observations generated from progress photos when a coach enables photo review for Zyx
• Resized copies of check-in progress photos, with their check-in dates, photo labels and recorded weights, returned to an external AI client the coach connected through MCP when the coach requests them

Controller: the Coach (we process on their behalf) · Sources: Uploaded by the client or the coach

Connected device and wearable metrics · sensitive · optional

• Daily aggregates for steps, sleep duration, resting heart rate, and heart-rate variability, with Health Connect RMSSD kept separate from Apple Health SDNN
• Optional two-way weight sync on connected phones: latest manual daily or weekly weight is written to Apple Health or Health Connect with a stable source identifier and save version. The newest external weight within the last 30 days is read into the Home widget in memory. Health Connect weight is not uploaded by this device-only widget feature. Account-scoped enablement contains no measurements and is held in device cache until disabled, disconnected or cleared. Exported Health records remain until removed in Health; disabling or disconnecting does not erase them.
• Optional Apple Health weight: latest valid measurement per local day, stored in pounds with its measurement date
• Recovery, strain, readiness, and similar scores produced by the device maker
• Optional Apple Health workout summaries: activity, times, time zone, duration, distance, energy, average and maximum heart rate when available, recording source, and manual-entry status
• Client-selected links to assigned training, hidden-workout choices, and a random app-installation identifier and connection generation used to prevent stale uploads

Controller: the Coach (we process on their behalf) · Sources: Apple Health imports the latest valid weight measurement per local day within the last 90 days, stored in pounds as daily summaries. Connect or Sync requests weight read access; automatic collection never requests new permissions. Empty results can mean no source measurement or unavailable read access, which Apple does not distinguish.; Android Health Connect on the device, after the client confirms the in-app explanation and approves Android read permissions; after this phone is explicitly connected, foreground sync runs on app launch or return (at most every five minutes), on manual sync, or on permission changes; it reads at most the latest 30 local calendar dates, including today, and uploads daily summaries only; Whoop, Oura, Fitbit, or Ultrahuman, after the client authorises the connection

Messages and conversation content

• Grouped workout video feedback messages referencing private workout clips without making a second copy; these clips follow workout retention rather than direct-message video expiry
• Optional Library video identifiers in reusable instruction templates, assigned client instruction plans and three-day local unsaved instruction drafts. Videos remain in existing private Library storage; choosing one does not change its audience. Authenticated playback checks the assigned client, current coach, plan visibility and Library publication before issuing a five-minute URL. Hiding a plan or withdrawing access stops new URLs, while existing URLs can work until expiry. Removing a reference does not delete the original file. No playback analytics or new vendor is introduced.
• Optional coach-selected welcome videos uploaded to private Library storage and published by the coach for all clients. Uploading directly in Welcome video settings automatically publishes that new personal Library file for all clients, as explained beside the uploader; it does not change existing file or folder permissions. Saving the welcome selection controls its use in intake forms and emails. Removing the selection keeps the Library file until separately deleted. People with a valid, unsubmitted intake token can request five-minute playback links after the intake privacy step; signed-in clients can replay through authenticated email watch links. Form loads expose only the title until Watch is chosen. Intake and welcome emails contain a watch link, not the video payload. Clearing the setting or withdrawing Library access stops new playback links; issued links can remain usable until expiry. The original file stays in Library until removed under its existing retention.
• Ordered references from community posts and scheduled drafts to existing Shelf listings and Classroom lessons. References retain identifiers and order with the post or draft, not copies of resource content. Display metadata is resolved using each reader's current resource access; an unavailable resource shows no restricted title or playable address. Selecting a card does not assign a template, enroll a member or grant access
• Coach-authored community channel descriptions and composer prompts, independent posting and commenting settings, saved reading order, and community and channel pin flags. Guidance is shown only to eligible members and staff; existing authorized assistant summaries can read it as untrusted data. These settings remain with their channel or post until changed or the related record is removed
• Scheduled community post titles, messages, attachment references, mentions, channels, requested publication times and status. Pending and failed drafts are private to current staff of the owning community. Cancellation retains the private schedule; queue records are removed with the community, owner or author. Publication shares the post with the eligible community audience and sends eligible mention notifications
• Owner-uploaded community logo images, visible to current community members and staff on web and in the apps, or publicly when the owner explicitly lists the network on a connected published website; image metadata is removed during processing
• Owner-uploaded community and course cover images, with image metadata removed, read through authenticated membership or ownership checks, or through an explicit public website listing chosen by the owner
• Public network website listings explicitly enabled by the owner: the network name, description, logo and banner, selected published course titles, descriptions and covers, and selected upcoming event titles and times. Posts, member profiles, lesson content, meeting links and health data are not included. Unlisting or disconnecting stops new reads; artwork links already issued expire within 60 seconds
• Network join requests from existing accounts: account and community identifiers, request status and decision times. The applicant can read their own status; the network owner can review the applicant name and approve or decline. Joining makes the existing community profile visible to other members but does not opt the person into marketing or share private coaching or health records. Requests are removed when the account or community is deleted
• Optional member-authored community bios, up to 280 characters, shared with current members and staff of their joined communities beside their existing profile photo and community role; not taken from private coaching or health profiles
• Unique Networks handles assigned automatically and editable by their account owner. Handles appear in the owner profile and, for coaches who opt into the directory, in coach-only discovery and handle search. Assigning a handle does not opt anyone into discovery or enable client friendships
• Photos, documents and videos deliberately attached to community feed posts, shared only through an eligible current conversation or visible post reference; videos can be downloaded in their original format without direct-message compatibility conversion
• In-app messages between a coach and a client
• Coach-authored scheduled message text, quoted-message references, requested delivery times and delivery status; pending text is private to the owning coach until sent. Cancelled and failed schedules remain with the client record and are removed when the client or coach account is deleted
• Client web attachment outbox: files, captions and conversation references saved on the device after Send, so an interrupted upload can resume; account-scoped local copies are removed after confirmed delivery, removal or sign-out, and expired copies are cleared on the next visit after 24 hours
• Coach-private conversation snooze times and client-reply wake times; follow-up notes are never sent to the client and are removed when the coach completes or cancels the follow-up, or the related account or client record is deleted
• Posts, chat, comments and event responses in the partner community - a shared space for referral partners and the LaunchSite team, where everything written is readable by every other partner in the room
• Private photo, document, and video attachments sent in a direct conversation; an uploaded video original is available to the conversation while a compatible copy is prepared
• Group space conversations between a coach and the clients they added to that space
• When an eligible owner connects an external AI client, selected owned Networks channel settings, posts, comments, member identities, events, coach-owned Shelf summaries and Classroom learning paths may be returned to that client under existing external-sharing preferences. Authorized calls may publish content, create events or create/rename a Network as that coach. The external provider retains returned content under its own terms; revoking the connection cannot recall it. LaunchSite MCP audit records contain identifiers, argument digests and outcomes rather than these returned bodies
• Posts published to a community and their comments, visible to members permitted by the channel audience and membership tier, and to network staff. Selected-member channel lists and tier assignments are saved to enforce access; unrestricted channels are visible to every member of that community
• Per-network notification preferences for mentions, ordinary channel updates, replies and automations, saved until the member account or network is deleted. Coach-selected channel defaults and personal channel overrides are stored with channel and account identifiers and timestamps until changed or the channel or account is deleted. Overrides can follow the current default or turn ordinary delivery on or off; the network-wide ordinary-updates opt-out takes precedence. New feed alerts contain no post text and use existing in-app, browser and native push delivery only for currently eligible readers at publication, including scheduled publication. Later membership or drip access does not replay alerts. Muting delivery does not delete the underlying conversation or its unread state
• Network event titles, descriptions, times, repeat settings and RSVP answers visible within the room. When a coach chooses Zoom or Google Meet, only event titles and start/end times are sent to that provider through the coach-owned connection; provider identifiers and participant join links are retained. No member roster, RSVP answers or event descriptions are sent, and this workflow does not invite attendees or start recording. Deleting an individual event created with a managed meeting first attempts provider cancellation; older separately linked meetings remain provider-managed. Deleting a network or account removes local events but does not cancel provider copies; coaches manage remaining copies with the provider.
• The whole message history between a client and their coach, when a team admin or the coach transfers that client to another coach on the same team - the receiving coach can read it, and each message still shows who wrote it
• Posts, chat, comments and event responses in a community that a coach has invited another coach into - that guest coach reads everything written in the room, including messages from clients who are not theirs, and is shown to everyone in the room as a guest; they cannot see any client’s plans, check-ins, notes, labs or health records
• WhatsApp and Instagram conversations connected to the coach’s paid Pro CRM workspace; these channels are separate from private coaching messages
• For an Instagram professional account a coach connects directly through Meta, the conversations LaunchSite stores because Meta serves only the 20 most recent messages of each one: for every person who messages that account, their Instagram-scoped id, username, name, profile picture address (hosted by Meta, which expires it within days) and whether they follow the account; each message once, with its text, attachment details and Meta-hosted attachment addresses, a link to any story it replies to, reactions, read receipts, edits, timestamps, reply references, click-to-message ad referral details and, for a message sent from LaunchSite, who or which automation sent it; and the connected account’s id, username, name, account type, profile picture address and an encrypted long-lived access token. Media a person sends is fetched from Meta when it is viewed, not copied; media the coach sends is copied to private storage, and Meta fetches it through a link that expires within 15 minutes
• Programmable CRM workflow agent instructions, trigger data, selected CRM business context, business knowledge excerpts, generated replies and named output fields, prepared follow-up tasks, and optional memory. Results remain with the workflow run until the run or linked lead is deleted; only the last four successful results are recalled, per contact or across the workflow as the coach selects. With no memory, the input is not retained in the agent receipt. Generated SMS, Instagram and WhatsApp messages retain the reviewed wording and decision before delivery through existing providers.
• For enabled CRM messaging workflows: provider account, conversation, sender and message identifiers; inbound text and timestamps; the CRM contact and lead link; workflow enrollment, reply waits, handoff tasks and confirmed or uncertain send outcomes
• Website chat-widget conversations with a visitor, coach and optionally the coach-selected AI agent; a random visitor credential is stored in the browser session and only its hash is stored on the server, with access expiring after 30 days
• Google/Outlook mailbox connection identity and address, synchronization cursor and status, matched CRM email sender/recipient details, subject and plain-text body, provider message and thread identifiers, authentication results, reply matching and automation outcomes; raw attachments and unmatched message bodies are discarded by the importer
• Coach-selected mailbox Reply-To routing; imported sender verification is unavailable and synchronized mail does not authorize reply workflows or AI actions; disconnect stops collection and is confirmed separately with the mailbox provider
• Email consent and opt-out history for each person, by purpose (marketing or one-to-one outreach), recorded as the person's own decisions, including an opt-out the person gave the coach directly and the coach recorded for them (with who recorded it and how the person said it), applying to every opportunity recorded for that person and to their member record, kept when one of them is deleted; the person's own "stop" in an Instagram or WhatsApp conversation, recorded for that channel only, and a website chat withdrawal the person gave the coach to record; separately, a public website visitor's request to stop automation on their own inquiry, which does not change the consent of another person matched by their unverified email; separately, the coach's own Do Not Contact block and whether the coach or an earlier opt-out set it; a suppression list that holds no email address, only a keyed identifier derived from it, for an address that reported an email as spam, that sent a "stop" while several contacts share it, or whose person was deleted while their opt-out stood; plus withdrawals already recorded against a messaging channel we have since retired, which are retained rather than erased

Controller: the Coach (we process on their behalf) · Sources: Sent by you; Received from the person you are talking to; Delivery receipts from the platform the message went through; Meta, for an Instagram professional account a coach connects directly: notifications of new, edited and unsent messages, reactions, read receipts and ad referrals; Meta’s message and profile details for the people who write to that account; and, when the account is connected, its most recent conversations (up to 25, with up to 20 messages each)

Voice input, call recordings, transcripts, and synthetic voice · sensitive · optional

• Coach-selected Loom or Tella review transcripts, used for written reviews and explicitly confirmed client memory notes
• Recordings and transcripts of consults and coaching calls the coach chooses to capture
• Derived call metrics about the coach’s own delivery (talk ratio, questions asked, whether a next step was set)
• Audio generated from a configured synthetic voice
• Microphone audio captured while a coach uses a voice feature - the Cowork consoles and dictation - and streamed to the voice provider or sent for transcription
• Text from a Loom video transcript a coach attaches to a check-in review, and dictated notes, used by Runway to propose decisions, with a supporting quote of up to 300 characters kept on each proposal
• Loom or Tella transcript text a coach pastes into one week of a client’s Runway, read once to propose decisions for that week and not stored; only a supporting quote of up to 300 characters is kept on each proposal
• The notes of a 1:1 call a coach logs, and its transcript only when the client allows recordings, read when the coach asks Runway to find decisions in that call; only a hash of the text read and a supporting quote of up to 300 characters on each proposal are kept
• A Loom or Tella transcript held for a check-in review, and 1:1 call notes in that check-in’s window, read when a coach generates the check-in Briefing (the transcript only when the client allows recordings)

Controller: the Coach (we process on their behalf) · Sources: Uploaded or captured by the coach; Meeting platform transcripts the coach imports; The coach’s microphone during a voice session they start, or that Cowork starts for a new client message while the default-on message setting is enabled

Prospect, lead, and CRM contact information

• Native CRM resource titles, uploaded files, saved document text and revisions with the real author identity. Authorized Google Drive imports create private stored copies; native Google documents become PDF snapshots. These imports do not automatically enter AI Memories. Unsaved document text and retry identifiers may remain in browser session storage, isolated by signed-in actor, workspace and document, until saved, discarded or the browser session ends. Server files and versions follow existing resource/account removal and infrastructure backup procedures. An uncertain upload may retain candidate bytes for later reconciliation rather than risk deleting a committed file.
• Name, email, phone, company, and stage for people in a coach’s pipeline
• Form submissions, booking requests, business-card scans, and QR-code captures
• Contact-addressed form answers, retained question and consent snapshots, score and attribution; exact contact/form identity, email-address hash and optional client association bound to a personal form link. This capture does not create an opportunity or grant email marketing permission
• Reviewed contact-form email subject, body, recipient and frozen provider payload, with pending, attempted, accepted, failed or uncertain outcomes. Preparation saves the message without sending; status checks never dispatch another email
• Reviewed contact-resource email subject, body, recipient, selected resource and frozen provider payload, with preparation, dispatch and recorded outcome. Standalone delivery does not create an opportunity or client Library share
• Standalone-contact erasure previews and completion receipts containing record counts, the acting user, workspace, request identifier, completion time and an owner-scoped target digest. Completion receipts contain no contact identifier, name, email or answer text
• Booking follow-up snapshots containing the submitted name, email, notes, appointment details and delivery receipts, kept until the appointment or owning account is deleted
• Answers and participation scores from coach-published native application and quiz templates, with the visitor’s recorded consent
• Form action receipts containing the saved submission and opportunity references, label add/remove operations, pipeline and original/target stage keys, original changed or no-op results, and occurrence/stage-entry times. These contain no answer text and support safe replay of the same saved submission without repeating the original label or stage mutation
• Saved form follow-up plans, including plans with no automations; selected automation definitions, configuration snapshots, original event identity and trigger context, opportunity revision and pipeline fingerprints, enrollment or refusal outcomes, run references and the acting user for a reviewed retry. These support retrying only the original pending automations after current ownership, consent, access and context checks
• UTM campaign, medium, content, and term recorded when a lead arrives from a link
• Notes, tasks, deals, estimates, and activity history the coach records
• Bulk action run identity, acting user, reviewed action parameters, task title and due time, request fingerprint, owned contact or opportunity references, individual outcomes and recovery state. Reversible changes retain previous values and revision tokens to avoid overwriting later edits. Stage moves, person merges and erasure retain confirmed, skipped, failed or unconfirmed progress. Target references are removed when related records are erased; a deletion by the run itself retains an anonymous outcome without the opportunity identifier
• New bulk workflow enrollment receipts retain the actual initiating user, exact opportunity selection, accepted workflow run references and refused or unconfirmed outcomes. Campaign release receipts retain the actual releaser, campaign and exact queued target identities. These records establish acceptance or release, not message delivery; older operations are not backfilled. Workflow run references clear when those runs are deleted. The browser temporarily retains the pending enrollment request and selected identifiers in session storage for retry recovery
• Contact CSV preparation receipts containing workspace, acting user, request identifier, row count, filename, scope, preparation time, selection fingerprint and content digest. CSV contents and raw selected identifiers are not stored in these receipts. Preparation does not confirm that the browser saved a file
• Coach-reviewed proposal email subject, text, recipient, frozen delivery payload and provider-attempt status, handled through the existing CRM email channel
• Form request key hashes, payload fingerprints, original submission/correlation/time, planned or resolved contact and opportunity identifiers, ambiguous candidate references, creation intent, status and cached response. The native browser retains only an opaque request key in session storage for status checks after reload, not answers or personal-link tokens
• Form and intake completion notices: workspace owners receive the contact name, form title and authenticated response link; assigned teammates without response access receive only a generic review notice. Answers are excluded from these notification emails. A recipient-specific event claim prevents repeated optional delivery requests for an already saved notice
• Saved proposal-page title, intro, body, investment and optional payment or booking action; drafts require the owning workspace to preview, while explicitly published pages are available to anyone holding their private link
• Retained Jev classifications, source references and coach review corrections from before the module hold; numeric prediction-time snapshots and observed CRM outcome labels
• Retained weekly pipeline checkpoints for 30-day and 90-day projections from before the module hold; no new checkpoints are captured
• The stage each checkpoint reached 30 or 90 days later, each open opportunity’s latest 30-day and 90-day projections, and the contacts the coach excluded from projections
• Legacy Ghost evidence queue entries, containing opportunity identifiers, event kinds and retry timing but no message or answer content; held entries remain eligible for cleanup
• Publicly self-published prospect profile or coaching-interest details, individual-or-business classification, source excerpts and URLs found by a coach-directed Lead Scout search; no inferred private health details

Controller: the Coach (we process on their behalf) · Sources: The person, when they complete a public form, book a call, or scan a card; The coach, when they add or import a contact; Public search result titles, snippets and source links returned through self-hosted SearXNG at the coach’s direction

LaunchSite OS business contacts and activity

• Contact names, email addresses, phone numbers and companies
• Platform sales opportunities, notes, tasks, communications and connection records
• The platform owner who created or changed a shared business record
• Public business-call requests: name, email, optional inquiry notes, selected time, timezone and assigned LaunchSite host

Controller: LaunchSite OS · Sources: People contacting LaunchSite OS; Authorized LaunchSite OS business owners adding or importing records

Subscription and payment information

• Abandoned Checkouts reads expired unpaid live Stripe session identifiers, amounts/currencies, creation/expiry times and available or preset customer name/email, matched to exact owned payment-session, Payment Link or commerce-order references on the currently authorized account. Results are transient read-only observations and this view stores no new lifecycle or customer record. Existing local and Stripe records retain their separate retention. Expiry does not establish visitor behavior, recovery or marketing consent; this view sends no reminders and creates no checkout or charge.
• Explicit Stripe catalogue imports read the authorized connected account and product/price records. Confirmed local imports retain the owner, Stripe account/product/price identifiers, name, description, price labels, amounts, currency, source fingerprint and original local snapshot. No Stripe records are changed and no customer records, messages or charges are created by this import. Provenance has no automatic age expiry and restricts deletion of its local product; the product can be archived. Owning-account deletion cascades to provenance records. Stripe retains its own source records under its retention policies.
• Standalone single-use product payment links retain the owner, selected product/version, frozen link name, price and currency, request and payment identifiers, connected-account identity, provider URL and creation/reconciliation state. Stripe receives the name, amount, currency and correlation metadata and collects buyer payment details. These records have no preselected client or lead and create no contact, marketing consent or local receipt email. Request records have no automatic age expiry; deleting the associated payment or owning coach deletes the request record. Provider records and buyer copies follow their own retention. Product deletion is restricted while referenced by a request.
• Coach-reviewed product CSV imports send only mapped product names, descriptions, default prices, currencies and types for owner-scoped preview and creation. The original file is parsed in the browser and is not retained by this path. Stable owner/name/currency-derived identifiers belong to the saved products; no separate import-history file or row report is stored. Products follow existing catalogue retention and deletion handling. This path does not contact Stripe or another import vendor.
• Optional native payment receipts store owner-enabled settings, numbering, sender display name and Reply-To address, subject/template/notes, frozen payment amount and currency, payer email and record references, prepared email content, provider correlation and send status. Future settled online payments capture one receipt while enabled; no historical backfill occurs. The configured Resend or Amazon SES transactional provider receives the receipt and recipient address. The verified sending address stays platform-controlled. Disabling prevents unclaimed sends, not recall of an in-flight or delivered email. These local settings and receipts have no automatic age expiry; deleting the payment removes its receipt and deleting the owning coach removes its settings and receipts. Other retained email logs and provider/recipient copies follow their separate retention and deletion handling. Notes should not contain health information or marketing.
• CRM coupon rules and immutable payment snapshots include discount names/codes, currency, schedules, selected products, duration and usage limits. Redemption allocations retain normalized billing email or an owner-scoped payer record key, payment/product references, provider account/coupon/session identifiers and issuance or uncertainty state. Guest email is not identity-verified. Drafts and pending checkout attempts reserve usage; safe cancellation releases usage while retaining the receipt. These records have no automatic age expiry. Deleting a coupon clears its live reference but retains the saved financial terms; deleting the owning coach removes local allocations. Stripe coupon and subscription records require separate provider handling. Editing or deactivating a coupon does not reprice previously issued invoices or subscriptions
• Organization payment connection reviews retain the current owner, credential owner, exact connected Stripe account, version, provider verification time and an audit event. A transfer requires a new review; it never copies former-owner credentials or moves existing subscriptions, payment methods or refund accounts. The owner authorizes new collections only after the server verifies the account with Stripe.
• For gym four-week and prepaid memberships: frozen checkout terms and agreed package price, member, contract, payment and acting account identifiers, connected Stripe account and payment-link/customer/subscription/invoice references, payment confirmation timestamps, original-age credit lots, scheduled paid coverage, deferred accounting receipts and recovery status. Vacation adjustments store approved dates, reason, approver, prorated paid amount, invoice reservations and provider adjustment receipts. Reasons are internal billing records and are not sent in Stripe invoice descriptions. This workflow does not store raw card data
• Gym membership catalogue versions store site, service, audience, frequency, private group size, package price, optional revenue account and permitted discount rules. Agreement snapshots preserve the selected accounting site and account for receipts, earned revenue and refunds. Agreed prices retain discount calculations, the approving account and a short internal eligibility reason. Archived entries retain the acting account and timestamp. Eligibility reasons should not contain student, service or family identity documents and are not sent to Stripe
• Gym refund records include the paid period, approved amount and method, internal reason, retained-credit decision, separate authorizing and executing staff, provider refund references and status, journal entries, and an audit history. Recorded check or ACH refunds include the staff-supplied payment reference, date and mapped business bank account. Card refund requests send Stripe the charge, amount and internal refund identifier, not member notes or the approval reason
• For independent Client plans and per-client coach sponsorship: payer and beneficiary identifiers, verified paid periods, separate subscription identifiers, allowance grants, reservations, receipts and refund or dispute reversals. Billing metadata excludes health details.
• Plan, subscription status, invoices, and billing email
• Historical assistant model add-on subscription identifiers, status and payment records remain for billing reconciliation; new model upgrade purchases are unavailable
• Optional internal Discord billing alerts: opaque account and managed-app purchase identifiers, processor receipt identifiers, known product labels, amounts/currency, event status and times, and delivery/retry receipts. The alert projection excludes names, emails, addresses, card data, raw decline descriptions, customer-authored metadata and health content.
• For the separate Pro CRM add-on: payment-processor subscription and price identifiers, subscription status, paid-through date, cancellation setting and synchronization time; access follows the governing team owner and also requires the coaching subscription
• For a CRM website domain purchase: the selected domain, Cloudflare registration and renewal quote, screening result, Stripe customer, Checkout session and subscription identifiers, registration status, and provisioning timestamps or error state
• Limited card metadata (brand, last four digits, expiry) returned by the payment processor
• For a managed coach app purchase: the selected setup offer, a secret token for its permanent payment link, payment-link status, and processor session, customer, and subscription identifiers
• For coaches who sell through the platform: payout account status and marketplace transaction records
• For shared CRM and Networks website payments: coach-authored offer descriptions, one-time amount and currency, course and Network bindings, chosen webhook endpoint, signed-in buyer identifier, checkout consent version, connected Stripe account and session/payment identifiers, payment/refund status and timestamps. Course access grants identify their purchase or automation source
• For recurring Network memberships: immutable monthly or yearly plan terms, saved tier and course bindings, explicit recurring consent version, buyer and merchant identifiers, Stripe subscription/customer/invoice references, paid-through and grace-window dates, cancellation and refund amounts. Stripe hosts payment entry and billing management; no raw card details are stored by this workflow
• For reusable course Marketplace sales: a seller-authorized fixed curriculum snapshot including assessment definitions and licensed private lesson asset references, seller license confirmation version, buyer purchase and resulting unpublished course identifier. No learner submissions, grades, progress, memberships or client records are included
• For a payment a coach records as received outside LaunchSite: the client or lead, amount, currency, received date, payment method, optional description and reconciliation note, and the account that recorded it
• For a call booked on a coach’s public booking page: the amount, currency, whether it was paid, and the processor’s session identifiers, linked to the appointment it paid for
• For referral partners: the PayPal address you give us to be paid at; the code attribution; commission entries calculated from each collected subscription payment after discounts and excluding tax; separately approved fixed commissions with the referred account name, Stripe customer and invoice identifiers and approval reference; refund reversals; and payments recorded by a platform administrator, including the amount, date, optional reference and the commission entries settled. These records support referral histories and monthly payout tracking

Controller: LaunchSite OS · Sources: You, at checkout; Our payment processor; A referral partner, when they enter the PayPal address they want to be paid at; Platform administrators, when they record a missed partner-code attribution for an existing coach, with an audit record of the assignment; A visitor to a coach’s public booking page, when that page charges for the call; A coach or authorized money staff member, when they record a payment received outside LaunchSite

Campaign and engagement records

• Website media-library uploads, including optional AI Atelier logos and photos, their filenames, dimensions and workspace ownership
• Private versioned website and funnel template snapshots, embedded copies of owned website images, explicit recipient account grants, and draft-copy recovery receipts
• Branded PDF guides and silent MP4 ads generated on explicit request from owned page or campaign content, including coach edits used only for that download
• Coach-requested Atelier campaign kits: coordinated ad copy and colors, downloadable SVG creative, email subject/body, and references to their draft page and reusable email template
• Connected business locations, Facebook Pages, Instagram business accounts and advertising account identifiers, names, timezone and currency
• Encrypted marketing-provider authorization tokens, granted permissions, account selection and connection status
• Which campaign emails and messages were sent to whom, and when
• Coach-selected opportunity or contact identifiers retained on email drafts to preserve an exact recipient selection, recipient identity type, and the acting creator recorded separately from workspace ownership
• Frozen email content, sender and recipient details, experiment variant, sending attempt, provider message identifiers, and a private unsubscribe capability tied to the recipient
• Private resource email download grants: workspace, opportunity or exact contact identity, selected resource and file, recipient address, optional client association, request identifier, activation and expiry dates, and optional revocation date
• Scheduled automation snapshots and delivery receipts, including the saved audience and workflow configuration, retained until their automation is deleted
• A random first-party funnel visitor cookie, per-experiment hashed visitor identifier, assigned variant, entry date and verified lead-capture outcome; no IP address or browser fingerprint is stored in experiment records
• Delivery, open, click, bounce, complaint, and unsubscribe event identifiers and timestamps reported by the sending provider; campaign events do not store raw clicked URLs, IP addresses or user agents
• Public Google and Facebook reviews: author display name, rating or recommendation, written feedback, provider identifiers and dates
• Coach-authored, coach-requested or explicitly opted-in automatic AI public review reply drafts, saved revisions, source fingerprints, automatic settings and generation attempts, explicit approval actor and time, publication attempts and provider-confirmed outcomes
• Recipients, request content, delivery outcomes, cooldowns and coach-selected first-attendance or first-payment rules for review-request emails
• Which public reviews a coach selected for an embeddable widget, and its revocable public link
• Daily campaign spend, impressions, clicks, currency, timezone and import coverage from selected Google Ads and Meta Ads accounts
• Coach-selected campaign tag mappings and reconciliation of CRM acquisitions against recorded paid ledger entries
• Selected Google or Meta lead-form identifiers, submission dates and campaign identifiers, import outcomes and references to the created or matched CRM contact
• Standard name and email fields copied from a selected provider form into a CRM contact; phone fields and custom answers are discarded rather than saved by the importer
• Meta form responses can contain additional answers in transit; the importer does not retain the raw provider response
• An email-permission hold for newly imported contacts and the workspace owner’s dated evidence of permission when they clear that hold
• The reviewed manual workflow explicitly selected to follow up with an eligible ad lead, its deduplicated enrollment and subsequent draft-review outcomes
• Versioned lifecycle package and portable setup installation receipts, selected dependency mappings and references to copied configuration assets; portable exports exclude contact and member records, credentials, payment history and outbound approvals
• Social post drafts, captions, links, selected business accounts, scheduled release times, immutable public media copies, provider post identifiers and observed likes and comments
• Explicit owned saved-post history searches read titles and captions in bounded pages without provider or AI calls. Studio Review Request manually selects an eligible business contact to open the existing approved review-email form; no model receives the selection and agent-generated copy does not replace saved account messages
• On-demand Facebook Page comments on owned published social deliveries: comment text, optional author display name, provider comment identifier and timestamp, transiently returned after current access and provider authorization checks
• Reviewed Social CSV imports create private Facebook text and link drafts. Import receipts retain the CSV basename, selected account identifiers, workspace and initiating actor identifiers, request identity, content and row hashes, original post identifiers, row order, count and timestamps. Closing an unresolved import retains its request identity, content hash and closure time to prevent a late retry from creating drafts
• Which members a coach put on a retention list, the stated reason, and whether a staff member contacted or skipped them
• A staff member’s own note about a contact attempt, and the date it was made
• Whether a member agreed to marketing on a given channel, when, what wording they were shown, and whether they later withdrew it
• A member’s unsubscribe token, so a one-click unsubscribe works without them signing in

Controller: the Coach (we process on their behalf) · Sources: Generated when the coach sends a campaign; Uploaded or selected by a coach while preparing website branding; Generated by the existing AI provider when the coach requests a coordinated Atelier campaign kit; Returned by Google or Meta after the coach authorizes a marketing connection; Reported back by the email provider; Recorded by a staff member working a LaunchPoint retention list; Captured from the member themselves - at the desk, on a form, or by their own unsubscribe

AI prompts, outputs, and workspace memory · sensitive

• Explicit Weekly Creative Studio generation sends the supplied brief, saved instructions and selected accessible business knowledge to the existing governed AI provider. The editable 3 to 7 text/link drafts remain in the current panel or an explicitly reviewed same-tab transfer to Social Planner, with no server-side pack record. The temporary transfer is cleared on discard, reload or business change and is not written to browser storage. An optional downloaded CSV remains on the user device. A separate reviewed Social CSV import creates normal private drafts under existing social-post and import-receipt retention. Generation and download do not import, schedule or publish posts
• Explicit Marketing Performance Report Run now saves a private campaign-to-date report from one owned email campaign and its bounded aggregate evidence through the existing governed AI provider. Only the initiating actor with current workspace access and unchanged eligible source evidence can open it. An immutable attempt receipt holds campaign identity, source and agent hashes, request identity, owner, actor, payer, timestamps and outcome. No recipient identities or message content enter model context; this adds no campaign sending, publication, scheduled execution or new provider
• Explicit Agent Studio Email Campaign drafting sends the submitted brief, saved instructions and selected accessible business knowledge to the existing governed AI provider. A separate reviewed Save stores the edited name, subject, body, heading, bullets and button in the existing owner-owned email template library. Content-free recovery records contain business owner, acting user, paying account, agent and request identifiers, a content digest, template reference, timestamps and status. Generation and saving create no recipient list, campaign or delivery
• Explicit New Deal Brief Run now saves a private generated business report and an immutable attempt receipt containing source and agent revision hashes, request identity, workspace owner, acting user, paying account, timestamps and outcome. The report is visible only to that actor under current workspace access and unchanged eligible opportunity evidence. Reports use the existing governed text provider and do not send messages, create tasks, change stages or activate triggers
• CRM Agent Studio setup and manual test messages, up to six recent conversation turns, saved agent settings, and up to six selected knowledge excerpts of 900 characters each with document titles, sent to the existing AI provider. Manual knowledge tests verify current owner access, ready personal AI Memories status and non-client-bound folder scope before and after retrieval and after generation. New Deal Brief and Lead Research & Scoring can also send an explicitly selected business opportunity name, stage key, value and source, up to ten recent activity excerpts of 600 characters each, and ten open task titles of 200 characters each with due dates and priorities. Lead Research & Scoring additionally sends the explicitly supplied qualification criteria, up to 2,200 characters, for a manual assessment without saving a score or changing CRM records. Client-linked opportunities and contacts are excluded. Marketing Performance Report can send an explicitly selected email campaign name, status and dates, plus aggregate acceptance, delivery and engagement counts across up to 10,000 recipients. Recipient identities, message content, provider IDs and raw errors are excluded from model context. Ownership, eligibility and evidence are rechecked after generation. Email, phone, intake, task notes and activity metadata are not selected. They do not publish agents or send CRM messages
• Optional coach-owned Claude routine connections: encrypted trigger tokens, routine identifiers, event and scheduled action context, coach-configured input with resolved references, launch attempts and session references, optional private results and coach notes. Intake events retain immutable submitted question and answer snapshots. The coach's external Claude account uses its own instructions, enabled skills and authorized MCP tools
• Coach-uploaded AI Memories photos: stored Library originals and AI-extracted visible text, tables and factual descriptions indexed as searchable passages, with source section headings retained alongside table rows. A bounded, orientation-normalized copy without image metadata, optionally accompanied by up to two overlapping detail crops within the same total byte limit, is sent to the existing configured AI provider after scope and permission checks. Client-bound folders restrict recall to that client; unbound folders are practice-wide and explicit team copies use team scope. Moving a photo out or removing it from Brain removes searchable passages but retains the Library original. Deleting a Library source removes the searchable passages in its own corpus, including mobile direct-row deletion, and prevents delayed ingestion from recreating them. Explicit independent team copies retain their own lifecycle. Web Library deletion also attempts original and saved-version file cleanup with shared-reference checks. Mobile direct-row deletion does not perform this file cleanup. Provider copies and backups have separate retention
• Content-free AI confirmation receipts containing a hashed confirmation token, tool name, execution status and timestamps, retained with the coach account to prevent repeated actions
• Private background website and funnel build briefs, asset references, progress, draft results and visual findings; transient rendered desktop and mobile screenshots are sent to the existing AI provider for requested design review
• Optional website-building inputs: selected logo and photo image contents, filenames, placement notes and a main brand color, sent to the existing AI provider when the coach requests a build or revision
• Explicitly approved Atelier project/workspace design decisions, their versions, build-time snapshots, live section previews, queued steering feedback and quality-review evidence
• Named Atelier workspace brand kits with owned media identifiers, reviewed design tokens, supported font styles, writing guidance and selected-kit preferences; generated artwork set metadata and associated media-library assets
• User-requested frozen design previews, normalized pen/box/text feedback, annotated PNG evidence and up to two selected reference images, saved privately with project files and sent to the selected AI engine only on an explicit feedback build; portable spacing, type, theme and motion settings
• Creative studio element identifiers, persistent pinned comments, selected batches, before/after proposals and decisions, screen connections, copied brand tokens and locks, configurable assets and branched project files
• Creative workspace project files (HTML, CSS, JavaScript, text, images, fonts and optional audio), imported public-page or element captures, custom design guidance, up to 40 conversation messages, private unfinished checkpoints and up to 20 saved file versions
• Explicitly selected Atelier pictures and visual references, including image bytes, filenames and whether each image is intended as design content or reference-only guidance. Pending attachments remain in the open browser until explicit project creation or a build saves them with the private project files. A requested hosted build sends their image contents to the existing design provider; saved files and versions retain the references under the existing project retention. Connected local engines receive the selected files through their existing file handoff
• Original image prompts and selected owned reference images sent to OpenAI image generation or editing and the generated images returned to the project; exported HTML, ZIP, PDF, editable PowerPoint, Figma layer JSON and H264 video with an optional supplied audio track
• AI Atelier brand preferences stored in this browser for the selected workspace: selected media identifiers, filenames, roles, placement notes, color and design skill choice
• Optional Juno course learning, including requests made as the learner advances slides after selecting Start interactive learning, sends the current authorized lesson notes, native or HTML slide text, learner questions, quiz answers and up to 12 recent chat turns to the existing configured AI provider. It does not capture screen images or read external iframe pages or videos. Chats and practice answers stay in the active browser component until cleared, the slide changes, or the learner leaves; they are not stored as course grades or coach-visible chat history. Content-free usage records use the existing AI metering retention and charge the course coach’s AI credits
• Juno course presentation briefs, selected Atelier skills and explicitly submitted lesson context or draft HTML/CSS, theme settings and coach-supplied iframe URLs/titles sent to the existing AI provider. Full Networks Atelier builds save editable project files, build messages, curriculum drafts, assets and revision history in the coach-owned Atelier workspace. The coach can explicitly create expiring design review links. Quick slide drafts remain in the open editor until used or discarded. Adding a presentation to Classroom requires review and a separate lesson save, which stores its presentation and private text PDF through the education library
• Optional Atelier concept briefs and native previews, selected design-system references, element/property or phone edit targets, browser-local section locks, durable paid-step checkpoints, measured credit usage and revision proposals with individual accept/reject decisions
• Estimated brand palettes, supported typography styles, spacing, corners and visual guidance derived from selected owned website structure or uploaded visual reference images, reviewed and saved by the coach in browser storage
• Durable native page design checkpoints and restore events used for Atelier history comparisons; comparison previews are rendered from saved documents rather than retained screenshot images
• Content-free AI run stage timings, parent and specialist token totals, admission reservations, provider attempt checkpoints, and confirmation timing used to diagnose latency and reconcile usage
• The workspace content sent to an AI provider to produce a requested output
• Drafts, summaries, and suggestions the AI returns
• Saved AI memories and embeddings derived from workspace content
• For a gym CRM after an ownership transfer, content-free usage is charged to the current organization owner while run history retains the organization workspace and actual acting account identifiers. Personal mailbox, calendar, social and payment connections are not transferred with CRM records
• A per-coach record of AI usage and cost against the monthly credit limit, including Launch Bot runs, Co-work actions, and live voice session duration and deduplication references
• Operational records of each AI run - which feature ran, which model, how long it took, how many tokens it used, which tools ran, whether retrieval found anything, and whether the coach approved the result. These records contain no prompt, reply, or document text
• OAuth connection, tool-call, change, and usage records for an external AI client the coach connects through MCP
• Optional Atelier computer pairing and heartbeat records, hashed device credentials, selected CLI and model, design briefs, brand media, draft context, review screenshots and returned design objects sent through a paired computer to the coach-selected Codex, Claude or OpenCode API provider account
• Atelier public URL inspection references: source URLs, DOM/CSS, section bounds, observed interaction notes and desktop/tablet/phone screenshots, saved only when the owner creates a project; public sites receive ordinary unauthenticated GET requests
• Atelier selected public JSON/CSV/GitHub endpoints or uploaded data files, manually refreshed snapshots, source labels and fetch timestamps stored in owned project files and versions
• Atelier workflow definitions, declared inputs, revision records, selected repository source references and downloaded framework handoffs
• Atelier review-link hashes, expiry and revocation, reviewer account identifiers and names, comments, target labels, project versions and last-viewed timestamps; the rendered design and its data snapshots are visible to signed-in Pro CRM users holding an active review link
• Selected chart measurements, dates, original units, source references and rendered images returned to an external AI client for a coach-requested MCP chart
• Resized check-in progress photos, with their check-in dates, photo labels and recorded weights, returned to an external AI client for a coach-requested MCP photo read
• Historical chart requests and source revisions in previously saved conversations
• Private Zyx review proposals, coach-edited versions, approval decisions, source evidence, goal assessments, action outcomes and delivery receipts
• Runway decision suggestions: when a coach asks to find decisions in a check-in review, or has turned on automatic suggestions, the coach’s review text, private notes, the Loom or Tella transcript text while it is still held for that check-in, and any dictation are sent to the configured AI provider (Azure AI) to propose plan changes and follow-ups, each with a supporting quote of up to 300 characters. Client answers are not sent. When AI is unavailable or switched off, keyword rules inside the app propose items instead and nothing is sent
• Pasted text: a Loom or Tella transcript or a written reply the coach pastes into one week of a client’s Runway is sent to the configured AI provider (Azure AI) to propose plan changes and follow-ups for that week and its check-in, each with a supporting quote of up to 300 characters. A pasted Loom transcript is not stored, logged or kept in the AI run record. A pasted reply is saved to the week, visible only to the coaching team, unless the coach unticks “Save this reply to the week”; it is never logged or kept in the AI run record. When AI is unavailable, keyword rules inside the app read it instead and nothing is sent
• 1:1 calls: when a coach asks Runway to find decisions in a call, its notes, and its transcript only when the client allows recordings, are sent to the configured AI provider (Azure AI) to propose plan changes and follow-ups for that week, each with a supporting quote of up to 300 characters. Only a hash of the text read is stored on the call
• Check-in Briefing and Checklist: when a coach generates a Briefing in a check-in review, the client’s answers to that check-in and up to 5 earlier check-ins, their phase, the coach’s and client’s messages in the window since the previous check-in, the Loom transcript held for the review (only when the client allows recordings), the notes of up to 3 1:1 calls in that window, and open Runway follow-ups and recent decisions are sent to the configured AI provider (Azure AI). It returns a coach-only summary and proposed checklist items, each with a quote of up to 300 characters. Changes in tracked metrics are computed inside the app. Nothing is sent to the client. Up to 15 checklist items still open from earlier check-ins (their text and the date of the check-in they came from) are also sent, so the AI does not repeat them; it may suggest that one looks resolved, with a quote of up to 300 characters from this check-in, and that suggestion is stored with the Briefing until the coach marks the item done or the Briefing is generated again
• Runway answer scores: for each written check-in question a coach chose to score, the text of the client’s answer, with the coach’s label and what 1 and 10 mean, is sent to the configured AI provider (Azure AI) to propose a 1 to 10 score with a rationale and a quote from the answer of up to 200 characters. An unchanged answer is not sent again. Where a coach has set up scored questions, this runs automatically when the client submits or edits a check-in (at most 40 automatic runs a day per coach), with the same data, provider and storage; the coach can turn it off with “Score new check-ins automatically” in Runway Metrics
• Runway replies and search in the assistant: when a coach asks their assistant, or an AI client connected through MCP, about a client’s weeks or to search their Runway records, the matching saved replies (up to 500 characters a week) and search snippets from decisions, week notes and labels are included in the request to the AI provider. A client’s weeks also carry each confirmed decision’s “Did it work?” result (weekly weight rates and watched metric readings before and after, computed inside the app)
• Week plan drafts: when a coach asks to draft a client’s planned weeks (in Runway or through their assistant), the client’s weight goal and target date, their latest weekly average weight, the check-in cadence and unit, the protocol block names and dates, the coach’s phase names, the values already set on those weeks and any instructions the coach types are sent to the configured AI provider (Azure AI) to propose a phase, goal and target weight for each planned week. The client’s name, check-in answers, notes and messages are not sent. When AI is unavailable or not permitted, the draft is built inside the app from the goal and protocol blocks and nothing is sent
• Operational records of each Runway suggestion run: what started it, its status, the model, how many items it found and a hash of its inputs. These records contain no review, note, transcript or quote text
• Explicit coach feedback and scoped, conditional coaching instructions used in future Zyx reviews
• Private coach revision requests, saved Zyx acknowledgements and results, immutable draft-version history, and instruction merge/conflict decisions with supporting evidence
• Structured follow-up expectations, due dates, captured goal baselines, comparisons with later measurements, and the coach’s outcome assessments and client-experience notes
• Optional coach ratings of selected Zyx reviews - quality, corrections and actual review minutes - saved in the workspace for the coach’s own evaluation
• A covering team coach’s read-only view of private Zyx reviews, only after the owning coach grants that access; covering coaches cannot approve, edit or send
• Feedback-request display and dismissal times, unanswered-request counts and pause dates used to limit repeated feedback prompts
• A private Cowork Markdown notebook of general working preferences, decisions and unfinished work, extracted from voice transcript batches while memory is enabled; its current text, one Undo copy, update time and learning setting. The notebook does not add raw transcript or audio storage. Clearing removes both notebook copies and disables learning; existing chat and client Brain records have their own retention.
• Launch Bot definitions a coach creates or edits: the bot’s name, avatar choice, instructions, chosen model, selected tools, schedule, task description and notification preferences
• Private coach–bot conversation threads, including the reports an unattended scheduled run posts, proposed actions waiting for the coach’s approval, automatic Growth Huddle CRM import results, the coach’s approve/dismiss decisions, and the Executive Assistant’s practice recommendations with the coach’s accept, dismiss or defer decisions and optional reasons
• Operational records of each scheduled bot run - when it was due, whether it ran, was skipped or failed, and why
• Group conversations between a coach’s Launch Bots - the coach’s messages to a group and each member bot’s replies, with proposed or automatically applied actions attributed to the bot that raised them
• Short notes a Launch Bot keeps for itself from its runs and conversations, visible and deletable by the coach in that bot’s settings
• Loom check-in review drafting creates a private editable review note with the client-facing sections. The note is appended to the coach-only draft and follows that draft and client record retention; it is excluded from client messages and voice-learning samples
• Coach-provided Loom transcripts and other writing samples saved from bot chat into private, versioned voice files to personalize written drafts
• Which client events a Launch Bot runs on, the documents it may read, and the actions a coach allows it to take on its own - plus the record of each change a bot applied under that permission, and each run’s estimated cost against the bot’s monthly budget
• Scientist coaching research briefs derived from a completed verified lab review, the client’s coaching context, permitted knowledge sources and optional related public research. Briefs remain in the coach’s bot conversation. Historical PDFs produced by the former Lab Analyst remain in private storage with short-lived owner access; Scientist no longer generates duplicate analysis PDFs. Each bot also has coach-written personality and working phrases
• MCP write receipts retain the submitted change arguments and a readable action summary; these can include client information, separately from content-free usage and authorization metadata
• For authorized team client work: the acting coach, client, owning coach, shared team, operation, and outcome identifiers used to check access and prevent a retried change from running twice

Controller: the Coach (we process on their behalf) · Sources: Generated when a coach or client uses an AI-assisted feature; Generated when a Launch Bot the coach configured runs on its schedule, or when the coach messages it directly; Received from an external AI client the coach authorises to use LaunchSite tools; Generated when an event or scheduled occurrence triggers a coach-enabled external Claude routine; Generated when a client asks their coach’s assistant a question; Generated after a check-in triggers an active Zyx automation configured by the coach; Retained from Ghost background analysis before the separate module hold; no new background analysis runs; Generated after a coach marks a check-in reviewed or sends the review, while the account owner has Runway automatic suggestions turned on; Generated when a coach pastes a Loom or Tella transcript or written reply into a week, or asks for a week plan draft, in Runway or through their own assistant; Generated when a coach asks Runway to find decisions in a 1:1 call, opens Runway Metrics or scores past check-ins for a written question they chose, or generates a check-in Briefing; Generated when a client submits or edits a check-in that answers a written question their coach chose to score, while the coach has “Score new check-ins automatically” turned on (the default)

Community moderation reports, flags and personal blocks · sensitive

• A report one member makes about another member’s post or comment, including the reason they chose and anything they wrote
• An automatic flag raised by reading a member-written post or comment - the reason, a confidence score, and one sentence describing the concern
• Whether a coach dismissed the flag, hid the content, or restricted an ability, and when
• A member’s private choice to block another member in a community, including the two account identifiers and when the block was saved

Controller: the Coach (we process on their behalf) · Sources: Submitted by a community member using the report control; Saved by a member using the block or unblock control; Generated by automatically reading posts and comments that members write in a community

Participation and activity records in a group space

• Welcome-video selection and initial activation time, plus a legacy client/coach dismissal timestamp retained for released-client compatibility. The current video appears in intake forms and email links, with no Home card. Intake playback does not record viewing or completion tracking or dismissal. Legacy dismissal is separate from product-tour completion and is not viewing or completion tracking. Replacing or clearing the video retains existing dismissals; deleting the related client profile or coach profile removes them.
• Which steps of a coach’s Start-here sequence a member has marked done, and when
• When a member was last active in the app, shown to their coach as a quiet-member reading
• Counts of a member’s posts and comments in one space, used to rank that space’s leaderboard
• How many days after joining a space a post becomes visible to that member

Controller: the Coach (we process on their behalf) · Sources: Directly from the member as they use the space; Automatically, as you use the platform

Public AI demo requests · sensitive

• The sentence a visitor types into the assistant demo on our marketing site - typically a calorie or macro target, a diet, an allergy or a food they avoid
• The one-day meal plan the assistant returns to them
• A one-way hash of the visitor’s IP address, with a count and a timestamp, used to hold each network to three free builds a day

Controller: LaunchSite OS · Sources: Typed by a visitor into the demo on our public marketing site, with no account and no sign-in

Usage, device, and diagnostic data

• Log data, IP address, browser and device type, and actions taken in the app
• Error reports, scrubbed of request bodies, cookies, and personal data
• Production monitor findings: aggregate event and affected-user counts, code locations, redacted route templates, release commits and issue identifiers, with raw error text and personal details omitted; for root-cause deduplication, two SHA-256 fingerprint hashes per finding (of its culprit and top stack frame, or of its normalized message, or of a query module and database error code), stored as hashes only, containing no personal data and kept as long as the finding
• Daily detector evidence: route latency and failure aggregates, opaque database query and index references and counters, workflow run identifiers, test fingerprint hashes, dependency advisory counts, job timing and outcome counts, backup age and byte size, and signed workflow receipt hashes
• Postgres failure scans: SQLSTATE codes, closed diagnostic categories, schema object names, operation and role classes, severity, aggregate counts, first and last occurrence times, scan windows and opaque statement fingerprints. Raw SQL, errors, contexts and row details are processed transiently in the protected GitHub workflow and excluded from saved receipts and T3 task briefs
• Database monitor evidence about the platform's own schema, never row data: database advisor lint codes, levels, categories, schema object names (functions, tables, policies, indexes) and Supabase remediation links with cache-key hashes; for slow statements, normalized query text with every literal value and comment redacted and the database role that ran it; and database size, connection, cache, dead-row and replication-slot aggregates with the role and application name of long-running or idle sessions
• Push notification tokens for the web and mobile apps
• Account-linked random mobile installation identifiers, app identity, platform, native version and build, runtime, running and downloaded update identifiers, and last report time, used to confirm delivery of repairs without notification permission
• Audit records of privileged actions inside a workspace
• MCP connection activity, tool name, affected record identifiers, change state, timing, outcome, and usage units without raw prompts or complete tool results

Controller: LaunchSite OS · Sources: Automatically, as you use the platform

Optional public-site advertising measurement · optional

• Your allow-or-decline measurement choice and when you made it, stored in your browser
• After you allow measurement: advertising click and cookie identifiers, the selected public page path, and browser, device, and network information including the IP address Google receives with a request
• A confirmed new coach signup or first paid platform subscription, with a receipt identifier to avoid duplicate counting and, for a paid subscription, its amount and currency
• No names, email addresses, form contents, client records, health information, private workspace paths, URL query strings, or page referrers are included in our measurement events

Controller: LaunchSite OS · Sources: Your browser choice; Consented visits to selected public marketing and signup pages on launchsite-os.com; Confirmed platform signup and payment results

Workforce and employment records (LaunchPoint ERP) · optional

• Employee name, preferred name, work email, phone, employment type, and hire and end dates
• Assigned work sites, shifts, clock-in and clock-out records, and approved hours
• Pay rates and labor cost, visible only to those the account owner has granted access
• Job title, department, reporting line, team membership, and a written description of the role
• A sign-in account for an employee, where the account owner chooses to issue one
• Explicit gym module and location permissions, including the administrator who changed them

Controller: the Coach (we process on their behalf) · Sources: Entered by the account owner or an authorised administrator; Recorded by the employee at a time-clock device

Building access records (LaunchPoint ERP) · optional

• A door credential - a fob or card serial, a phone token, or a door PIN, each stored only as a one-way hash
• Which door was used, at which site, and the exact time it was used
• Whether entry was allowed or refused, and the reason it was refused
• Attempts by a credential that is not recognised, recorded without a name because there is none
• Whether anybody was rostered on at the time

Controller: the Coach (we process on their behalf) · Sources: Issued by the account owner or an authorised administrator; Recorded by a door reader when a credential is presented

Children and collection records (LaunchPoint ERP) · sensitive · optional

• A child’s name and date of birth, held so the room’s supervision ratio can be computed
• Which member is the child’s guardian
• The adults that guardian has authorised to collect the child, with a relationship and phone number
• Each check-in and check-out: the time, who handed the child over, and who collected them
• A written reason where a child was released to somebody not on the authorised list

Controller: the Coach (we process on their behalf) · Sources: Entered by the account owner or their staff from what the guardian tells them at the desk

Bank statement records (LaunchPoint ERP) · optional

• A name for a bank account, the bank it is held at, and the last four digits of its number - never the full number
• Imported statement lines: the date, the amount, and the description the bank wrote, which often names the counterparty
• Which line was matched to which bill, expense or ledger entry, by whom, and when
• Which months the account owner has closed, and when a closed month was reopened

Controller: the Coach (we process on their behalf) · Sources: A statement file the account owner exports from their own bank and imports themselves

Business identity for a white-label app listing · sensitive · optional

• Whether the app will use an existing Individual membership, an existing Organization membership, or a new Organization enrollment
• The coach’s registered legal entity name, business address, business phone and business email
• Their Employer Identification Number (EIN), and their D-U-N-S number where they already have one
• The outcome they report from Apple’s D-U-N-S lookup, including whether they requested a number, were asked for more information, or need LaunchSite guidance
• The name and title of the person with authority to sign for the business
• The store listing they write, their brand colours, and the logo and store artwork they upload
• Their answers to the intake’s yes/no permissions, their typed electronic signature, the time it was signed, and which version of the wording they signed
• Business paperwork they choose to attach, such as an LLC or incorporation certificate
• A government photo ID, ONLY where a store or Dun & Bradstreet specifically asks for one - never requested by default, and optional in the form
• The App Store Connect issuer ID, key ID and private .p8 API key used to provision the coach organization’s app; the private key is stored in Azure Key Vault, while the application database keeps only its opaque versioned vault reference

Controller: the Coach (we process on their behalf) · Sources: Entered by the coach themselves through authenticated App Setup in their LaunchSite account; Provided once by a platform administrator after the coach organization grants the named App Store Connect access needed to manage its app

Paired browser extensions · optional

• A pairing code, stored only as a SHA-256 hash and valid for five minutes and one use
• A per-browser access token, stored only as a SHA-256 hash - the readable value exists once, in the browser that paired, and is never recoverable afterwards
• A label the extension reports so you can tell your browsers apart, such as “Chrome on Windows”
• When each browser was paired, when it last called us, and when it was revoked

Controller: LaunchSite OS · Sources: Created by you when you generate a pairing code in Settings; Reported by the extension itself when it pairs

Pages and optional screen images Co-Work uses · sensitive · optional

• Your spoken or typed instruction for the browser session
• A text description of visible page controls, their labels and field values
• When you enable screen sharing: still images of the connected tab’s visible viewport, which may include client health information or imagery
• The page address and the sites allowed for this session
• Session history recording the instruction, step kinds, element references and outcomes

Controller: LaunchSite OS · Sources: The browser tab you connect to Co-Work, only while your session is running; When Co-Work is paired, voice requests to build or edit work in the app use browser control by default; requesting background work uses the workspace tools instead; LaunchSite and at most one additional site you explicitly allow for that session; Screen images require the extension’s screen-sharing choice and browser permission; password, payment, one-time-code and marked private controls, and opaque frames, are masked

Recorded demonstrations of a coach’s own workflow · sensitive · optional

• The kind of each interaction - click, typing, selection, submission, navigation - in the order it happened, with the time it happened
• The identifier a control carries in our own interface and its accessible role; where a control has no such identifier, the visible name on it instead, which for a step that opens a client record is that client’s name
• The page path each step happened on, which for a client page identifies that client’s record and the part of it that was open
• For typing and selection, only whether the field was left empty, given text, or had an option chosen - never the characters entered
• The written instructions and tool list the recording is compiled into and saved on the Launch Bot

Controller: LaunchSite OS · Sources: The coach, demonstrating a workflow in their own LaunchSite workspace while the paired Co-Work extension records it

Records brought across from a coach’s previous platform · sensitive · optional

• Client names, email addresses, phone numbers and status, as the previous platform recorded them
• Programme, workout and exercise names and their contents
• Other coaching fields that platform returned alongside those records in a captured JSON response, after authentication and account-recovery fields are removed
• Visible text from an HTML table the coach explicitly selects and previews, excluding hidden/private content, form controls, button labels and images
• Loaded Kahunas client conversation text and its associated sender and timestamp metadata, explicitly previewed and saved by the coach for AI onboarding, tied to the client profile linked in the conversation header. Alternatively, text the coach highlights on a client profile, including selected names and dates. Private data, hidden message text, editing controls, unrelated content and media are excluded
• During a coach-started Kahunas browse run, the assigned Nutrition preview: plan, day, meal and food names, displayed macros, and portions from read-only quantity controls across loaded day and meal tabs. Editable inputs, hidden controls, private elements, images and unrelated page contents are excluded
• During the same coach-started browse run, assigned supplement plans and their displayed dosage, timing and notes; assigned workout programs and their loaded days, exercises, sets, repetitions and source details; and the selected daily-habit form identity with the completion-question labels from its matching read-only template preview. The habit labels are assigned tasks, not historical completions, ratings or measurements. Client settings are read without changing values or submitting the form; unassigned library templates are not copied onto clients
• Where a coach opens their check-in or progress history on the old platform, whatever that page returned about their clients - which can include weights, measurements and notes about symptoms or wellbeing
• NEVER an image. Capture reads JSON responses, explicitly selected table text, coach-previewed client history text, or scoped assigned-plan previews during a coach-started browse run, so progress photo contents are not captured, transmitted or stored
• A Weekly History file (CSV) the coach uploads on Data Upload: per client and week, goal and phase labels, target weights, travel week marks, weekly notes, decisions and follow-ups, matched to existing clients by email or name

Controller: the Coach (we process on their behalf) · Sources: Read from the coach’s own account on their previous platform, by the LaunchSite Sync browser extension, using the session already open in that browser; A Weekly History file the coach exports from their previous platform or spreadsheet and uploads on Data Upload; the file is read in the coach’s browser and only its rows are sent; Passwords, authentication tokens, cookies, CSRF values and account-recovery fields are removed in the browser before upload and checked again at LaunchSite intake; stored source addresses omit query strings and fragments; LaunchSite never contacts that platform itself

Business phone messages, calls and usage billing

• Provide business-specific phone service, route authorized SMS replies and explicitly enabled agents, and support human takeover
• Submit explicitly approved business sender details to Twilio for identity and carrier review, show status and reconcile original registration fees
• Prevent duplicate provider actions, enforce recorded permission and recipient time windows, reconcile reported usage and bill the authorized business payer

Legal basis: Processing on business instructions and the appropriate recipient permissions. The business determines the applicable lawful basis for outreach and must not use phone agents for protected healthcare processing.

Manually recorded internal product feedback

• Keep and search private product feedback, calculate actual per-product summaries, and permit revision-checked editing and deletion

Legal basis: Processing under the coach instructions. The coach determines the appropriate basis for recording customer feedback; free text may contain sensitive information despite guidance to omit it.

Mobile app update availability

• Offer an optional update to the correct app when its store makes one available
• Remember Later for seven days without interrupting a workout or form

Legal basis: Legitimate interests in maintaining app reliability and offering compatible software updates.

Network membership, learning paths and imports

• Organize shelf templates and allow members to browse authorized folders. At the owning coach request, Juno may read owned folder names, descriptions and listing placement through the existing configured provider; folder writes remain manual
• Create an invited learning account only after email-bound invitation verification, without enrolling the person in coaching, marketing or optional AI; public browsing does not enable public account creation or joining
• Organize existing courses and cohort schedules without changing content permissions
• Answer paid client questions from currently authorized coach material, respecting course locks and live knowledge assignments; optionally transcribe owner-selected uploaded course recordings through the configured AI provider
• Prepare pending invitations or private unpublished course drafts, not automatic messages or publication
• Show actual Network growth and activity; preview launch readiness using synthetic member data
• At the owning coach request, let Juno discuss authorized aggregate reports, course and cohort labels, synthetic checks and membership terms, or propose an explicitly confirmed unpublished plan draft. Those growth tools exclude invitation email lists and secrets, imported source files, cohort member identities and raw payment-provider identifiers

Legal basis: Art. 6(1)(b) requested membership and learning services; coach instructions and required permissions for uploaded material that may contain sensitive data. Imports must not include unnecessary private health records.

Optional AI network setup

• Draft a network identity and original artwork from selected references
• Create a reviewed network and unpublished courses with private text lessons, without enrollment or automatic publication

Legal basis: Requested optional AI processing under the coach instructions and recorded AI permission. Coaches are instructed not to include private member or client records; uploaded free text may nevertheless contain sensitive information.

Platform support messages and engineering review

• Receive and investigate support requests
• Measure reviewed classification quality and operator effort without automatically changing classifier settings
• Notify platform staff and retain prior engineering decisions and code changes
• Preserve historical engineering evidence and unfinished source-code work for operator review
• Start ordinary coding tasks from eligible support requests and sanitized monitoring findings in an operator-configured local T3 project
• Tell a requester once, in the platform inbox or support chat conversation they used, that the fix for their request reached production, when an administrator enables it
• Let mapped platform administrators review retained case evidence, plans and repository references, including community Discord cases whose participants have no LaunchSite account

Legal basis: Providing requested support and operating the service. A lawful basis and any applicable sensitive-data condition must be established before enabling external processing of sensitive support correspondence.

Managed app fulfillment status and operator planning

• Track a purchased branded app from intake through provisioning, store review and maintenance
• Identify missing requirements, prepare operator actions and report recorded progress without exposing business documents or provider credentials

Legal basis: Performance of the purchased managed-app service and legitimate interests in coordinating its delivery. Provider account terms and the applicable processing basis require review before enabling the operator integration.

Optional WordPress hosting and Shopify catalog connections

• Provision a separate WordPress environment and report its readiness
• Let coaches copy Shopify product links into their pages and funnels while checkout, orders and customers remain with Shopify

Legal basis: Performance of the coach-requested service and processing on the coach’s instructions.

Coach-controlled hosted WordPress content

• Operate the coach’s requested WordPress website and maintain its infrastructure backups

Legal basis: Processing on the coach’s instructions. The coach determines the lawful basis for hosted website content and any applicable Article 9 condition before collecting health information. Hosting does not change the platform’s wellness-only restrictions.

Optional Fullscript plans, resources and practice connection

• Show confirmed released assignments and their exact directions inside the client app; reconcile provider changes and optionally notify the client of an update
• Open the official Fullscript practitioner editor with a short-lived session grant and the verified matched patient; Fullscript controls supported authoring and retains checkout and fulfillment
• Fetch current assigned attachments through authenticated, bounded downloads without saving attachment URLs or file copies; expose only supported content and explain unavailable resources
• Create an optional logging checklist only after the coach manually enters and confirms its timing. Importing or purchasing never marks a dose taken
• Create a Fullscript patient only after the coach reviews first name, last name and email and explicitly confirms; welcome email is suppressed and patient matching requires a separate confirmation

Legal basis: Coach-directed processing under the applicable service agreement; the coach must establish a lawful basis and an applicable Article 9 condition before using identifiable health information. Developer sandbox access does not establish production permission.

Private client workspace and optional AI

• Provide the same private Zyx workspace to independent subscribers and coach-sponsored clients, with separate coach-controlled nutrition and training self-management permissions and numeric limits; other personal plan types retain their existing Self build permission
• Generate requested personal drafts and reviewed revisions, educational lab explanations, a daily brief, explicitly requested optional weekly reviews, and short notes from recurring checks the client wrote in HEARTBEAT.md
• Let the client personalize presentation, control memory and brief delivery, retrieve authorized knowledge, review plan activation, export saved material, and choose what to share

Legal basis: Requested account services and separately recorded permission for optional AI and calendar processing; applicable sensitive-data conditions require counsel review.

Public research for coaching briefs

• Find and cite relevant published research alongside an existing verified lab review

Legal basis: Processed on the coach’s documented instructions for their requested research feature.

Public reference research for the client companion

• Explain general coaching topics with cited public evidence alongside authorized personal or coach material

Legal basis: Requested optional companion research using public reference material; this category excludes private client search content.

Connected mailbox correspondence

• Let the mailbox owner read, search, compose, save drafts, reply, archive, flag or star, and mark messages read inside CRM Conversations or their own OS Messages Email tab
• On an explicit coach request, send a bounded selected email transcript to the configured AI provider to produce a reviewable reply draft; no automatic saving or sending
• Show matched correspondence on the existing CRM lead timeline for coach review
• CRM Jev email analysis is unavailable while its separate OS module is coming soon
• CRM Ghost background analysis is unavailable while its separate OS module is coming soon
• Honor opt-out requests; synchronized mail does not trigger reply workflows or assigned AI agents without a supported trusted sender-verification source

Legal basis: Processed on the coach’s documented instructions; the coach determines the applicable basis and any additional condition required for sensitive correspondence.

Historical chart tables and saved charts

• Retain existing client records from the retired Charts workspace; its imports, saved snapshots, sharing and access remain unavailable. Current MCP chart rendering uses the original coaching records, not these historical chart stores

Legal basis: Art. 6(1)(b) with Art. 9(2)(a) explicit consent obtained by the Coach where the selected data concerns health

Optional public AI demonstration

• Generate the requested fictional example with the disclosed AI provider
• Limit abuse of the free demonstration

Legal basis: The visitor’s requested demonstration and legitimate interests in preventing abuse

Shared barcode food database and food photos

• Answer a barcode scan from public reference datasets, earlier scans and community additions, and show the client the food to confirm before it is logged
• Check community additions before they are shared, and set aside an addition that several different people report as wrong so the next person can add it correctly
• Read the foods in a meal photo or the numbers on a nutrition label with the disclosed AI provider, and show the result to the client to check and edit; nothing read from a photo is saved until the client confirms it
• Measure lookup speed, how often a product is found, and provider outages

Legal basis: Art. 6(1)(b) performance of the service the client asked for (finding and logging a food), and Art. 6(1)(f) legitimate interests in keeping a shared food database accurate

Privacy requests, permissions, and review records

• Handle privacy rights and eligibility reviews
• Preserve accurate evidence without inventing past permissions
• Record the displayed disclosure version separately for independent accounts and coaching relationships
• Apply documented processing restrictions and track unresolved requests

Legal basis: Applicable legal obligations and legitimate interests in handling rights and security requests; permission evidence records the asserted basis rather than creating one

Account erasure work and completion evidence

• Remove active account data and files reliably
• Track provider work, shared records, backups, versions and retained exceptions separately
• Retry incomplete work and prevent reintroduction after restoration

Legal basis: Applicable deletion obligations and legitimate interests in completing and documenting requested erasure

Coach-client agreement drafts and signed evidence

• Send explicitly enabled agreement notices using current email permission checks and retain truthful provider acceptance and retry evidence
• Give coach and client the same finalized agreement
• Prevent later edits from changing signed evidence
• Record amendment, void and reviewed erasure decisions

Legal basis: Performance of the coaching agreement and applicable recordkeeping or dispute purposes; any health content requires an applicable special-category condition

Coach agreement acceptance records

• Record which platform agreements a coach accepted
• Provide copies and investigate agreement disputes

Legal basis: Art. 6(1)(b) contract; Art. 6(1)(f) legitimate interests in keeping evidence of agreements and resolving disputes.

Coaching template creation and editing attribution

• Show who created and last edited a template to people already authorized to view it

Legal basis: Performance of the requested coaching service and processing on the coach instructions.

Gym staff record access scope

• Restrict coaching records and sessions to current assignments inside already authorized sites
• Keep separately authorized tagged-thread collaboration and read-only site conversation oversight distinct from general record access

Legal basis: Performance of the requested gym service and processing on the gym instructions.

Gym site coaching template publications

• Share reusable coaching content with currently authorized staff at selected gym sites without sharing private client programs or changing global team-library access

Legal basis: Performance of the requested gym service and processing on the gym instructions.

Gym staff revenue attribution reviews

• Report reviewed staff revenue and unallocated amounts without changing journal entries, collecting payments or running payroll
• Retain earlier reviews and reject stale edits

Legal basis: Performance of the requested gym service and processing on the gym instructions.

Gym member menu preferences

• Configure the gym member menus on web and updated mobile apps without deleting member records or changing destination permissions
• Reject stale edits and audit changes to the shared configuration

Legal basis: Performance of the requested gym service and processing on the gym instructions.

Gym membership import source and reconciliation records

• Match imported agreements to the existing member book, refuse repeated agreements, show recent confirmed imports and investigate reconciliation problems without replaying charges or issuing credits

Legal basis: Performance of the requested membership service and processing on the gym instructions.

Gym historical migration and opening balances

• Preserve readable source history, reconcile repeated imports and opening balances, and distinguish historical evidence from live payments
• Activate reviewed opening session packs or supported signed-waiver evidence only after a separate owner reconciliation

Legal basis: Processing on the gym instructions for the requested service, with the separate consent or other reviewed condition required for any imported health information.

Gym provider consent and connection provenance

• Keep shared CRM records separate from personal credentials after ownership changes
• Permit only the current owner-authorized email, social and marketing connections and reject obsolete credentials or replayed connection intents

Legal basis: Performance of the requested integration and processing on the gym instructions.

Gym Google Calendar authorization and event provenance

• Use the owner-authorized Google connection for gym availability and new appointments
• Refuse former-owner credentials, stale authorizations and attempts to mutate old events through a replacement connection

Legal basis: Performance of the requested calendar integration and processing on the gym instructions.

Gym class bookings, service credit eligibility and waitlist notifications

• Allocate class places and bounded waitlists, prevent conflicting or unpaid automatic promotions, restore the original charged credit after an eligible cancellation and tell a promoted member in their private inbox
• Show the authenticated member their own web/mobile timetable, original-date credit history and standing preferences; share explicitly published class instructions without copying staff-only plans

Legal basis: Performance of the requested membership service and processing on the gym instructions.

Shared gym operational notes, tasks and class boards

• Coordinate service on the canonical contact before and after membership with current employment, module and location access
• Notify only authorized colleagues and retain an attributable history; publish class instructions only when the gym owner chooses

Legal basis: Performance of the requested gym service and processing on the gym instructions.

Account and profile information

• Configure bookable availability and reconcile an explicitly submitted schedule creation after an uncertain response without silently creating another schedule
• Create and secure your account
• Show a coach-selected Fullscript storefront link to that coach’s clients. Opening the public link suppresses the web referrer. Optional authorized account linking and supplement history are described separately under Fullscript connection data
• Display an optional illustrated profile identity. Character image addresses contain appearance options without account identifiers and render without authentication; uploaded profile photos remain in private storage
• Authenticate you and enforce role-based access
• Send service, security, and account notices
• Keep a client’s contact details, date of birth, gender, preferred language and postal address on the client profile their coach manages
• Let teammates browse and copy resources that a coach shares with their team; separately copy selected starter-kit resources and settings into a new coach’s account once. Personal copies remain independent after onboarding. Practice branding, support email and practice address stay synchronized only when organization management is enabled for that asset
• Restore an unfinished coach invitation on the same device after navigation or reload
• Display a participant’s name and existing profile picture alongside their score in the Performance League, subject to their League participation setting and the viewer’s access to the same coach roster or community; client-facing views also require the roster coach and community owner to enable client League visibility. Coach standings retain their existing access rules
• Show a coach to other coaches in the coach directory, but only if that coach has switched their listing on - their name, photo, headline, region and specialities, and never their clients, roster size, revenue or plan

Legal basis: Art. 6(1)(b) performance of a contract; Art. 6(1)(f) legitimate interests in securing the service

Client wellness and health-related records

• Operate the coaching workspace and the client portal
• Keep client-created food labels and recipes available for later meal logging; saving through My foods, meals, recipes or favorites does not publish them to the community food database
• Produce coaching outputs: grades, programs, summaries, reminders, progress tracking
• Provide coach-selected learning materials to authorized viewers and record lesson completion
• Enable coach-to-client communication
• Keep coach-only records of who created or last updated assigned plans and who requested lab analysis
• Support Shared coaching: a client’s primary coach or an authorized team admin selects teammates, their responsibilities and client-specific permissions; the platform synchronizes a group conversation containing the client and selected coaches. Removing a collaborator ends that shared-coaching grant and group access, while independent team permissions and retained records remain in place
• Answer the client’s own questions about their plan and their own records, where their coach has enabled the assistant
• Show a coach Runway, a week-by-week view of each client (plan, goal, phase, target weight and weekly rate of change, travel weeks, weekly averages of the client’s own logged measurements, decisions and follow-ups due), computed on our servers from records that coach can already open. Runway records are visible to the client’s coach, their managing coach, teammates in the owning coach’s team and shared-coaching collaborators, never to the client; weekly averages of daily logs, meals and wearable data are withheld from every coach other than the owning coach and the client’s managing coach
• Let a coach set a phase, goal, target weight or travel mark on a block of planned or past weeks at once, and apply a week plan draft after reviewing and editing it; nothing in a draft reaches the client’s weeks until the coach applies it
• Chart every metric a coach tracks for a client in Runway Metrics, including AI scores of written answers the coach set up, and let the coach search their own Runway records (decisions, week notes, goal and phase labels and saved replies) for the clients they can already open
• Prepare a coach-only Briefing and Checklist for a check-in review. A checklist item becomes a Runway follow-up only when the coach saves it; nothing in a Briefing or Checklist is shown or sent to the client
• Show a coach whether a confirmed Runway decision worked: the client’s weekly weight rate and the watched metrics before the decision and 2 and 4 weeks after it, computed inside the app from the same Runway and Metrics records each time it is opened, with no AI and nothing stored

Legal basis: Art. 6(1)(b) performance of the coaching contract, with Art. 9(2)(a) explicit consent for health data obtained by the Coach as controller

Pre-participation health screening

• Establish whether a client should speak to a doctor before starting physical activity
• Require a coach to review a flagged answer before that client books a class themselves
• Give the business a record of who has been screened and who has not

Legal basis: Art. 6(1)(b) performance of the coaching contract, with Art. 9(2)(a) explicit consent for health data obtained by the Coach as controller

Lab files and extracted markers

• Extract report text, confidence, and table or row locations so a coach can verify marker facts against the uploaded source
• Let platform administrators inspect transient lab OCR, extracted marker facts, and assembled analysis prompts with platform reference retrieval
• Produce lab summaries and overlays for coaching
• Track markers over time
• File an uploaded report against the right client and panel type

Legal basis: Art. 6(1)(b) with Art. 9(2)(a) explicit consent obtained by the Coach

Progress photos and movement video

• Visual progress tracking
• Coach form review and feedback
• When the coach enables it, send bounded current and previous check-in photos to the configured AI provider to draft approximate physique observations and comparisons for private coach review
• When the coach requests them through an AI client they connected through MCP, return resized copies of selected check-in progress photos to that external AI client for the coach’s visual progress review, only where the coach can already see the client’s photos and the client has not withdrawn permission for sharing with an external AI assistant

Legal basis: Art. 6(1)(b) with Art. 9(2)(a) explicit consent obtained by the Coach

Connected device and wearable metrics

• Show source-labeled trends to the client and their coach
• Inform coaching decisions
• Show imported workout history separately from exercise logs and let the client link a recording to assigned training without marking exercises complete
• Answer the owning coach’s questions using visible workout summaries through a read-only AI tool when wearable and AI processing permissions allow it
• Answer the client’s own questions when their coach has given them an AI assistant: their recent readings are included in the request sent to the AI provider so the answer reflects the week they actually had

Legal basis: Art. 6(1)(a) consent, with Art. 9(2)(a) explicit consent for health data

Messages and conversation content

• Deliver the message and show the conversation
• Run Network-owner activated workflows from membership joins, tier changes, lesson or whole-course completions, Going RSVPs and configured inactivity periods measured from LaunchSite-wide last activity. Store workflow definitions, event references, member identifiers, delayed-step checkpoints, enrollment grants and outcomes. Send in-app notifications only, honoring each recipient's Network automation preference; that preference does not cancel course enrollment actions. Enrollment retains existing content audiences and prerequisites. Previewing an audience sends nothing and writes no runs. Workflow definitions and run history have no automatic expiry and are removed when their automation, Network or associated account is deleted; delivered notifications follow existing notification retention. No external messaging provider receives this workflow data
• For an Instagram account connected directly through Meta, keep the conversation history Meta does not (it serves only the 20 most recent messages of a conversation) and apply Meta’s reply rules: a business cannot message a person first, replies are sent within 24 hours of the person’s last message (up to 7 days for a conversation started from a click-to-message ad), and only a coach, never an automation or AI agent, may reply up to 7 days later using Meta’s Human Agent tag
• Identify a community using the logo its owner chooses. Replaced or removed logos stop accepting new reads and their active storage copies are scheduled for deletion; storage recovery controls can retain deleted copies for up to approximately 37 additional days
• Show an owner-approved public network catalog while keeping admission invitation-only; public browsing does not permit joining, access requests or account creation. Existing memberships remain, and invitations are separate from marketing consent and paid course access
• Identify communities and courses using owner-selected covers under the same replacement and storage-recovery policy as logos. Let members edit or clear their own public-to-their-communities bio without changing their private coaching information
• Run coach-configured CRM replies on the chosen connected account, match replies to the same conversation, prevent duplicate processing, and pause automated replies for human handoff or opt-out; when the coach explicitly enables it, an unmatched inbound sender creates a CRM contact and lead
• CRM Jev conversation analysis is unavailable while its separate OS module is coming soon
• Show a community post and its comments - whoever wrote them - to the other members of that community, including any coach the room’s owner has invited into it
• Prove consent and honour unsubscribe, spam complaint, chat "stop" and quiet-hours rules
• Detect and prevent abuse of the messaging channels

Legal basis: Art. 6(1)(b) performance of a contract; Art. 6(1)(c) legal obligation for consent and opt-out records

Voice input, call recordings, transcripts, and synthetic voice

• Help the coach review and improve their own calls
• Produce audio playback of written content
• Turn what the coach said into the text of their request

Legal basis: Art. 6(1)(a) consent of every party to the call, obtained by the Coach; Art. 6(1)(f) legitimate interests in the coach’s own performance review

Prospect, lead, and CRM contact information

• Run the coach’s pipeline
• Attribute which campaign produced a lead
• Research and qualify coach-requested prospects
• Prepare coach-reviewed CRM imports
• Preserve historical CRM classifications for retention, export and erasure; Jev analysis and Jev workflow conditions are held
• Estimate defined future outcomes only after recorded history passes validation checks
• Preserve historical Ghost results under existing retention and subject-rights rules while the module is unavailable
• CRM Ghost background analysis is unavailable while its separate OS module is coming soon
• Retain historical 30-day and 90-day Ghost projections while new capture and projection access are unavailable
• Automatically add newly sourced Growth Huddle candidates to the coach’s CRM
• Follow up with the person

Legal basis: Art. 6(1)(f) legitimate interests of the Coach in managing their own business enquiries; Art. 6(1)(a) consent where required for electronic marketing

LaunchSite OS business contacts and activity

• Manage LaunchSite OS business enquiries and follow-up in a shared CRM
• Route call invitations, booking changes and contact details to the authorized team member taking the call; notify the LaunchSite support inbox about new business bookings
• Keep business records available to authorized business owners and separate from their coaching records

Legal basis: Art. 6(1)(f) legitimate interests in managing business enquiries; Art. 6(1)(a) consent where required for electronic marketing

Subscription and payment information

• Take payment and manage subscriptions
• Verify gym membership payments and release the purchased sessions once, preserve original credit expiry, and reconcile the provider payment to the member contract
• Suspend coach product access for incomplete or past-due subscription payments and restore it after confirmed billing recovery
• When operators enable a dedicated private staff channel, notify them about supported LaunchSite coach-plan and managed-app trials, invoice payments/failures, cancellations, refunds and disputes; no AI processes these billing notifications
• Let coaches close unpaid payment links through Stripe and retain the canceled payment record in their transaction history
• Collect managed coach app setup fees and maintain the related monthly subscription
• Collect the separate CRM website-domain subscription and register, connect, renew through the registrar account, or suspend the purchased domain as the subscription lifecycle requires
• Pay out marketplace sellers
• Pay referral partners the commission they have earned, which means transmitting the PayPal address they gave us to PayPal in order to send that payment
• Let a coach charge for a consultation booked on their own booking page, and show them which bookings are paid
• Let coaches sell one-time payments, learner course access and course-plus-Network bundles through their connected Stripe account; verify payment before granting access and revoke only purchase-derived access after a full refund
• Let coaches sell recurring Network tiers and course access through their connected Stripe account, synchronize payment-backed access, provide billing management after access expires, and report gross collected amounts and recorded partial or full refunds separately by currency. Refunds alone do not cancel recurring billing; cancellation is a separate Stripe billing action
• When a coach selects a saved webhook endpoint, send signed payment-confirmed or payment-refunded events containing only order and offer identifiers, amount, currency and status. These payloads exclude buyer contact information, lesson content and health information; client external-sharing permission and account-erasure checks apply before delivery
• Deliver a reusable course copy to a coach buyer from the fixed submitted snapshot, without transferring learners or publishing the buyer course automatically
• Maintain a coach’s revenue ledger for payments received outside LaunchSite without sending a new charge to a payment processor
• Meet tax and accounting obligations

Legal basis: Art. 6(1)(b) performance of a contract; Art. 6(1)(c) legal obligation for tax and accounting records

Campaign and engagement records

• Show the coach whether a campaign delivered
• Store website images for draft editing and serve them publicly when referenced by published pages
• Let the coach review, download and reuse coordinated page, ad and email drafts without sending messages, buying ads or publishing content during kit creation
• Connect the business locations and marketing accounts the coach selects for their workspace
• Let the coach read business reviews, request an AI reply or explicitly enable automatic refresh and drafting for new public feedback, edit a saved draft, and explicitly approve its exact revision for publication to Google or Facebook
• Send eligible contacts and members a request for honest feedback, when the coach queues one or enables a future-event rule
• Publish the coach’s selected public reviews in a clearly labelled widget until the coach revokes it
• Compare observed email engagement between randomly assigned campaign variants
• Keep a returning browser on its assigned funnel variant and compare observed visitor-to-enquiry conversion between those variants
• Report provider spend alongside mapped CRM leads and recorded collection, keeping currencies separate and identifying incomplete data
• Import enquiries from the selected provider forms, preserve existing contact preferences, prevent duplicate imports and record the owner’s review before email follow-up
• Publish coach-approved social content at the selected time and reconcile provider-confirmed publishing outcomes
• Let authorized workspace readers load available top-level Facebook Page comments without replying, moderating or sending those comments to AI
• Create reviewed social drafts as one batch and reconcile an interrupted import without duplicating drafts or publishing them
• Suppress future sends to people who unsubscribed or complained
• Let a coach see who has already been contacted, so the same member is not approached twice
• Report how many contacted members returned to a class

Legal basis: Art. 6(1)(f) legitimate interests in measuring delivery; Art. 6(1)(c) legal obligation for suppression records

AI prompts, outputs, and workspace memory

• Produce the output that was requested
• Propose Runway decisions and follow-ups from what the coach wrote, said or pasted about a check-in or a week, for the coach to add, edit or dismiss. A proposal is a suggestion only: it changes no plan, is never shown to the client, and becomes a decision only when the coach adds it
• Propose a phase, goal and target weight for a client’s planned weeks as a draft the coach reviews, edits and applies or discards. A draft changes nothing until the coach applies it, and is never shown to the client
• Summarise a check-in for the coach’s review and propose checklist items, and propose a 1 to 10 score for a written answer the coach chose to track. Both are coach-only suggestions: a score is a chart value the coach can overwrite, and a checklist item becomes a follow-up only when the coach saves it
• Render a requested chart from authorized coaching records with bundled Flint and Vega software, without sending chart data to Microsoft or a separate chart service
• Keep AI features grounded in the coach’s own workspace
• Store coach-imported client notes and records, including pasted text and Google Sheets CSV exports, as private Library source files and client-scoped search embeddings for future AI answers. Imported content remains source evidence, not permission to perform actions
• Prepare private goal and plan reviews for a coach to edit, approve or skip before applying changes or sending a reply
• Revise an unsent review from the coach’s saved request, acknowledge saved feedback, refine scoped instructions, and let the coach compare follow-up observations without treating approval as proof of benefit
• Include applicable coach instructions directly in review context and use relevant feedback text to form a temporary knowledge-search query; feedback instructions are not stored as vectors or used to retrain a model
• Keep AI features grounded in records the acting coach is authorized to access, including eligible teammate-owned clients
• Answer a client’s own questions from the material their coach published, and from the parts of their own record they can already see in their portal
• Reconcile stored memories when newer information contradicts them
• Meter usage
• Monitor whether AI features are working correctly - speed, failures, and whether answers were grounded in the coach’s own material
• Let a coach use their own AI client to read eligible workspace data and make changes to it. A change takes effect as soon as the coach allows the action in that AI client - LaunchSite does not ask for a separate confirmation, and records every change in the coach’s activity history
• Apply current team permissions when a coach uses AI on a teammate's client. Client ownership stays with the owning coach; the connection, action attribution, and usage remain tied to the acting coach. Private message threads, protected files, and Brain sharing retain their separate access rules
• Read posts and comments written in a community to flag ones a coach may need to look at

Legal basis: Art. 6(1)(b) performance of a contract, inheriting the Art. 9 condition of the underlying record

Community moderation reports, flags and personal blocks

• Show a community’s coaches what may need their attention, so a room stays usable
• Let a coach see repeated incidents involving one member as a pattern rather than in isolation
• Record what a coach decided about a report
• Hide blocked members’ community content for the blocker and suppress notifications between them; the block list is only returned to the member who saved it

Legal basis: Art. 6(1)(f) legitimate interests in keeping a shared space safe, inheriting the Art. 9 condition of the underlying post

Participation and activity records in a group space

• Show a member where to start in a space
• Let a coach see who has disengaged, by name, so they can reach out
• Rank a space’s leaderboard among the members of that space only
• Release a coach’s material at the pace they set, counted from when each member joined

Legal basis: Art. 6(1)(b) performance of the coaching contract, and Art. 6(1)(f) legitimate interests in a group space that works

Public AI demo requests

• Build the day of meals that was asked for and show it back
• Limit each network to three free builds a day, so the demo cannot be used to run up AI costs

Legal basis: Art. 6(1)(f) legitimate interests in demonstrating the product and protecting it from abuse, with Art. 9(2)(e) where a visitor chooses to make health details about themselves public by typing them into a demo on an open web page

Usage, device, and diagnostic data

• Keep the service secure and reliable
• Diagnose faults
• Deliver notifications you asked for
• Investigate abuse

Legal basis: Art. 6(1)(f) legitimate interests in the security, integrity, and reliability of the service

Optional public-site advertising measurement

• Remember and honour your measurement choice
• Understand whether our advertisements lead to visits, coach signups, and paid subscriptions
• Avoid counting the same confirmed conversion more than once

Legal basis: Art. 6(1)(a) consent for optional measurement; Art. 6(1)(f) legitimate interests in remembering and honouring your privacy choice

Workforce and employment records (LaunchPoint ERP)

• Operate the employer’s rota, timesheet, and labor-cost reporting
• Show the organization’s structure - who works where and who reports to whom
• Authenticate an employee and enforce the organization and location permissions for their work
• Keep an audit record of changes to employment, access, and approved hours
• Export approved closed payroll hours for the employer to review and map to their payroll provider, without submitting payroll or transmitting tax identity through this export

Legal basis: Art. 6(1)(b) performance of the employment relationship and Art. 6(1)(f) legitimate interests of the employer in operating and staffing the business, in each case with the employer as controller

Building access records (LaunchPoint ERP)

• Decide whether a member or employee may enter the building at that moment
• Answer who was in the building after an incident, an injury, or a theft
• Show the account owner which entries happened while nobody was on shift

Legal basis: Art. 6(1)(b) performance of the membership or employment relationship for entry itself, and Art. 6(1)(f) legitimate interests of the operator in the security of their premises and the safety of the people in them, with the operator as controller

Children and collection records (LaunchPoint ERP)

• Make sure a child is only released to an adult their guardian authorised
• Keep the room within its staff-to-child supervision ratio
• Answer who had a child, and when, after an incident or a dispute

Legal basis: Art. 6(1)(f) legitimate interests of the operator and, decisively, of the child in being released only to an authorised adult - an interest that a child cannot assert for themselves, which is why the guardian supplies the record and the operator is controller. Art. 6(1)(c) legal obligation where local childcare regulation requires an attendance and collection register. No Art. 9 processing: no health data about a child is collected.

Bank statement records (LaunchPoint ERP)

• Check the business’s own books against its bank statement
• Show what moved on the bank with no record behind it, and what was recorded and never settled
• Produce a general journal and trial balance the account owner can give to their accountant

Legal basis: Art. 6(1)(f) legitimate interests of the business in keeping accurate books, and Art. 6(1)(c) legal obligation where accounting and tax law requires records to be reconciled and retained, with the account owner as controller

Business identity for a white-label app listing

• Prepare the business details for Apple’s official D-U-N-S lookup, track the outcome the coach reports, and guide the coach when they ask for help
• Enrol the business in the Apple Developer Program and publish their branded app under their own account, as Apple’s guideline 4.2.6 requires
• Publish their Google Play listing and build their app with their own branding
• Create and reconcile the Expo project, Apple bundle identifier, app capabilities, build credentials and store connection through supported provider APIs

Legal basis: Art. 6(1)(b) performance of the contract to build and publish the coach’s branded app, since Apple and Google will not issue a developer account or accept a listing without this information. The electronic signature and the permissions recorded alongside it are also relied on under Art. 6(1)(f) legitimate interests in being able to evidence what the business authorised

Paired browser extensions

• Let an extension you installed reach your own LaunchSite account without holding your password
• Show you every browser that can currently reach your account, so you can revoke one you do not recognise
• Tell you when each browser was last active, so the revoke list means something

Legal basis: Art. 6(1)(b) performance of a contract, since the pairing is what makes an extension you chose to install able to work with your account; Art. 6(1)(f) legitimate interests in securing accounts, for the activity and revocation record

Pages and optional screen images Co-Work uses

• Understand the visible page and choose the next step toward your request
• Describe proposed browser actions and their observed outcomes
• Show you the session’s progress and outcome

Legal basis: Art. 6(1)(b) performance of a contract; where visible content includes health data, processed on the coach’s instructions under the applicable health-data consent basis

Recorded demonstrations of a coach’s own workflow

• Turn the demonstration into a Launch Bot’s written instructions and tool list, so the bot can do the same job later on a schedule, on a server, with no browser involved
• Show the coach the steps that were recorded, so they can correct or discard them before the bot is changed

Legal basis: Art. 6(1)(b) performance of a contract, since the recording is how the coach configures a bot they asked for; where a step names a client or their record, processed on the coach’s instructions under the applicable health-data consent basis

Records brought across from a coach’s previous platform

• Show the coach what was found so they can decide what to import
• Create the clients, contacts and programmes the coach chooses to bring across
• Extract client-linked plans and health history into a coach-reviewed onboarding draft using the configured AI provider
• Use captured client conversations as historical context in AI onboarding and its source preview. Capturing a transcript does not send messages or create a live conversation
• Let an import that mapped a field wrongly be explained and corrected afterwards
• Bring a coach’s past weeks into Runway, show a preview before anything is written, and let the coach undo a Weekly History import

Legal basis: Art. 6(1)(b) performance of the contract with the coach, who is moving their own business records into the service; Art. 6(1)(f) legitimate interests of the coach and their clients in continuity of coaching when a coach changes platform. Where a capture includes health-related information about a client, the coach relies on Art. 9(2)(a) explicit consent obtained by them as the controller of that record, on the same basis as the wellness records they already hold in LaunchSite

Business SMS and AI phone calls

Destination: The contact selected by authorized staff or the person who called or texted the business, through its owned Twilio number. Phone audio also reaches OpenAI Realtime Mini.

How it is turned on: Provider setup, business sender readiness, billing and recipient permission checks are required. Staff explicitly send texts, assign and enable an SMS agent, or enable phone agents. An outbound call requires an explicit authorized request and separate recorded call permission. Human takeover pauses SMS agent replies.

What can be sent:

• SMS text, sender and recipient phone numbers, carrier routing metadata and delivery receipts
• Live phone audio, approved public business instructions and bounded phone-agent commands
• Business phone rental and usage references with amounts to Stripe for checkout and confirmed credit

What is never sent through it:

• A browser-chosen unrelated business sender or billing owner
• Private CRM record access based only on caller ID
• Automatic recording or stored call transcripts in the phone agent runtime

Content the Coach controls: People may put personal or health information in messages or speech. Public-information guidance does not guarantee that arbitrary caller or staff content is free of sensitive data.

Coach-owned Claude routines

Destination: The coach-selected Claude Code routine in the coach's Anthropic account, with any MCP connections the coach enables for that routine.

How it is turned on: The coach saves a routine trigger token and enables an event or scheduled automation with a Run Claude routine step. Each eligible event or scheduled occurrence can start an unattended session.

What can be sent:

• The launch sends a routine run identifier, trigger type, bound client identifier when available and optional coach-configured input. Input may include resolved client or event data.
• Through the normal authorized LaunchSite MCP connection, Claude can read eligible workspace records and perform permitted actions. Optional run context includes its originating event and, for intake events, the exact submitted questions and answers. These may include personal and health information. Current ownership and external AI sharing permission are checked.
• The routine follows the coach's saved instructions and enabled skills. It may report completion and optionally retain a private result or save a private coach note. An explicitly requested note for an unlinked intake is attached when its client profile is linked.

What is never sent through it:

• The routine trigger token is encrypted server-side and is never returned by connection or history APIs. Run history excludes input, event content, private results and credentials. The optional completion helper never publishes a result to the client.

Content the Coach controls: The normal LaunchSite connection exposes its permitted coaching tools, including writes, to the selected external routine. The coach controls its instructions, skills and selected connectors; unattended sessions can use those connectors without another LaunchSite confirmation. Other enabled connectors follow their own permissions. Claude subscription limits, charges, retention and account settings apply; LaunchSite cannot recall data already retrieved by that account. Existing intake-only connections retain their narrower permissions.

Internal platform billing alerts

Destination: A dedicated private Discord text channel selected by LaunchSite operators for billing staff.

How it is turned on: Off by default. An operator configures the channel, a separate signed Stripe notification destination and an explicit live/test mode. Routine alerts are silent; failed payments and disputes can mention the configured staff role.

What can be sent:

• Opaque account/purchase and payment-processor receipt identifiers, allowlisted coach-plan or managed-app labels, event status and times, amounts/currency and constructed Stripe Dashboard links
• Temporary delivery recovery markers and message receipts

What is never sent through it:

• Names, emails, billing addresses, card data, raw decline text, customer-authored descriptions or metadata, health content and full Stripe event payloads
• Connect account events, marketplace/coach-to-client payments, unknown product scopes and credentials

Platform support intake, classification, monitoring and local coding tasks

Destination: Operator-configured Discord channels, configured Azure vision inspection and optional example-based classification, and Jev classification. Separately enabled coding tasks go to the operator-controlled local T3 instance and its configured Codex or Claude Code account. The retired Cezar worker and cockpit no longer receive support evidence or create engineering sessions.

How it is turned on: Off by default. Platform administrators independently enable capture, Discord delivery, content transfer, classification and monitoring. Administrators may explicitly import existing inbox and support-chat history into the same private Discord conversations. Separately enabled community-channel scans read selected Discord messages and send actionable reports to private support threads, never replies to the source channel. Message text and authors cannot grant approvals or upgrade policy. Discord carries no administrator actions: support is decided in LaunchSite, and Discord buttons, forms and commands are refused without reading or changing anything. Classification uses Jev unless a server setting selects the Azure example-based classifier, which falls back to Jev on failure. A reply draft is never sent without an explicit administrator action on the exact message in its owned app conversation. The Cezar engineering pipeline and worker account management are retired. Retained Cezar approvals do not authorize this connector. A separate operator-enabled local T3 connector starts ordinary coding threads for eligible support tasks and sanitized monitoring findings, using the configured project, model account and repository instructions. It saves the thread reference after launch; launch does not establish resolution of the support issue. This connector creates no customer message or separate deployment authority. Two follow-throughs are separate, each off by default and enabled by a platform administrator. With fix-live notices on (release_notices_enabled), the support service itself sends one fixed-text message, once per request, into the platform inbox or support chat conversation of a customer request whose own fix reached production, as the administrator who enabled notices and with no per-message administrator action. With the release train on (release_train_enabled), a daily local T3 task prepares a production release pull request; it can merge that release and start the production deploy only after the owner approves it in the task's own thread.

What can be sent:

• The existing bounded task brief and canonical case/source links for eligible work sent through local T3 to its configured coding provider; launch and thread identifiers are retained separately from the task text
• Opaque source and receipt identifiers for notifications
• Canonical feature-guide/app-help excerpts sent to the existing classifier for grounded reply drafts; reviewed exact replies use the existing owned app conversation only, and content-free daily quiet counts appear in the private pinned status
• Explicit administrator answers and assumptions for a support request, with bound Late Info choices, through the existing private operator discussion and support provider paths
• Server-derived requester role, governing plan and add-ons, managed-app availability, normalized page and known platform/build supplied as descriptive context to the existing classification and task-brief providers; content-free weekly accuracy and operator-tap counts shown to administrators and in the private pinned status
• Administrator alerts about intake and monitoring health, with fixed text, codes, counts, times and a work item reference only
• With fix-live notices enabled, one fixed-text message ("Thanks for reporting this. A fix is now live. If you still see the problem, reply here.") per eligible customer request, once, in that request's own platform inbox or support chat conversation, sent as the enabling administrator without a per-message action; bug reports, community Discord requests and monitor requests are never messaged
• With the release train enabled, T3 Task pull request numbers, dev merge commits and dates sent through local T3 as one daily release task, which may merge to master and start the production deploy only after the owner approves in its thread
• When content processing is enabled, bounded support text, sender display names for app-origin support, original message times, page paths, engineering plans and approval status
• When an operator configures a private decisions channel, one card per decision waiting on an administrator (request title, one plan or task sentence, acceptance results, change size, and links to the request and its pull request), deleted once decided, and one line in the request's private thread naming the decision and the deciding administrator's Discord account
• Community member text with local source/author identifiers, bounded model-derived screenshot observations or unread-attachment indicators and exact Discord jump links; Jev receives request-local aliases instead of those identifiers
• When a server setting selects the example-based support classifier, each classification sends the new support text, up to 8 earlier messages, stored screenshot observations and fictional labelled examples to the configured Azure chat model without Discord message links; bounded label, relation, product area, uncertainty, severity proposals and content-free usage are kept; an optional human-support reply draft and its supplied guide reference stay on the request for administrator review, and never enter the measurement ledger

What is never sent through it:

• Raw attachment bytes and signed attachment links in Discord notifications, Jev requests, private support threads and web-service records; non-image attachments. Supported screenshot bytes go transiently to the configured Azure vision provider. A person may still paste a sensitive link into message text.
• Private attachment downloads and raw Sentry webhook bodies in the local T3 handoff; source-authored text can still contain pasted links
• New transfers to the retired support worker or Cezar cockpit, provider credentials and production deployment credentials

Content the Coach controls: Support text is authored by people and is not guaranteed to be free of personal or health information. Generated code may also reproduce such information; a model instruction is not a data-loss prevention guarantee.

Managed app fulfillment tracking

Destination: An operator-configured collector on LaunchSite-controlled infrastructure, with Codex case planning and Claude Code advice through self-hosted OpenRig.

How it is turned on: Disabled without its dedicated read-only bearer credential. The operator enables polling and case tracking. Paid purchases can be tracked before intake completion; readiness gates implementation planning. This feed cannot dispatch a provider action, deploy, submit to a store or send a customer message.

What can be sent:

• Opaque purchase, intake and provisioning references, validated app keys, payment eligibility and finite requirement and status codes
• Saved-reference readiness booleans, recorded status timestamps, deterministic change receipts and trusted administrator, source and workflow links

What is never sent through it:

• Business documents, signatures, emails, artwork bytes, checkout links and raw provider errors
• Provider credentials, secret references, support-worker credentials and database credentials

Client-selected assistant and lab sharing

Destination: The current owning coach, selected by the client through an accepted coaching relationship.

How it is turned on: The authenticated client explicitly shares a selected conversation message or personal lab result. Sponsorship does not activate sharing.

What can be sent:

• A snapshot of the selected message or the selected report name, extracted values, verification revision and educational explanation

What is never sent through it:

• Other conversations, personal memory, calendar details and future changes to the selected item
• The private uploaded source file

Social publishing to connected business accounts

Destination: The Facebook Pages and Instagram professional accounts the coach connects and selects for a post. Published posts are visible under those accounts at the provider.

How it is turned on: A coach saves a draft, then explicitly releases it for immediate or scheduled publication to selected enabled accounts. Connecting an account or saving a draft does not release a post.

What can be sent:

• The caption, optional Facebook link, selected marketing images or uploaded Instagram Reel video
• The selected business account identifiers and instructions to prepare and publish the post
• An unguessable public media address so Meta can retrieve the released copy of an image or video

What is never sent through it:

• Private coaching files are not selectable through the social media picker

Content the Coach controls: The coach writes the caption and chooses or uploads the media. We do not inspect their content for personal or health information. The coach controls what becomes public; published copies remain subject to the provider’s controls.

Public replies to business reviews

Destination: The Google Business Profile location or Facebook Page the coach connects and selects. The provider displays the reply publicly against a review or recommendation.

How it is turned on: A coach writes the reply and explicitly chooses to publish it. Imported reviews do not cause an automatic public reply.

What can be sent:

• The coach’s reply text and the provider identifiers for the business, review and existing reply where applicable

What is never sent through it:

• Coaching records are not automatically attached to review replies

Content the Coach controls: Reply text is written by the coach and is not filtered for personal or health information. Coaches choose what they disclose publicly.

Email requests for business reviews

Destination: A lead or member selected by the coach, or a qualifying member after the coach activates a first-attendance or first-payment rule. Delivery uses the coach’s configured email service.

How it is turned on: A coach queues an individual request or explicitly enables a rule for future qualifying events. The delivery worker checks marketing eligibility, opt-out preferences, quiet hours and the request cooldown before sending.

What can be sent:

• Recipient name and email address
• The coach’s review-request subject and message, business review link, business postal address and unsubscribe link

What is never sent through it:

• Attendance details, payment amounts and coaching records are not attached to the request email

Content the Coach controls: The coach controls the email wording. It is not inspected for personal or health information.

Webhook Endpoints (event delivery to a system the coach connected)

Destination: An HTTPS URL the coach enters. The coach selects the receiving system - for example an automation platform such as n8n, Make, Zapier, or GoHighLevel, or software they run themselves - and can change or remove it at any time.

How it is turned on: Off unless a coach creates an endpoint. Each endpoint is created with an explicit choice of what it may carry, and each message is signed with a secret unique to that endpoint so the receiving system can verify it came from us.

What can be sent:

• The event that occurred (for example, a check-in was submitted, or a compliance figure fell below the threshold the coach set) and when it occurred
• The client identifier the event concerns, and the identifier and threshold of the automation that sent it
• A compliance percentage, where the event is about compliance
• The programme phase the client is in or has moved to
• How many days or check-ins have been missed, the date of the last check-in or daily log, and the client’s check-in schedule
• The identifier of the check-in or message the event refers to - the identifier only, never its contents
• The client name, email address, and phone number - only where the coach set that endpoint to include contact details, which exists because most automation platforms match their own contact records on email or phone
• For an explicitly connected website payment offer: verified payment-confirmed or full-refund status, order and offer identifiers, amount and currency. This fixed payment payload never contains buyer contact details, course content or health information, regardless of endpoint contact settings

What is never sent through it:

• Check-in answers and any free text a client wrote
• Wellness system-status grades
• Lab results and uploaded documents
• Progress photographs and other imagery
• Message content

Workflow Webhook (lead delivery from a CRM workflow step)

Destination: One of the coach’s own registered Webhook Endpoints, named by a step inside one of their CRM workflows. The coach registers the destination, and can change, disable or delete it at any time.

How it is turned on: Off unless a coach registers a Webhook Endpoint and adds a webhook step to a workflow that names it.

What can be sent:

• That a lead reached a given point in the coach’s workflow, which workflow it was, and when
• The lead identifier, its pipeline stage, where it came from, its deal value, and when it was created
• Marketing attribution recorded with the lead (UTM campaign, source, and medium)
• The labels the coach has applied to that lead
• Every custom field the coach has defined on their leads, with its values
• The lead name, email address, and phone number - only where the coach set that endpoint to carry contact details

What is never sent through it:

• Client coaching records - check-ins, wellness grades, labs and imagery belong to a client rather than a lead, and no lead webhook can reach them
• The content of messages sent to or from the lead

Content the Coach controls: Custom lead fields are created and named by the coach, and we do not restrict what goes in them. A coach who records health-related notes in a custom field will send those notes to their chosen destination. Coaches choose what to collect there and where it goes.