The localised versions of this document (English / German / French) are available in the app at brevetcycling.club/privacy. The German version is binding for users in Germany, Austria and Switzerland.

Privacy Policy

Brevet Cycling Club Last updated: 23 September 2026 (policy version 2026-09-23)

23 September 2026 (policy version 2026-09-23) — the one thing the account-less tools keep. Nothing about your member data changes. Until now §6b could say the public tools store nothing at all. That is no longer exactly true, and the change is worth a version rather than a footnote. Once your result is on screen, the ride analysis sends a description of the FILE — the make and model of the device that wrote it (never its serial number), the message and field codes it used, which channels it held, and the shape of its sampling in coarse bands. No value from your ride, no coordinate, no date or time, and no heart rate, not even a note that the channel was there. It is kept because the page must open files from head units nobody here owns, and identical descriptions collapse into one row with a counter, so it grows with the number of recording DIALECTS rather than with the number of visitors. §6b now describes it in full. You will be asked once to confirm the current version before your next AI request.

21 September 2026 (policy version 2026-09-21) — two fields that stay on your device. Nothing new reaches us, and nothing changes about how your member data is processed. The ride analysis in §6b now also sorts your heart rate into zones. A heart-rate zone is a share of a maximum, so behind the same consent tick the page asks for one: a maximum you have measured, or your age, from which it estimates one with a published formula. Both are used where you typed them — in your browser — and the request has no field for either, exactly as it has none for the heart rate itself. §6b now says this instead of leaving it unsaid. We bump the version anyway, because the consent ledger has to be able to say which text you accepted, and because a page that asks something new about your body should say so in the document that describes what it asks. That means you will be asked to confirm the current version once before your next AI request. Corrected the same day, before it mattered to anyone's data: §6b said the web server writes no access log for these requests and left it there. It does not — but when it turns a request away for arriving too fast it notes that refusal, with the address, in its error log, which is how an attack is seen while it happens. §6b now says so instead of letting the silence imply otherwise, and it also names the aggregate counts we keep of answered and refused requests.

20 September 2026 (policy version 2026-09-20) — two public tools that work without an account. Nothing changes about how your member data is processed. (1) New §6b: the single-ride analysis and the pacing card open your file in your own browser; the file is never uploaded, only number series (power, cadence, speed, distance, elevation — or the distance-and-elevation shape of a route) reach our server, and nothing is stored. Heart rate is processed in your browser only, after a separate explicit consent, and is never sent to us. (2) §4, clarification: power and cadence are special-category data where we combine them with your heart-rate, sleep and recovery data, as in a member account — not on their own. Our Terms gained Section 14 on the same date. Corrected the same day, before it mattered to anyone's data: §6b first said a file's date and time of day “is not read”. It is read — inside your browser, to measure the seconds between samples — and it is never sent; §6b now says exactly that, and names .TCX beside .FIT as a file the ride analysis opens.

9 September 2026 (policy version 2026-09-09) — routes you upload, and what the map service receives. Riders can now upload their own GPX routes to ride indoors — private by default, or shared with a group or the club. (1) §2, §3: a GPX is location data, and it usually begins at your front door; when we build the route we cut 500 m off both ends, permanently, so it never starts at your door — not even for you. Uploading, building and sharing run on contract performance (Art. 6(1)(b)); sharing is your per-route choice and reversible at any time. (2) §6, correction: for every route we build — yours or the catalogue's — our server sends a thinned copy of the route (one point every 50 m, rounded to about 11 m, ends removed; no name, account, time or file) to OpenStreetMap's Overpass API to read what stands beside the road. This has been the case since the visual-world update of 7 September and was not described here; the earlier sentence that Brevet "never transmits location anywhere" was written about the device permission and now says so. (3) §7, §8: routes are kept until you delete them or your account; deleting one removes the built track, its world file and the uploaded GPX; your data export includes your routes as GPX. Because (2) discloses a processing that was already happening, we ask you to re-confirm the current policy version before your next AI request.

4 August 2026 (policy version 2026-08-04) — two optional ride themes, and what they do NOT do. This update describes two opt-in themes and, more importantly, the storage and the third-party contact each one does and does not create. (1) Podcast player (§6, §7, §10, §11): your subscriptions and listening positions stay in your browser and never reach us — we do not know which shows you follow or what you have listened to. Episode audio streams from the publisher's own server straight to your player, so that publisher receives your IP address and browser identification as part of the media request — exactly as with any podcast app, and it is what a show counts its listeners from. The episode LIST is fetched by our server instead, so a publisher never learns WHO subscribes. Show search is forwarded through our server to Apple's public directory, so your own address never reaches Apple. (2) News board (§7, §10): your source list and the "already shown" marks stay in your browser; your browser contacts no news site at all, because we fetch the feeds and nothing is embedded — no images, no article pages, no third-party scripts. (3) §7 additions: both feed caches are transient server memory (30 minutes for podcasts, 5 for news), addressed by a hash of the feed address, shared across all riders, with no user identifier and no address in plaintext. (4) Ride share links (new §6a): sharing a ride has always been off by default and per-ride; §6a now says so in the policy, and describes the new per-ride choice of what a link publishes — heart rate is off unless you switch it on, and what you leave off is never sent. Riders who accepted an earlier version are asked to re-confirm the current policy version before their next AI request.

2 August 2026 (policy version 2026-08-02) — AI context, corrected in both directions. An audit found the AI prompt did not match this document. (1) Fixed to match the promise (§5): the model used to receive your latest RAW recovery readings — HRV (RMSSD), resting heart rate, sleep hours and quality, SpO2, body fat. It now receives only DERIVED statements against your own baseline ("HRV below their own baseline"), which is what "What is NOT sent" always said. No raw reading leaves this server. (2) Newly disclosed (§5): the free-text NOTE you type with a life event is sent to the model in your own words, so the coach can answer what you actually wrote — this was already happening and was not described here. The event TYPE is generalised first: the model is told "health event", never a condition name. If you would rather a note stayed on this server, log the event without a note. Because (2) widens the described processing, we ask you to re-confirm before your next AI request.

23 July 2026 (policy version 2026-07-23) — club programme update. This update aligns the policy with the club programme. (1) Removed features (§2, §7): the leaderboards and competitive leagues were removed in 2026 and are no longer described as processing purposes; any historical leaderboard/league data still on file is retained until account deletion and is no longer processed. (2) New club processing (§2, §3, §6, §7): your sequential membership number (assigned when you join; shown club-internally as the number only, no names, in this version), the homologation ledger of your completed club brevets, and the transactional club letters (welcome letter, weekly homologation confirmation). These run on contract performance (Art. 6(1)(b)) — no new consent is required. (3) §2 addition: on club brevet rides, the contrôle stamps and in-ride fueling/effort (RPE) declarations you record are part of your training data. Riders who accepted an earlier version are asked to re-confirm the current policy version before their next AI request.

Earlier — 17 July 2026 (policy version 2026-07-17) — accuracy & completeness corrections. This update corrects and completes several statements following an internal data-protection review: (1) Retention truth for AI/Coach data (§5, §7): the 30-day window applies to the AI job queue and conversation log only; the Coach's conversation memory is kept for up to 365 days and durable Coach facts until account deletion — both were already how the platform worked, and both are under your control ("Clear history", "Reset Coach memory"). (2) Email delivery (§6, §11): our SMTP setup is now named specifically (own EU server, AWS SES eu-north-1 relay under the AWS GDPR DPA). (3) Model development & research (§5): new transparency note on background training-response models; any research use beyond in-product development requires a separate opt-in (model_research). (4) §7 additions: retention rows for the security audit log, companion telemetry, and Coach memory. (5) §4/§11 addition: transient in-memory live-ride telemetry cache (EU, no persistence) — disclosed both in the health-data section and in the international-transfers table. (6) §10 addition: device-local storage of Spotify OAuth tokens (browser localStorage, §25(2) No. 2 TDDDG). Riders who accepted an earlier version are asked to re-consent before their next AI request.

Earlier — 30 June 2026 — transparency addition (draft — to be confirmed by admitted counsel before launch). This update discloses the YouTube visual theme as a third-party integration. The theme is opt-in; when a rider selects it, a click-to-load gate now requires an explicit, prior action before the embedded privacy-enhanced player (youtube-nocookie.com) loads. §2, §3, §6, §10 and §11 now name Google LLC (USA) as an independent controller for the embedded player and for the optional OAuth connect, and describe the resulting international transfer and its safeguard. This is a transparency and consent-mechanics addition; it does not change the consent baseline for health-data (GDPR Art. 9) or AI processing and so does not by itself require renewed health/AI consent.

Earlier — 11 June 2026 (policy version 2026-06-11 — transparency corrections: §10 now lists all four first-party cookies the web platform sets (not one); §6/§11 reclassify Strava as an independent controller; §2/§7 add the contact-form processing; session-cookie lifetime corrected to what the code enforces (7-day idle / 30-day absolute, not 90 days); the retired Google Calendar integration is no longer described as active and its leftover tokens are deleted; §1/§13 state the documented DPO position instead of announcing an appointment. Riders who accepted an earlier version are asked to re-consent before their next AI request.)

This privacy policy explains how Brevet Cycling Club ("we", "us", "Brevet") collects, uses, stores, and protects your personal data when you use our virtual cycling simulator and companion services (the "Platform"). We are committed to transparency and to protecting your rights under the General Data Protection Regulation (GDPR) and other applicable data protection laws.

1. Who We Are

Data Controller (Verantwortlicher, Art. 4(7) GDPR):

Manuel Bröer - Fotodesign Eisenbahnstr. 201 63303 Dreieich Germany

Privacy contact: privacy@brevetcycling.club General contact: info@brevetcycling.club

Data Protection Officer (DPO): Brevet processes special-category data (Art. 9 GDPR — heart-rate variability, sleep, recovery and other health metrics) at the core of its coaching service. We have assessed the appointment duty (Art. 37 GDPR, §38 BDSG) and documented the result: at the platform's current scale — a small, invite-only beta operated by a single person — no DPO is appointed. The assessment is revisited at defined triggers (substantial growth of the user base, opening of public registration, or commercial launch), and an external DPO will be appointed and published here when one is met. Until then, all data-protection requests are handled by the privacy contact above and answered within the statutory 30-day window of Art. 12(3) GDPR.

If you believe we are processing your personal data unlawfully, you can lodge a complaint with your local supervisory authority (Art. 77 GDPR). For users in Germany the territorially competent authority depends on your federal state -- for our place of business it is the Hessische Beauftragte für Datenschutz und Informationsfreiheit (HBDI), Gustav-Stresemann-Ring 1, 65189 Wiesbaden, poststelle@datenschutz.hessen.de. Users elsewhere in the EEA can contact their own national authority; users in Switzerland the Eidgenössischer Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB); users in the United Kingdom the Information Commissioner's Office (ICO).

2. What Data We Collect

3. Legal Basis for Processing

We process your personal data under the following legal bases (GDPR Art. 6):

4. Health Data -- Special Category (GDPR Art. 9)

Health and biometric data (heart rate variability, sleep data, body composition, SpO2, respiratory rate, body temperature, VO2max, cycling power and cadence) is classified as special category data under GDPR Art. 9.

What makes power and cadence sensitive here — and what does not. On their own, power and cadence are measurements of a machine: the work a power meter recorded, the revolutions of a crank. They say nothing about your health. Inside a member account we combine them with heart rate, heart-rate variability, sleep and recovery data into one picture of how your body is coping, and in that combination they share the protection of the data they are combined with — which is why they are listed above. Where they are processed alone, without that link, as in the public tools of Section 6b, they are not special-category data, and we do not treat them as such.

We process this data only with your explicit consent (Art. 9(2)(a)). Consent is recorded in our consent_log table together with timestamp, policy version, locale and (hashed) source-IP, so we can prove when and on which version of this policy you opted in.

Data sources (read)

We read health data from the platform-native, on-device health hubs:

• iOS: Apple HealthKit. Brevet uses the key NSHealthShareUsageDescription to request read access. Per Apple App Store Review Guideline 5.1.3, we do not store HealthKit data in iCloud, do not use it for advertising, and do not share it with data brokers.
• Android: Google Health Connect. Brevet declares only the android.permission.health.READ_* permissions necessary for cycling coaching and recovery analysis (see the manifest in our public app bundle for the exact list). Each permission is justified individually in the Google Play "Health Apps declaration form".

Write-back: exporting completed Brevet rides

The companion app can also write completed Brevet indoor rides back into Apple Health (iOS) or Google Health Connect (Android) so that your other fitness apps (Strava, Training Peaks, Apple Fitness, etc.) see them. This is opt-in via the "Export workouts" toggle in the Sync settings, and off by default.

When the toggle is on, for each completed ride the companion writes one workout record of type "Cycling" containing:

• start time and end time
• total distance (metres)
• total calories burned (kJ converted to kcal)
• the source attribution "Brevet Cycling Club"

A monotonic watermark in the companion app's secure storage prevents the same ride from being written twice. We do not write per-second power, heart-rate or cadence sample streams, GPS routes, or any data unrelated to the indoor ride.

The write goes from our EU backend → the companion app on your device → your device's Apple Health / Health Connect store. From there it stays under the OS's control: Apple/Google govern who else can read it. No third-party transfer happens during the write-back path.

iOS uses the key NSHealthUpdateUsageDescription and Android declares android.permission.health.WRITE_EXERCISE, WRITE_DISTANCE, WRITE_TOTAL_CALORIES_BURNED, WRITE_HEART_RATE and WRITE_EXERCISE_ROUTE for this purpose. Permissions Brevet declares but does not currently use (the optional HR samples and route polylines) are kept in the manifest only so a future opt-in to richer write-back does not require a new permission prompt.

To stop the write-back at any time: toggle "Export workouts" off in the Sync settings, or revoke health-sync consent entirely (which also stops the read direction).

Use of Google APIs (Limited Use Policy)

Brevet Cycling Club's use and transfer to any other app of information received from Google APIs (including Google Health Connect) will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

In practice this means:

• We use Health Connect data only to provide the user-facing fitness-coaching features described in this policy.
• We do not transfer Health Connect data to third parties except as needed to provide or improve those features, to comply with applicable law, or as part of a merger, acquisition or sale of assets with notice to users.
• We do not use Health Connect data for serving ads, including personalised, retargeted or interest-based advertising.
• We do not allow humans to read Health Connect data unless we have your affirmative agreement for specific data items, it is necessary for security purposes (e.g. investigating abuse), to comply with applicable law, or for aggregated and anonymised purposes used to improve the service.

How we treat your health data

• You must actively choose to sync health data from Apple Health or Google Health Connect. We never collect health data without your action.
• You can withdraw consent at any time via the Sync settings in the companion app (button "Revoke health sync consent") or by contacting us. Withdrawal is logged with the same level of detail as the original grant. Once revoked, the companion app immediately stops reading and uploading health data; already-stored data is deleted on account deletion or by request.
• Health data is stored in our EU-hosted PostgreSQL database with encryption at rest, pseudonymised by user-ID where possible, and is accessible only to authorised personnel for security, legal-compliance and operational purposes.
• Live ride telemetry is processed transiently in-memory. While you ride, your live values (heart rate, power) are additionally held only in server working memory on our EU infrastructure — never written to disk or persisted — to power real-time features such as the effort-based peloton across our multiple server processes, and are dropped as soon as they are delivered (see the live-ride telemetry cache in §11).
• No human routinely views your identifiable health data. Your readiness analysis and coaching are generated automatically — there is no human coach who reviews your data as a matter of course. (You can still ask us to have a person review a specific AI recommendation — see §7a.)
• Health data is never sold, shared with advertisers, or used for interest-based profiling.
• Health data sent to AI is anonymised first (see Section 5).

Location permission (Android ACCESS_COARSE_LOCATION / ACCESS_FINE_LOCATION, iOS NSLocationWhenInUseUsageDescription)

Brevet's companion app requests the operating system's location permission for exactly one purpose: to let Apple HealthKit and Google Health Connect return the route- and distance-derived fields of the workout records we already read under your health-data consent. Without this grant, Health Connect's ExerciseSessionRecord returns null for distance and speed on outdoor rides, so your outdoor workouts show up with the OS's indoor-mode estimate (typically zero kilometres) instead of the real route metrics.

What Brevet does NOT do with the location permission:

• We never open a continuous location subscription. There is no CLLocationManager.startUpdatingLocation call on iOS, no FusedLocationProviderClient.requestLocationUpdates call on Android.
• We never collect raw GPS coordinates ourselves, never store them, never transmit them to our servers, and never share them with any third party.
• We never use location data for analytics, advertising, profiling, or any feature other than enabling complete workout-distance reads from the OS's own health hub.

The grant only affects how much detail the OS includes in the workout records it hands us when we read them. The OS itself remains in control of which slice of the route to expose, governed by your per-workout privacy settings inside Apple Health / Health Connect.

You can deny this permission and continue using the rest of the platform unchanged. Outdoor workouts will simply show with the OS's indoor-mode distance estimate.

Background health reads (Android READ_HEALTH_DATA_IN_BACKGROUND, iOS HealthKit Background Delivery)

To keep your readiness numbers fresh without forcing you to open the app every morning, Brevet reads health data in the background from the same two sources:

• Android: the manifest declares android.permission.health.READ_HEALTH_DATA_IN_BACKGROUND, which Health Connect classifies as a "special access" permission. Google's permission dialog surfaces it as a separate toggle alongside the per-data-type grants. Once granted, our existing 12-hour WorkManager sync job (which runs while the app is in the background) can read the same data types it reads in the foreground; without it the job still wakes up but Health Connect returns empty results.
• iOS: Brevet registers HKObserverQuery for the recovery- critical data types (heart-rate variability, resting heart rate, sleep analysis, VO2 max) and calls HKHealthStore.enableBackgroundDelivery(for:frequency:.immediate) for each. When your watch, ring, scale or other connected device writes a new sample of one of those types, iOS wakes the Brevet companion process briefly so it can fetch the fresh reading. The wake-up budget is bound by iOS's background-task policy and cannot be expanded by us.

The background path reads exactly the same data types listed in the §2 "Health & Biometric" row — there is no expanded, background-only data set. We do not "wake up early" to read data we wouldn't otherwise read. Background access is a freshness mechanism, not a data-expansion mechanism.

Background reads are subject to the same retention rules, storage location, limits on human access, third-party-sharing prohibition and revocation rules as foreground reads (every other subsection of §4). Revoking the health-sync consent immediately turns the background path off along with everything else. On iOS, the companion also calls HKHealthStore.disableAllBackgroundDelivery() so iOS stops queuing wake-ups for data we no longer have permission for.

The declared purpose for both platforms is identical: recovery analysis, readiness scoring and training-load management for the rider, on the rider's own behalf — generated automatically. The data is not used for advertising, profiling for third-party purposes, or any other downstream use.

Local-only morning reminder notification

The companion app schedules a single local notification (flutter_local_notifications.zonedSchedule, Android channel brevet_health_reminder) that fires once a day at the time you choose — default 09:00 local, adjustable in the Sync settings between 00:00 and 23:59 or disabled entirely. The notification:

• Is generated on your device by the operating system, without any server involvement. No Firebase Cloud Messaging round-trip, no Apple Push Notification Service delivery. Nothing leaves your device when the notification fires.
• Carries a fixed payload identifying it as the daily reminder (so a tap routes to the in-app sync screen). The payload contains no health data, no personal data, no rider-specific text beyond the localised reminder copy.
• Suppresses itself for the day when our backend's freshness endpoint (GET /api/companion/health-sync-summary, which only reports a boolean "is today's data complete?" + the latest readiness score) confirms your data is already up to date. This avoids redundant buzzes for riders who already synced via another device or via background delivery.

The reminder lives entirely under your control. Turn it off in the Sync settings, change the time, or simply ignore it — the underlying sync still runs on the same WorkManager / BGTask schedule regardless of whether the notification fires.

5. AI Data Processing

Brevet's AI coaching is powered by Google Vertex AI (Gemini models), served exclusively through Google's EU multi-region endpoint — every request is processed inside the European Union (Google may serve it from any of its EU regions, e.g. Frankfurt or Eemshaven); we never use the global endpoint. Vertex AI acts as a data processor for Brevet under Art. 28 GDPR. Google does not use the prompts or responses to train its general-purpose models — this is contractually pinned via Google's Vertex AI Service Specific Terms (cloud.google.com/terms/service-terms), Vertex AI section, which prohibits Google from using customer data to train foundation models without separate written agreement. Brevet has not entered any such agreement; the default no-training contract applies.

Why Vertex AI

We picked a managed Gemini deployment over a self-hosted model because it gives Brevet a state-of-the-art coaching model with predictable latency at a cost we can sustain at the platform's current scale. We do not fine-tune the model. We do not ship custom weights. Every request is processed by Google's stock Gemini deployment under our project's service account.

Architecture

The AI pipeline has three components:

1. Backend (EU-hosted): when you submit an AI request, the backend builds a prompt payload and writes it to a job queue (ai_jobs table) inside our EU PostgreSQL database. The backend strips your name and replaces it with a stable pseudonym (Athlete-XXXXXX) before the job leaves the database boundary.
2. Brevet broker (self-hosted): a long-running Brevet- operated process running on a dedicated machine inside Brevet infrastructure. The broker connects outbound to the backend over an authenticated WebSocket (no inbound ports are opened on the broker network), claims pending jobs, then calls Vertex AI on Brevet's behalf using the project's service-account credentials. The broker authenticates with the backend using a pre-shared token compared with hmac.compare_digest(); it never receives your user_id, email or display name — only the pre-pseudonymised payload.
3. Vertex AI (Google Cloud, EU): receives the pseudonymised prompt + system context + RAG-retrieved snippets, runs Gemini, returns the response. Inference goes to Google's EU multi-region endpoint (aiplatform.eu.rep.googleapis.com, location eu) — EU-only by construction; embedding requests are pinned to the single EU region europe-west3 (Frankfurt). We do not use a global Vertex endpoint, and the broker refuses to start if any Vertex setting points outside the EU.

A retrieval-augmented generation (RAG) step on the broker side looks up cycling-science context from a Postgres pgvector store on Brevet infrastructure; that store contains only public cycling-science material, never user data.

What is sent to Vertex / Gemini

• A pseudonymised training summary (recent rides, power/HR metrics, fitness state)
• Demographic context you provide (age, gender, weight — no name, no email)
• Derived recovery/readiness context — which can include your current menstrual cycle phase if you have logged it (a derived phase label, never the raw flow dates)
• Notes you write yourself. If you log a life event (illness, stress, travel, a poor night) and type a note with it, that note is sent to the model in your own words, so the coach can respond to what you actually said. The event's TYPE is generalised first — the model is told "health event", never a condition name — but your note is not edited. Write only what you want the coach to read; if you would rather it stayed on this server, log the event without a note.
• Your stated training goal
• Cycling-science snippets retrieved from the RAG corpus (no user data)
• The pseudonym Athlete-XXXXXX as the rider's display name for the model to refer to

What is NOT sent

• Your real name, display name, email address or user ID
• Raw health data (HRV, sleep, etc.) — only derived aggregate metrics
• Your Strava credentials or OAuth tokens
• Any content owned by Apple HealthKit or Google Health Connect beyond the aggregate metrics described above

Storage and retention

• AI job queue and conversation log (ai_jobs, ai_conversation_log): the pseudonymised prompt payloads and the model's responses are stored in our EU PostgreSQL for 30 days and then deleted by an automatic cleanup task.
• Coach memory — so the Coach can remember earlier exchanges the way a human coach would ("we tried this last spring") — is stored separately and kept longer:
  • Conversation turns (coach_conversations): each chat turn — and the coaching text from your morning/weekly/post-ride emails — is stored as text (with an optional similarity index) for up to 365 days, then removed by a daily cleanup task. You can delete all of it at any time with "Clear history" in the Coach chat panel.
  • Durable facts (coach_user_facts): a short list of things you have told the Coach — your goal, constraints, preferences, planned events — is kept until you delete your account or clear it yourself. You can review everything the Coach remembers, delete a single fact, or "Reset Coach memory" entirely from Profile → Dangerous Zone.
• A condensed context summary may be stored alongside messages to improve follow-up responses; it is removed by the same cleanup.
• The job queue itself uses a 30-day TTL (expires_at) so abandoned jobs are garbage-collected.
• Google Cloud's data-handling: under the Vertex AI Service Specific Terms, prompt and response data sent to Vertex AI is retained by Google only to the extent necessary to serve the request and to operate the service (incl. abuse detection / quota), and is not used to train Google's foundation models. Google's specific retention windows are governed by the Cloud Data Processing Addendum (DPA) we countersigned with Google as part of our Cloud project setup.

International transfer (Art. 44 GDPR)

Google Cloud is operated by Google LLC, headquartered in the United States. Even though our Vertex requests target the EU region (europe-west3 / europe-west), Google may need to transfer limited operational metadata to the US for billing, service operation and abuse detection. We rely on Google's EU Standard Contractual Clauses (Module 2: controller → processor) and on Google's adherence to the EU-U.S. Data Privacy Framework as the legal basis for any such transfer. The Cloud Data Processing Addendum we countersigned with Google incorporates both safeguards.

We do not use OpenAI, Anthropic, Microsoft Azure OpenAI, AWS Bedrock or any other LLM provider beyond Vertex AI today. If we ever add a second provider, this section will be updated and your renewed AI consent will be requested.

Model development & research (beta)

Model development & research (beta). To improve the automated coaching engine, we run new training-response models in the background on your existing training and recovery data, alongside the coaching you already receive — these run silently, are never shown to you as a second opinion, and produce no separate advice. Any use of your data for research outside this in-product development — for example exporting time series into a separate research environment — happens only after you give a specific, separate opt-in consent (the model_research purpose) and can be withdrawn at any time. Research copies are pseudonymous, stay on our EU systems, are never shared or sold, and are deleted when you withdraw consent or delete your account.

You control AI access

• AI features require explicit consent acceptance before first use
• You can revoke AI consent at any time via POST /api/ai/revoke-consent or in the Platform UI
• Revoking consent immediately prevents further AI processing -- pending jobs for your account are cancelled
• The 30-day AI job/conversation data is deleted at the next cleanup cycle (or immediately if you delete your account). The longer-lived Coach memory (above) is cleared by "Clear history" / "Reset Coach memory", and in full when you delete your account.

5a. Companion Telemetry (Crash + Error Reporting)

To diagnose companion-side crashes and UX failures that never reach our backend (BLE pairing failures, sync errors, mid-ride app deaths), Brevet operates a narrow telemetry pipe. It is off by default for every rider; turning it on requires a deliberate per-account action by Brevet, with the rider's prior agreement.

What the pipe collects

The pipe never carries free-form analytics, never carries health data, and never carries the rider's name, email or session token.

Server-side PII strip — what's redacted before storage

Every string field (message, stack, context values) passes through a redaction filter on our backend before it reaches our log pipe:

• Email addresses → <email>
• Bearer tokens, hex tokens, long base64 runs → <token>
• OS user paths (/Users/<name>, /home/<name>, C:\Users\<name>) → /<user> / <user>
• IPv4 and IPv6 addresses → <ipv4> / <ipv6>
• Long digit runs (≥ 11 digits, likely phone / account numbers) → <digits>

Pseudonymisation

Each event is tagged with the rider's stable but server-opaque pseudonym Athlete-XXXXXX (a SHA-256-derived 6-character identifier) and an install-scoped UUIDv4 device id. The broker / log pipeline never sees the rider's real name, email or user id. Only a privileged admin endpoint (/admin/telemetry/lookup, audit-logged on every call) can reverse-map the pseudonym back to the rider, and only when Brevet needs to triage a specific report.

Where the events go

The companion sends batches over HTTPS to our EU backend (POST /api/telemetry/companion), which strips PII as described and forwards each event to our self-hosted observability stack (SigNoz on Brevet infrastructure inside the EU). No third-party crash reporter is involved: we deliberately do not use Firebase Crashlytics, Sentry SaaS, Bugsnag, or any other vendor for this pipe. The data never leaves Brevet.

Local crash queue

Crash events that fire while you are offline are written to a small persistent FIFO on your device (50-entry cap, SharedPreferences-backed). The next time the companion launches with a working network connection it flushes the queue and clears the local copy.

Pre-login crashes

Crashes that happen before you sign in (onboarding bug, login loop) reach a separate anonymous endpoint (POST /api/telemetry/companion/pre-auth) that accepts ONLY events of type crash. Rate-limited at 5 requests per minute per IP and body-capped at 32 KB. These events carry only the device UUIDv4 — no rider binding — until you sign in for the first time, at which point the device id is linked to your account so later forensic lookup can attribute past pre-auth crashes to you.

Opt-in + revocation

• Off by default for every non-admin rider.
• Brevet admins are implicit-opted-in for operational reasons (we cannot diagnose our own crashes without crash data from the admin builds).
• For non-admin riders, opt-in happens only through a documented support flow: you ask, we toggle, we tell you we toggled, and the next launch starts emitting events.
• Revocation is a single API call by Brevet (POST /api/admin/telemetry/opt-in/{user_id} with enabled=false), logged in audit_log like every other admin action. The companion stops emitting at the next launch, and any pending local crashes are still flushed once (so a crash that triggered the revocation doesn't disappear with it).

6. Third-Party Data Sharing

We share your data with the following third parties, and only for the purposes described:

We do not:

• Sell your personal data to any third party
• Share your data with advertisers
• Use your data for profiling for third-party purposes
• Share identifiable health data with any third party

Use of YouTube API Services. The optional YouTube visual theme uses YouTube API Services — the embedded IFrame player and, if you connect your account, the YouTube Data API (read-only). By using the theme you agree to the YouTube Terms of Service; any data Google receives is handled under the Google Privacy Policy. When you connect your YouTube account, the read-only access (your playlists, subscriptions and your region's trending feed) is used only to let you pick what to watch during a ride; we do not store that data on our servers, never transfer it to third parties, and never use it for advertising. You can revoke Brevet's access at any time in your Google Account permissions.

6a. Publishing a Ride Yourself (share links)

This section is not about anyone we hand data to. It is about the one place where you are the publisher, and it is worth its own heading because the consequences are different: what you publish here, we cannot un-publish for you once someone has copied it.

It is off. Every ride is private. Nothing about a ride is reachable from outside your account unless you tap "Create share link" on that specific ride.

Per ride, never per account. Sharing one ride shares that ride. It does not open your profile, your history, your fitness numbers, or your other rides.

The link is the key. We mint a random 128-bit token and the ride lives at that address. It is not listed anywhere, not in search, not on your profile — but there is also no login in front of it. Anyone holding the link can open the ride, and can pass the link on. If you post it somewhere public, treat it as public: it can be copied, re-shared and indexed by search engines like any other public URL.

You choose what it shows. Four things are always on the page, because they are what a shared ride is: the route name, the duration, the distance and the elevation. Everything beyond that is a switch you control:

Heart rate is off unless you switch it on. That is deliberate: it is the health-adjacent end of a training file, and a default that publishes it would be a default nobody chose.

"Off" means not sent, not merely not drawn. The page you share is built from your selection on our server. A block you leave off is never put into the response at all — so it is not hiding in the page's data for someone who looks past the visuals.

Some things can never be shared this way. Beat-to-beat heart intervals (the raw signal HRV is computed from), your GPS positions, your speed and cadence traces, your critical-power and weight values, your notes, and anything your Coach has written are not part of any block and cannot be published through a share link at all.

The preview card obeys the same choice. When the link is pasted into a chat or a social post, the small preview card that appears is generated from exactly the same filtered data — it cannot show a number the page itself would not.

Changing your mind. Turning a block off updates what the link shows immediately, and keeps the same link working. "Stop sharing" deletes the token: every link you have already handed out goes dead at once, and re-sharing later mints a brand-new address, so the old link never revives. What we cannot undo is a copy someone already made while the link was live.

6b. Public Tools Without an Account (single-ride analysis, pacing card)

Two things on this site work without an account and without a login: you choose one file, you get numbers back, and that is the end of it. This section spells out what happens, because "we keep nothing" is a claim that is only worth something in detail.

Your file stays on your device. It is opened by your own browser. It is never uploaded — our server has no way to receive it on these routes. What your browser sends is a handful of number series it has read out of the file, together with the values you type in:

• Ride analysis (a .FIT or .TCX file): power, cadence, speed, distance, elevation, and time counted in seconds from the start of the ride — plus, if you enter them, your weight, critical power and W'.
• Pacing card (a .GPX file): the route as pairs of distance and elevation — the shape of the road — plus your critical power, your weight, the weight of your bike, and optionally your height, riding position, W', how your power holds late in long rides, and how hard you mean to ride. A name you type for the card is printed on the card in your browser and is never sent.

One more thing goes, and it is the only thing we keep. Once your result is on the screen, your browser sends a description of the FILE — never of the ride: which make and model of device wrote it (never its serial number), which message and field codes it used, which channels it held, and the shape of its sampling in coarse bands like "1 s" or "under 30 minutes". No value from your ride, no coordinate, no date or time of day, and no heart rate — not even a note that the channel was there. We keep it because this page has to open files from head units nobody here owns, and the failures that matter are recording dialects we cannot invent: a firmware that writes one speed field and not the other, a ride chained out of three files after a battery change, a file whose checksum fails because the battery went first. Identical descriptions collapse into one row with a counter, so what we hold grows with the number of DIALECTS, not with the number of visitors, and there is nothing in it that could point back at you.

Your device also sends its IP address with the request, as it does with every request on the internet.

Your file carries more than that — and it is not read. A file recorded outdoors usually carries GPS coordinates; most files carry a device serial number and the real date and time of the ride; a route file carries where the road is, which often means where you live. The code that opens your file reads fields from a fixed list. Coordinates, names and serial numbers are not on it and are never read. The clock time of each sample IS read — in your browser only, because there is no other way to know how many seconds lie between two samples — and what is sent is the time since the start of the ride, never the date or the time of day. The requests have no field for a coordinate, a name, a serial number or a clock time, and our server refuses any request that carries a field it does not know.

Heart rate never reaches us. Heart rate says something about your body and not only about your riding, so it is special-category data under Art. 9 GDPR and we treat it as such: it is processed in your browser only. By default the heart-rate channel of your file is not read at all. Tick the separate box on the page and your browser reads it, draws it and relates it to your other channels on your own device — that tick is your explicit consent under Art. 9(2)(a) GDPR and it covers that one analysis. Behind that same tick the page asks two more things about your body, because a heart-rate zone is a share of a maximum and means nothing without one: a maximum you have measured, or your age, from which it estimates one. Both are used where you typed them, in your browser. What the request carries has no field for any of the three — not for a heart rate, not for a maximum, not for an age (nor for a coordinate) — and our server refuses a request that carries one. Untick the box, or close the page, and there is nothing left: neither here nor with us, because it never was with us.

Nothing is written down. The numbers are held in server working memory for the length of the calculation — typically well under a second — and released when the response is sent. They are not written to a database, to disk or to a cache, and they are not attached to any account, including yours if you happen to be logged in: these requests are sent without cookies. Our application log records that a calculation ran, how many data points it had and how long it took — no values, no address — and we count how many requests each tool answered and how many we refused, as totals with no address in them. The web server in front of it writes no access log for these requests, and they are excluded from our request tracing. One exception, and it exists to keep the tool working: when the web server turns a request away because it arrived too fast, it notes that refusal — including the address it came from — in its error log, so an attack can be seen while it is happening. A request that is answered leaves no such line. The response tells your browser not to store it. Close the page and the result is gone; we could not show it to you again.

Nobody else receives it. No third party receives your numbers or anything computed from them. In particular, nothing is sent to Google Vertex AI or to any other AI service: the public tools do no AI processing at all. The AI coaching described in Section 5 exists only inside a member account and only with the separate consent described there. The pages load no third-party scripts, fonts, maps or trackers.

Abuse protection. So that the tools stay available, we count requests per source address. Our application holds a keyed hash of your address — not the address — in a memory-only store, and the entry expires within the hour. The web server in front of it additionally keeps the address itself in working memory for a short time (typically about a minute) to smooth bursts; it is not written anywhere. Legal basis: our legitimate interest in keeping the service available (Art. 6(1)(f) GDPR, Recital 49).

Legal bases, in short. Computing the figures you asked for is the service you requested, so we process the performance data and your entries to deliver it (Art. 6(1)(b) GDPR). Rate limiting runs on legitimate interest (Art. 6(1)(f) GDPR). The heart-rate part happens on your device and we receive nothing from it; the tick that starts it is your explicit consent (Art. 6(1)(a) and Art. 9(2)(a) GDPR) for that processing in your own browser.

Your rights, honestly stated. Because we keep nothing and attach nothing to you, we cannot find "your" analysis afterwards and cannot identify you from it (Art. 11 GDPR). So there is nothing for us to give you access to, correct or erase — and equally, nothing that could later be handed over, breached or repurposed. Your other rights, including the right to lodge a complaint with a supervisory authority, are described in Sections 8 and 9. If you want your rides kept, compared and coached over time, that is what an account is for; the rest of this policy describes what changes when you open one.

Under 16? Use the public tools with your parents' agreement.

Not a medical device. The tools describe what is in your file. They do not assess your health and are not a medical device — see Section 5 of our Terms of Service.

7. Data Retention Periods

We retain your data for specific periods based on purpose and legal requirements:

7a. Automated Decisions and AI Coaching (GDPR Art. 22)

The AI coaching feature produces individualised training recommendations (target weekly load, ride structure, rest-day suggestions, post-ride verdict). These outputs always remain advisory: every recommendation is generated automatically, it never changes your structured plan without your action, and you can override or ignore any AI suggestion at any time.

For this reason, our AI coaching does not constitute a "decision based solely on automated processing, including profiling, which produces legal effects ... or similarly significantly affects" you within the meaning of GDPR Art. 22(1).

Independently of that, you always have the right to:

• Request human review of any AI-generated recommendation by emailing the address in Section 1.
• Express your point of view about an AI recommendation and have it considered by a person on our team.
• Contest an AI recommendation -- which in practice means: stop using it, request a manual plan adjustment from us, and/or revoke AI consent (Section 5).

We log AI requests for 30 days (Section 5) so that human review can re-construct what the model was shown when generating a contested recommendation.

8. Your Rights

Under GDPR, you have the following rights regarding your personal data:

9. How to Exercise Your Rights

Self-service (immediate):

• Export all your data: in the app, open Profile → Export my data to download a complete JSON file of all your personal data (Art. 20 portability). The same export is available programmatically via GET /api/auth/export.
• Delete your account: in the app, open Profile → Delete my account (a two-step confirm) to permanently and irreversibly delete all your personal data (Art. 17 erasure). Programmatically: DELETE /api/auth/account.
• View retention policy: §7 of this Privacy Policy lists every retention period; the machine-readable form is GET /api/auth/data-retention, which returns the current periods as JSON.
• Update your profile: in the app, correct identity fields under Profile → Account and training metrics under Profile → Physiology. Programmatically: PUT /api/auth/profile.
• Revoke AI consent: POST /api/ai/revoke-consent -- immediately stops AI data processing
• Revoke health-sync consent: DELETE /api/consent/health-sync (or the "Revoke health sync consent" button in the companion Sync tab) -- immediately stops the companion app from reading and uploading data from Apple Health or Google Health Connect, including the background path described in §4
• Inspect your consent ledger: GET /api/consent -- returns the full history of consents you have granted or revoked, with policy version and timestamps
• Revoke email consent: in the app, open Profile → Account → Email preferences and toggle it off — the change takes effect immediately
• Turn off the daily reminder notification: Open the companion Sync settings → toggle "Daily morning reminder" off, or set its time to a slot you're never available. The toggle takes effect immediately; no server round-trip.
• Disable location permission: Revoke it in the OS-level Settings app (iOS: Settings → Brevet Cycling Club → Location; Android: Settings → Apps → Brevet Cycling Club → Permissions → Location). The rest of the platform continues to work; outdoor workouts will surface with the OS's indoor-mode distance estimate.
• Revoke background health reads: Same path as above — revoke the per-data-type or background-access toggle in Apple Health (iOS) / Health Connect (Android). On iOS the companion will additionally call disableAllBackgroundDelivery() at the next launch so iOS stops queueing wake-ups.
• Opt out of companion telemetry: Email privacy@brevetcycling.club requesting telemetry opt-out. Admins toggle the flag through the audited support flow; the change takes effect on the next companion launch and pending local-queue crashes are drained once on the way out (so a crash that triggered your request isn't lost).

By email:

For any request you cannot complete self-service, or if you wish to exercise your right to restriction or objection, contact us:

Email: privacy@brevetcycling.club

We will respond to your request within 30 days as required by GDPR Art. 12(3). If your request is complex, we may extend this by a further 60 days, but we will inform you of the extension within the initial 30-day period.

We may need to verify your identity before processing your request to protect against unauthorised access.

10. Cookies, Sessions, and Device-Local App Storage

Brevet sets four first-party cookies on the web side — all of them functional, none of them tracking:

• We do not use tracking cookies, analytics cookies, or advertising cookies.
• We do not use browser fingerprinting.
• All four cookies are strictly functional (login, request integrity, login-notification noise reduction, app-shell detection). They fall under the §25(2) Nr. 2 TDDDG exemption, so no consent banner is required.

Spotify music control (opt-in — device-local tokens)

If you connect Spotify to control playback during a ride, the Spotify OAuth tokens are stored in your browser's local storage on your own device (a PKCE public-client flow — there is no Spotify secret on our servers). They are used only to control your own playback and never leave your device except in the direct calls your browser makes to Spotify. Because this storage is strictly necessary for the music service you explicitly requested, it falls under the §25(2) No. 2 TDDDG exemption; no consent banner is required. Disconnecting Spotify, or clearing your browser storage, removes the tokens.

Embedded YouTube player (opt-in theme — consent-gated)

The four cookies above are the only cookies Brevet sets, and all are functional. The optional YouTube visual theme is different: when its embedded player loads, YouTube can set third-party cookies and read or write information on your device. Those are not strictly necessary and do not fall under the §25(2) TDDDG exemption, so we do not load them by default.

Instead the player is gated by click-to-load: it stays a static placeholder describing what will happen until you take an explicit, prior action ("Load player & continue"). Only then does the embed load — from the privacy-enhanced domain youtube-nocookie.com, which defers tracking/advertising cookies until playback. That action is the §25(1) TDDDG consent for the device access and the Art. 6(1)(a) consent for the data Google then receives as an independent controller (see §6 and §11). Your choice is remembered for the current browser session only, so each new session re-confirms it; switching away from the YouTube theme stops the embed loading.

Podcast player (opt-in theme — device-local only)

The optional podcast theme keeps everything about your listening on your own device, in your browser's local storage under the key brevet-podcast:

None of it is sent to us and we hold no copy: we do not know which shows you follow or what you have listened to. That is a deliberate design decision rather than an omission. A list of the podcasts someone follows is a map of their interests, and podcast catalogues carry politics, faith, health and sexuality on the cover — so the safest place for that list is the one where we cannot read it. The cost is stated rather than hidden: your shows do not follow you from one device to another. If that ever changes it will be an explicit opt-in with its own entry in this policy, never a silent upgrade.

"Remove" clears one subscription; clearing your browser storage clears everything at once. Because this storage is strictly necessary for the player you explicitly asked for, it falls under the §25(2) No. 2 TDDDG exemption; no consent banner is required.

News board (opt-in theme — device-local, and nothing leaves your browser)

The optional news board shows headlines from feeds you choose. It is the most contained surface we ship, and the detail is worth stating because most people assume the opposite of a news reader:

• Your browser contacts no news site at all. We fetch the feeds from our own server and hand your board the headlines. A newsroom therefore never sees your address, your device or the fact that you read them — only that Brevet asked for its feed.
• Nothing is embedded. The board renders text: no images, no trackers, no article pages, no scripts from anyone else.
• Your source list stays here, in your browser's local storage under the key brevet-news, together with the marks for which headlines have already been shown. We hold no copy, so we do not know what you read. A list of the news someone follows is a political profile; the safest place for one is where we cannot read it.

The starter list is a suggestion, not an endorsement — every source is removable and the board is perfectly happy empty. Because this storage is strictly necessary for the board you explicitly asked for, it falls under the §25(2) No. 2 TDDDG exemption; no consent banner is required.

Device-local app storage (companion app only)

The companion app stores a small number of values on your device for the app itself to read — these are NOT cookies, NOT analytics, hold NO health data, and never leave the device:

Deleting the companion app removes all of these. Revoking health-sync consent additionally clears the permission-related entries. Revoking telemetry opt-in additionally drains and clears the local crash queue.

11. International Data Transfers

Your data may be transferred to or processed in the following locations:

For transfers outside the European Economic Area (EEA), we rely on EU Standard Contractual Clauses (SCCs) as approved by the European Commission, or other appropriate safeguards under GDPR Chapter V.

We do not use any LLM provider other than Google Vertex AI today (OpenAI, Anthropic, Microsoft Azure OpenAI, AWS Bedrock, self-hosted Gemma / Llama / Mistral, etc. are all out of scope). The LLM inference itself happens on Google Cloud's EU infrastructure under the safeguards listed above, never on a US-region Vertex endpoint.

12. Changes to This Policy

We may update this privacy policy from time to time. When we make material changes:

• We will update the "Last updated" date at the top of this document
• For significant changes, we will notify you via email (if you have email notifications enabled) or display a notice on the Platform
• Continued use of the Platform after changes take effect constitutes acceptance of the updated policy
• If changes affect your health data processing or AI data processing, we will request renewed consent

13. Contact and Data Protection Officer

If you have questions, concerns, or wish to exercise your rights:

General inquiries: privacy@brevetcycling.club

Data Protection Officer: no DPO is currently appointed — see §1 for the documented threshold assessment and its revisit triggers. All data-protection matters reach us at privacy@brevetcycling.club.

Supervisory authority: You have the right to lodge a complaint with your local data protection authority if you believe we are processing your personal data unlawfully.

This privacy policy is written in clear, plain language in accordance with GDPR Art. 12 (transparent information). If any part is unclear, please contact us and we will explain it.