Privacy Policy

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

• 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
• 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
• 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
• Model-derived request titles and message groupings produced when an administrator plans a private triage card, with content-free usage of that request
• Screenshots attached to the Discord source messages of a community case, downloaded for its investigation, review and implementation sessions
• Support-worker account labels, enabled state and priority, usage percentages and reset times, temporary device sign-in codes, sign-in outcomes and administrator audit receipts

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 and request splitting, bounded Azure intake summaries, optional Azure example-based classification, Jev classification and internal discussion, investigation and implementation by OpenRig-managed Codex sessions, with Claude Code advice and independent review

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

Signed coach-client agreement evidence · sensitive · optional

• 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

Account and profile information

• Name, email address, and password (stored only as a salted hash)
• Coach-created client invitation records: hashed single-use token, linked account and coach, email snapshot, expiry, and access/revocation status. Links expire after 72 hours; invitation records remain until the associated account is deleted. 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
• Client-pinned workout set notes saved as personal reminders for the same exercise and training template across devices
• Client-created food labels, and client-created 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
• 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 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

• 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
• 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
• Consent state and opt-out history for each email address, 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

• 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 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 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

• Name, email, phone, company, and stage for people in a coach’s pipeline
• Form submissions, booking requests, business-card scans, and QR-code captures
• 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
• UTM campaign, medium, content, and term recorded when a lead arrives from a link
• Notes, tasks, deals, estimates, and activity history the coach records
• Jev classifications, source references and coach review corrections; numeric prediction-time snapshots and observed CRM outcome labels
• Weekly pipeline checkpoints for 30-day and 90-day projections, captured only after the coach turns on projections: stage, time in stage, recorded activity counts and permitted Jev labels
• 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
• Only while Ghost Opportunities background analysis is on: a queue entry naming which open opportunity has new evidence, the kind of event (message, email, form or intake) and retry timing, with no message or answer content
• 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

• 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
• 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
• Frozen email content, sender and recipient details, experiment variant, sending attempt and provider message identifiers
• 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 public review replies, 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
• 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

• 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. Web Library deletion follows existing source-file cleanup; provider copies and backups have separate retention. Mobile direct-row deletion does not perform the web file and passage cleanup
• 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
• 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 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 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 a client asks their coach’s assistant a question; Generated after a check-in triggers an active Zyx automation configured by the coach; Generated after new evidence arrives for an open opportunity while the coach has Ghost Opportunities background analysis turned on; 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 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
• Push notification tokens for the web and mobile apps
• 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

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

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
• Notify platform staff and prepare reviewed code changes
• Answer mapped platform administrators in a private support thread about that case's bounded evidence, plan, recorded repository findings and implementation status, 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
• Classify selected email threads, or a lead’s recent matched correspondence as part of a lead analysis, with Jev when the coach requests it
• Only for coaches who turn on Ghost Opportunities background analysis (off by default), include an open opportunity’s recent matched correspondence, with mail from unverified senders labelled as unverified, in the bounded lead snapshot Jev classifies after an eligible new event; only email from a verified sender can itself start that analysis, and synchronized mail currently has no sender verification, so it never does
• 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

Signed coach-client agreement 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.

Account and profile information

• 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 or as a recipe 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
• Classify Pro CRM conversation text with Jev when the coach requests it (a selected conversation, or a lead’s linked messages as part of a lead analysis), and, only for coaches who turn on Ghost Opportunities background analysis (off by default), as part of an open opportunity’s bounded lead snapshot, including its recent website chat and CRM-sent messages, classified after an eligible new event: a new inbound WhatsApp or Instagram message on a linked lead, a new email from a verified sender, or new form, quiz or intake answers; website chat alone never starts a background analysis
• 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 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
• Classify permitted CRM evidence and support coach-reviewed workflow conditions
• Estimate defined future outcomes only after recorded history passes validation checks
• Show where saved Jev classifications, coach-requested or from background analysis the coach turned on, place open opportunities beside their recorded stages
• Only for coaches who turn on Ghost Opportunities background analysis (off by default), keep open opportunities’ Jev evidence current by classifying their bounded lead snapshot after new inbound WhatsApp or Instagram messages on linked leads, new emails from verified senders, or new form, quiz or intake answers arrive; never for contacts held for review, excluded from Ghost Opportunities, opted out or awaiting email consent
• Project where open opportunities are likely to be in 30 days and in 90 days, each horizon shown only after its own recorded history passes validation
• 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
• 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 and publish explicitly authorized replies 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
• 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 decide which parts of the organization they may read
• Keep an audit record of changes to employment, access, and approved hours

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

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 notifications and engineering worker

Destination: Operator-configured Discord channels, configured Azure vision inspection, request splitting and optional example-based classification, Jev classification, and dedicated home-server Codex and Claude Code sessions coordinated through OpenRig. Validated candidate changes are published as draft pull requests in the configured GitHub repository. Administrator-approved PR commits can merge into development, followed by deployment verification.

How it is turned on: Off by default. Platform administrators independently enable capture, Discord delivery, content transfer, classification, investigations and builds. 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. Community cases default to plan-only human review; trusted server policy can authorize the existing automatic bug-build flow for new bug cases. Message text and authors cannot grant approvals or upgrade policy. Plan it on a private triage card can split a mixed burst into one plan-only case per request; the split grants no approval. Classification uses Jev unless a server setting selects the Azure example-based classifier, which falls back to Jev on any failure and keeps the same admission cut-off. That setting also covers the community channel scan, where Jev then only groups messages with earlier cases. Feature builds require recorded plan and implementation approvals for the specific plan revision; one administrator Approve & build tap records both. Grounded app bug fixes build automatically when enabled. Every merge to development requires human approval of the exact PR commit; production release remains separate.

What can be sent:

• Opaque source and receipt identifiers for notifications
• Administrator alerts about the engineering worker's health and stopped builds or merges, with fixed text, codes, counts, times and a work item reference only
• 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
• 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 an administrator chooses Plan it on a private triage card, that card's bounded message text, screenshot flags and stored screenshot observations go to the configured Azure chat model under request-local aliases, which returns request titles shown only on the private card
• 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; only the label, confidence and content-free usage are kept
• Screenshots (PNG, JPEG, WebP or GIF still images, at most 8 per job) attached to the Discord source messages of a community case, downloaded by the home worker for that case's Claude Code and Codex investigation, review and implementation sessions
• Candidate source-code changes and opaque work-item and plan-hash references in GitHub; community-origin PR/commit metadata uses generic copy and trusted source links

What is never sent through it:

• Raw attachment bytes and signed attachment links in Discord notifications, Jev requests, private support threads and stored records; non-image attachments; supported screenshot bytes go transiently to the configured Azure vision provider and, for community cases, to the home worker's engineering sessions described above. A person may still paste a sensitive link into message text
• Production deployment credentials and Supabase service credentials on the home worker

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.