Privacy

SoignAI — legal entity formation pending is the controller for the data described here. Questions, or any of the requests in Your rights: soignai.app@gmail.com.

Soignai is in private beta. Accounts exist by invitation only. Requesting access is free; accepted closed-beta access is priced at €14.99 / $14.99 per month, and payment is collected only after an invitation and before app access once billing is enabled.

• Closed-beta request — before an account exists, a request holds your first name, email address, primary discipline, whether you use Intervals.icu, the amount of training history you say is available there, your recent training frequency, and any optional note about what you want SoignAI to help with. It is used only to review and run the closed-beta cohort and to contact you about that request. No Intervals.icu credential is collected in this form. If you do not join the beta, the request is kept only while closed-beta recruitment is active, unless you ask us to delete it sooner.
• Account — email address, first name, and the timestamp at which you gave consent. Your password is stored only as a hash, by Supabase Auth, and is never visible to us.
• Consent history — each time one of your consent choices changes (the health-data consent, the separate consent to keeping timed GPS positions, or switching Use ride GPS to build my Atlas off or back on), one record is added: which choice changed, its previous and its new timestamp, where the change was made (sign-up, the consent screen or the Atlas setting) and the account that made it, where that is known. Records are only ever added, never edited, so the history keeps consent times that a later choice replaced. It is kept to show what you agreed to and when, and for nothing else: it holds none of your health, training or location data, and it does not change what your consent covers. It is in your export and is deleted with your account.
• Profile — weight, height, year of birth, sex, objective and target weight, weekly training hours, your per-day-type energy figures, protein target and calorie floor; the kinds of day you define and the activities you put in each one — the sport, how hard, how long and the time you usually start — together with any time you move one of them to on a single date; any dates you give for not training; your morning weights, and the optional morning check-in answers you enter for upper body and lower body (fresh, normal, heavy or sore), fatigue (low, normal or high), mood and a note — together with the legs (fresh, normal or heavy) and soreness (none, mild or significant) answers the earlier check-in recorded, kept as they were; an optional Health/Illness answer (no symptoms, mild symptoms or significant symptoms) with the exact symptoms you select, the local day, time and time zone of your report, and a history of edits. An unanswered field is not recorded as healthy. These are your reports, not diagnoses; optionally your body-fat percentage; and anything you tell us about how you eat — dietary pattern, allergies, foods you will not eat. These exist to compute your targets and to keep suggestions safe, and for no other purpose.
• What you log — meals and their components with weights, energy and macronutrients; the day’s type — and, where you change it, the kind it was before — and active energy; sessions, together with the record of a ride described below where one came from a ride file or from a training platform you connected; and the personal food list built from your corrections.
  
  A manual activity keeps the activity and intensity you chose, its start and duration, and any distance, average power, incline, effort or note you add. To make its energy estimate reproducible, it also snapshots your most recent recorded weight, the activity-catalogue version and MET value used, the raw active and gross estimates, the rounded figure shown to you, and any quality flags. Editing creates a correction history; deleting the activity permanently removes that whole history. If a synced session turns out to be the same workout, it replaces the manual activity in your day's totals — both records are kept, and you can undo it. If you delete a synced session, the identifier it was imported under is kept so the next sync does not bring it back; it is in your export and is deleted with your account.
• Experimental calculation history — private validation, when enabled, can retain a candidate assessment together with the wellness and check-in facts it used and the planned session context observed at that time. These experimental assessments do not guide your training or change your plan. Production collection is currently disabled. Retained calculation history is included in your account export and removed with your account; correcting a source answer does not rewrite an earlier calculation.
• A connection you make — if you connect intervals.icu, the connection itself: your athlete number on their service, when you made it, when it last fetched anything, how far back it has read, and when it ended. The key you paste is held encrypted, is never shown back to you, and is not in your export. It is described below.
• Pictures you send — two sizes of each photograph, whether it is a plate, the summary screen of a head unit a session was read from, or a food or packet you add to your Pantry. Described below.
• Your conversations — the messages you send and the replies to them, kept against the day they belong to, together with the entries that were proposed and whether you accepted them. This is what lets a day you open next month still show how it was logged.
  
  For meal-analysis cards, we also keep a provenance record linking a saved meal to the model output and the component-level corrections made to it. A card you discard keeps only non-content run metadata; its food details are not copied into this record. Historical backfills do not claim editing time or interaction counts. These records are in your export and are deleted with your account.
• Your Pantry, your Patterns and how you prefer to eat — the foods and products you add to your Pantry with what you told us about them (a usual portion, the figures on a packet, what a homemade item is made of, your notes); the meal patterns you create or confirm, with their usual components and amounts; and the preferences you state on Plates, such as cuisines you enjoy or fuelling products you avoid. All of it is yours to edit, archive or delete there.
  
  Alongside them we keep a record of how each meal you log compares with a pattern of yours — what you swapped, left out or added — and a short list of questions the app has for you as a result, with your answers. These are worked out by fixed rules from your own entries, not by an AI model, and nothing they suggest changes a pattern or your Pantry unless you accept it. All of this is in your export and is deleted with your account.
• What the app has concluded about you — short statements inferred from what you log, such as when you tend to eat or which meals run light on protein, together with what each one is based on. They are written by an AI model from your own records, are rewritten periodically, and are shown to that model so its replies are about you rather than about nobody in particular.
  
  You can read every one of them on your profile page, edit any of them, and delete any of them. Anything you write or correct is kept as yours and is left alone when the rest are rewritten; anything you delete is not inferred again. Alongside them we keep the day-by-day notes those statements are drawn from, and a record of any occasion the app’s safety limits were triggered — kept so we can tell whether those limits are working.
  
  Your Training Profile keeps the facts you enter or confirm about your usual training week and Day Types. If you turn on Profile Intelligence, fixed rules may also infer proposed facts and routine variants from your ride history. Each fact keeps whether it was observed, inferred, confirmed, entered or is still unknown, together with its evidence window and confidence. No AI model performs this extraction, and a confirmed or entered fact is never silently replaced by a later inference. These records are in your export and are deleted with your account.
  
  For the day you are on, we also keep the shape of what is still ahead of it: a calorie figure and a protein, carbohydrate and fat split for each meal you have not logged yet. They are worked out by arithmetic from your own last four weeks — no AI model is asked — and they are never counted as food you have eaten. You can change any of them or remove them, and they are gone at the end of the day either way.
  
  When one of them ends, we keep a note of what was expected against what was actually logged, so the figures get better at describing you. It holds no food names and nothing you wrote. It is never shown back to you as a score, a streak or a percentage, and it never will be: it exists to make next week’s numbers closer, and for nothing else.
  
  For a session, we work out what to take on before, during and after it, and keep those figures as they stood when they were worked out rather than recomputing them later — so a plan you read last month still says what it said. They are in your export and are deleted with your account.
  
  We also keep the versioned training strategies considered for you, the proposed changes to an active plan, and an append-only record of what was accepted, rejected or observed. When a compiler-native Plan is created, we keep its frozen inputs, verified results and exact session artifacts so an earlier accepted plan can be reconstructed. We also keep a dated record of when a planned session was matched to one of your rides, released or replaced, which holds only identifiers and times, never ride data. These records preserve which version was used and what changed. Full-season planning also keeps the saved strategy alternatives, each accepted revision, your weekly history-coverage confirmations and your choice about automatic calendar extension. These are in your export and are deleted with your account.
  
  If you confirm that a training block matches the narrow group VO2max sessions are approved for, we keep your training-block applicability confirmations (VO2max eligibility): the block’s start and end dates, your yes/no answers to the five conditions, and which wording you confirmed. We never ask for or keep your date of birth. A change or a withdrawal is kept as a new record rather than editing the old one, so an earlier plan can be explained. These confirmations are used only to decide whether VO2max sessions may be planned in that block and to show you why. They are never sent to an AI model, to analytics or to telemetry. They are in your export and are deleted with your account.
  
  Strength sessions we recommend, whether you accept or decline each one, the strength sessions you accept (with the sets you report doing) and any strength assessments are kept as a revision history, together with the inputs and versions they were worked out from. They are in your export and are deleted with your account.
  
  Objectives you explicitly set are kept as an append-only revision history, including their title, status, target where one exists, date, source and confirmation. They belong to you and can outlive a training Plan. A Plan’s intermediate target and a metric you merely Watch are not stored as Objectives unless you explicitly promote them. Objective revisions are in your export and are deleted with your account.
• How you arrange it — which charts you keep on your trends page, in what order and at what size. It is a description of how you like to look at the rest rather than anything about you, and it is kept so the page you built is still there next time. It is in your export and is deleted with your account.
• Operational records — one row per AI call, holding the model name, token counts and cost. It exists to enforce usage limits and to know what the service costs to run. It contains no food, photo or profile content.
  
  Alongside them, a short note whenever your account passes 80% of one of those limits, so we can raise it before the app stops answering you. Such a note says only which limit, the two figures, the date, and your account number — never anything you logged, wrote or photographed. It is included in your export and is deleted with your account.
  
  The same operational row may also hold request details such as the requested model, whether the call succeeded, timing, provider reference, retry count, and cost attribution. These details describe the AI call, not what you asked it about, and contain no food, photo or profile content.

This is the part worth reading closely.

It applies to every photograph you attach, not only to food: a screenshot of a ride or a run is handled, kept and deleted in exactly the way described here, and is saved with the session it was read from rather than with a meal. The last point covers ride files from a head unit, which are handled differently from photographs and are not uploaded at all.

• The photo is resized to 1568 px on the long edge and re-encoded in your browser, before it is sent anywhere. Re-encoding discards EXIF metadata, including GPS coordinates.
• The resized image is sent to Google (the Gemini API) to be read, as listed in “Where it is processed”. Alongside it goes the state of the day: its type, your energy target, what you have logged so far with its macronutrients, the names and times of the meals already on the day, your local clock, and the seven days to today as energy logged against energy targeted. That context is what the reply is written from — it is why it can say what the rest of the day should look like rather than only what was on the plate. Your name, email address and account identifier are not sent, and neither is any thumbnail.
• The image that is read is not stored. The 1568 px version is held for the length of the request and discarded when the response comes back. It is never written to a database or a file store.
• Two smaller copies are kept. Your browser makes both, from the already-resized image, so neither carries EXIF or location. A 160 px thumbnail of a few kilobytes is saved with the meal, so your log is recognisable rather than a list of names. A 768 px copy — large enough to see what was on the plate, or to read the figures off a head unit — is saved so you can open the photograph again from the entry.
• The thumbnail is stored in the database. The 768 px copy is stored in a private file store, both in Ireland, under the same protections as everything else here. The file store is not readable by anyone holding a link: opening a photograph asks the app for it, the app checks the entry is yours, and issues an address that stops working after a minute.
• Every photograph of an entry is kept, not just the first. If you send two pictures of one plate and they are logged as one meal, both copies of both are saved with it and both are shown when you open it. Until recently only the first was kept and the rest were read and discarded.
• Both are deleted when you delete the entry, and both are deleted with your account. A photograph you attached to a message but never saved as an entry stays in that day’s conversation, where you can see it, and is deleted with your account like the rest of it.
• What is otherwise kept is the result you accept: the food names, weights and numbers.
• A ride file is read in your browser and never uploaded. When you attach a .fit file from a head unit, it is opened and read on your device. The file itself is not sent and is not stored, and the second-by-second position track it contains, which usually begins and ends at your home, is sent only if you separately agree to timed GPS retention when you import it. An unaccepted ride’s timed position object expires after seven days. What is otherwise sent is the summary of each session in it and the record of the ride described in the next section, which is more than a summary and is set out there rather than here.

Your ride record can hold elapsed duration separately from moving time. Each saved version of a ride also keeps its sport, where its energy figure came from and that figure, and a fingerprint of its stored power curve (a hash, not the curve itself), so a plan can tell which version it saw; these versions are deleted with the ride and included in your account export. Where personal Section records are retained, their source links, effort summaries and processing history belong to your account and are included in your account export.

This part changed on 3 September 2026, and it is a widening. Until then a ride left behind the few figures a summary holds. It now leaves a detailed record of how you rode, and that record is health data in the same sense the rest of this page is.

• Two things are kept beyond the summary. The first is your best average power over each of thirty-two lengths of effort, from one second to five hours — and again after each 500 kJ of work, so that what you could do late in a long ride can be told apart from what you could do at the start of it. The second is a trace of the ride in five-second steps: power, heart rate, cadence, altitude, temperature and distance. Together they are roughly twenty to eighty kilobytes for a ride.
• They exist to work out what you can hold for how long, what a session cost you, and what to eat around it, and for no other purpose. Where a figure drawn from them reaches a coach, that is the disclosure described further down, and nothing reaches anyone unless you have given that access.
• The five-second measurements record does not hold your position. A ride file is read in your browser; under your separate timed-GPS agreement, its recorded positions and times are staged privately. An intervals.icu sync asks the service for named measurements; it asks for position only if you have agreed to your GPS tracks being kept (the location consent described in the next section), and without that agreement it never asks for position at all. The measurements record described here never holds a coordinate, a route or a place name either way: where a ride happened is kept, if at all, only as that ride’s own map track or timed evidence, described in the next section.
• It is stored with the session it belongs to, in the same database, under the same protections. It is in your export, it goes when you delete the session, and it goes with your account.
• Past rides you import from an archive can leave a fuller record, only with your agreement. If you have agreed to the current wording, importing your ride history keeps a high-resolution, non-geographic record of each ride: power, heart rate, cadence, speed, distance, altitude, gradient, climb rate, temperature, respiration, cycling dynamics and e-bike motor power, as the file recorded them. It never holds your GPS position, a route or a place name. Deleting a ride does not delete this record, which stays with the imported file the ride came from until you delete your account. It is in your export, and it is never sent to our analytics or telemetry. If you have not agreed to the current wording, nothing of this kind is kept: a ride keeps only the five-second measurements record already described above. The same agreement covers importing your wellness entries from intervals.icu, which therefore pauses until you agree again.
• A ride file read before that date left only the summary, and no record was made of it afterwards — a file is read on your device and discarded, so there is nothing to go back to. Rides fetched from a connected service can be read again, because they are still held on that service.

This part is new since 22 September 2026, and it is a widening. Until then nothing about where you rode was kept anywhere in this app. Everything here depends on the separate location consent: routes you bring, and — since 28 September 2026 — the tracks of rides a connected service holds, fetched with each ride’s other measurements. Without that consent none of it is kept.

• A route you bring. You can upload a GPX file describing a ride you plan to do. The path it describes is kept, simplified for storage but not otherwise changed, together with its distance and its climbing. Replacing the file keeps the one you replaced rather than overwriting it — nothing you have already imported is ever rewritten — and removing a route from your account archives it rather than hiding that it once existed; it is gone for good, like everything else here, only when your account is. You can name a climb, descent or rolling section within a saved route. That name is kept separately from the route geometry, included in your export, and deleted with your account.
• Save a past ride as a route. If that ride already has a saved GPS track, you can choose to make a new route from it. The new route keeps a copy of that track geometry and records which ride and track source it came from. The historical ride and its track stay unchanged. This action does not fetch more GPS data.
• A ride’s own track — where you actually rode — is kept only with your location consent. Since 28 September 2026, if you have agreed to GPS tracks being kept, a connected intervals.icu sync fetches each ride’s position record together with its other measurements — one request per ride — and keeps it with that ride, including for rides already imported. Without that agreement no position is ever requested or kept. The track stays attached to the ride it belongs to: it is never turned into a planned route unless you choose to save it as one, and it goes when the ride or your account goes.
• Timed GPS for your own Section history. With a separate agreement from 29 September 2026, newly acquired ride evidence keeps every recorded position with its elapsed source time in a private, compressed object. It is separate from the simplified map track. Missing or malformed timing and evidence beyond the published size limits are marked unavailable or unrankable rather than shortened. The object and its metadata are included in your account export and removed with the ride or account. Removing a planned Route does not remove a recorded ride or its track.
• Neither is trimmed at the start or the end. A route often begins or ends at home. We do not cut those ends off, because this is your own record, visible only to you under the same row-level protection as everything else on this page, and never shared or published by this app — a coach you give access to sees the figures described elsewhere on this page, never a map. Trimming would matter once a route or a track could be shown to somebody else; nothing here does that.
• Drawing either one loads a map. The map itself — the roads and place names under your route — comes from OpenFreeMap, a public map-tile service, described further in “Where it is processed” below.
• Where on a ride you ate, drank, refilled or stopped, and how the ride felt. After a ride you can place what you ate or drank on it, mark a refill or a café stop, or tell us a stop we noticed in your ride file was not one. We keep only where on that ride it happened — the distance from the start, and the moment in the ride worked out from it — beside the ride. What you ate stays the meal you logged, with its own time; no second copy of it is made, and no position is copied out of the ride’s track. You can also note how the ride went — fueling felt good, an energy dip, a rough stomach, thirst, too much or too little to drink — in your own words if you like. These are kept as what you said, never turned into a diagnosis or a fixed fact about your body, and you can change or remove any of them. A stop we detect from gaps in your ride file is only a suggestion, and is not stored at all until you confirm or reject it. You can also say which bottles you carried — their size, what was in them, how much you drank if you remember, and roughly where on the ride each one was in use; we keep that as you reported it, and never turn it into a fluid or salt target. Where we suggest a spot on the ride for something you logged eating, we keep that suggestion, and each earlier one, apart from where you say you actually ate it, so a suggestion is never mistaken for what happened.
• Both are stored with the route or the ride they belong to, in the same database, under the same protections as everything else here. Both are in your export. Removing a Route archives it and does not remove a ride track. Deleting a ride deletes its track; deleting your account deletes all of it. If you pin a ride comparison in Trends, we keep a reference to that exact calculation, without copying its data into another store.

Atlas can bring in your past rides from an account export — the archive Garmin or Strava lets you download — or from activity files you choose. Nothing is imported unless you start it.

• The archive is kept only while it is being read. Your browser uploads it directly to private, temporary storage in the same Supabase project described in “Where it is processed”. It is never public, and only our server reads it. It is deleted as soon as its import has been processed. An upload that is interrupted, fails, is cancelled or is never finished expires 72 hours after it began and can no longer be read from then on; an hourly clean-up deletes it at its next run, so it is gone no later than about 73 hours after it began. If the storage service cannot be reached at that moment, the next hourly run tries again. Deleting your account deletes it at once. It is not copied into the backups described in “How long it is kept”.
• What is kept from it. Only activities are read, and one that is plainly not a ride — a run, a swim — is skipped and not stored; nothing else in the export is kept. Each cycling activity becomes a Ride in your history — including a ride recorded without a power meter, whose mechanical work is recorded as unknown rather than estimated from calories — unless it matches one you already have. An activity whose sport cannot be told is kept only as the record below and never becomes a Ride. For each activity read we also keep a small record of where it came from (the service or file, the file’s name within the archive, the device, its start, duration and distance) and how it was matched to your rides, so the same ride is never imported twice and a ride you deleted is not brought back.
• Where you rode is used to build your Atlas, by default, if you have given the location consent. With that consent, and unless you switch it off, Atlas uses the GPS positions in imported activities and in rides a connected intervals.icu account holds, without asking again for each import. From them it keeps an analysis copy of each ride’s track and builds your personal map: the roads and paths each ride followed, matched against a snapshot of the public OpenStreetMap road network, how often and in which direction you rode them, and the sections and corridors made from them. This is what Explore and Scout draw on. Road and Section names may use the snapshot’s public OSM road names, road references and nearby named places. Automatic names are calculated locally from that stored evidence; rendering a Section does not send it to a reverse-geocoder. Without the location consent none of this happens.
• Switching it off. Atlas → World → Connections → Use ride GPS to build my Atlas. From that moment no new GPS is fetched or processed for Atlas: imports still bring in rides, but not where they went, and nothing new is added to your map. Switching it off does not erase what was already built. That stays in your account and in your export, and Explore and Scout can still use it. There is not yet a control in the app that erases it on its own: deleting your account removes all of it, and you can ask for its erasure by writing to soignai.app@gmail.com.
• Where it is kept. Everything above about your rides is stored in your own account, under the same row-level protection as the rest of this page, is included in Settings → Download everything, and goes when your account is deleted. Shared public OSM road and place metadata contains no account data and is excluded from account exports and deletion. The Atlas map loads its tiles from OpenFreeMap exactly as described in “Where it is processed”: what is drawn over it — your rides, routes and map evidence — is never sent to it.

If you start a historical ride import, we keep its date range, progress cursor, your GPS consent and selected stream IDs, plus each activity’s source ID and evidence availability. This lets the import resume and show gaps. The progress record contains no raw performance stream or GPS coordinates; a fetched GPS track remains attached to its recorded ride. Performance streams for older rides are fetched only for rides you select, and only the derived power curve is kept with the ride, as for recent rides. These records are included in your export and removed with your account.

You can connect an account on intervals.icu, a training platform that already receives your rides from your device maker, so that rides arrive here without you exporting a file after each one. Nothing is connected unless you do it, and it is off until you do.

• What is read. Your completed activities and, for those recorded with a power meter or a heart rate strap, the measurements those recorded over the ride; and, with your consent, your daily wellness entries (below). Nothing else is read. Import does not change your account there. If you explicitly choose device delivery through the Intervals bridge and your connection permits writes, the selected workout is sent to its calendar.
• Position is optional. Ride sync asks for named measurements — power, heart rate, cadence, altitude, temperature, distance and time — whenever a ride has any of them, not only when it has power. Position is added to that same request only if you have given the separate location consent; without it, position is never asked for. A historical import follows the same consent check.
• Wellness, only with your consent. If you have agreed to the current wording of this policy, each sync also reads your own daily wellness entries there — sleep duration, sleep score and sleep quality, heart rate while asleep, heart-rate variability, resting heart rate, the service’s own readiness score, the 1–4 ratings for soreness, fatigue, stress, mood, motivation and injury, blood oxygen, breathing rate, the Baevsky stress index and steps — for the last 90 days the first time and the last 14 days after that, so a value that arrives late is picked up. Each value is kept as the service reported it, with its unit, its date and when the service last changed it, including the fact that a field was left empty. It is not turned into a score of ours. Weight and body composition, food and calorie entries, the service’s own fitness and fatigue model, menstrual cycle entries, blood pressure, blood glucose, lactate, hydration and your comments there are not stored even though the service sends them. These wellness days are in your export and are removed with your account. We also record the local day, time and outcome of SoignAI checking Intervals for wellness, separately from when Intervals last changed a value. A check cannot tell us whether your wearable has synced.
• The measurements are not kept as they arrive. They are turned into the record described in the section above and then discarded. The second-by-second stream stays on their service, where it already was.
• The key stays a secret. You connect by pasting a key from your own account settings there. It is encrypted before it is stored, is never shown back to you, is never written to a log, and is not in your export — the export names the connection, not the key.
• Disconnecting ends it. The key is destroyed and no further request is made. The rides already brought across stay where they are: they are your training history, not theirs, and deleting a season of it as a side effect of ending a connection is not something you asked for. Delete a ride, or your account, and it goes like anything else.

The Today page can show the forecast for where you are. It needs a place to do that, and it has none until you give it one: nothing is looked up until you tap “Use my location” or “Add location” and your browser asks your permission.

• What is kept. One place, rounded to two decimal places of latitude and longitude — about a kilometre — and the time it last changed. Never your exact position, never a history of where you have been, and never a place name. The rounding is done before the place is sent to us and again by the database, so a more exact position cannot be stored.
• How it stays current. Once you have set it, and only while your browser already allows this site your location, opening Today may read a coarse position — at most once every half hour, reusing one your device already has where it can — and replaces the kept place only if you have moved more than five kilometres. It never asks you again. If you withdraw the permission, the last place simply stays until you change or remove it.
• Where it goes. The rounded place is sent from our server to MET Norway, the Norwegian Meteorological Institute, to ask for the forecast — with no name, no account and nothing else about you. MET Norway is a public weather service, not a processor of ours; it receives a pair of coordinates and answers with a forecast.
• Removing it. Profile › Training › “Stop using my location” clears it, and it goes with your account. It is in your export.
• Weather along a planned route. This is separate from the one place above. When you prepare or refresh the Before for a planned ride with a route, our server sends MET Norway up to twelve points along that route’s own line, each rounded the same way — to two decimal places, about a kilometre — with the route’s own altitude at that point where it is known. The same points are sent again when you save a change to that Before that re-times the ride (its start time, target time, stops or bike setup, whether you change it yourself or apply a suggestion from the Soigneur); the edit controls say so before you save. Nothing is sent until you take one of those actions; opening the page does not ask. Because this traces the shape of the route rather than one place, MET Norway can infer roughly where you plan to ride that day — still with no name or account. The forecast is kept only inside that ride’s prepared Before, in your own account; it is exported and deleted with it.
• Water, food and repair points near a route. Only where this deployment has turned the feature on. Preparing or refreshing a Before (or saving a change to one whose route has changed since it was prepared) then also sends up to eight rectangular areas covering the route, rounded outward to two decimal places, to the OpenStreetMap Overpass API, to ask what drinking water, cafés, shops and bicycle repair are nearby — nothing identifying goes with the request. What comes back is kept the same way: only inside that ride’s prepared Before, in your own account.

• Database and accounts — Supabase, in eu-west-1 (Ireland).
• The application — Vercel, with server functions pinned to dub1 (Dublin). The pinning is deliberate: the default region is in the United States.
• Backups — Cloudflare R2, in a bucket restricted to the EU. Every backup is encrypted before it leaves, with a key Cloudflare does not hold and cannot be given, so what is stored there is unreadable to them.
• AI model processing — Google, through the Gemini API, which processes it on our behalf under that provider’s standard API terms, and may do so outside the European Union. It receives only what each task needs, and is used for: reading food, portions and figures out of the photographs and messages you send — meals, session screenshots and Pantry items — with the day’s context described above; deciding whether a message in the day’s conversation changes what is logged; reading the allergy or diet words you type, for you to confirm; turning a ride you describe in words in Atlas into route settings, for you to confirm; naming the subject of a question to the Soigneur or from your coach; checking a figure a reply cited against the record it cited; working out per-100 g figures for a food you name that is not in the food list; matching the food names read from a photograph to the food list; noting lasting observations from a finished day’s log and conversation; the day’s conversation and the Soigneur: your messages, with the parts of your record they need; answering a coach you have given access to, from the part of your record you shared; rewriting the profile the app has inferred about you.
• Rides, if you connect them — intervals.icu. Only if you connect it, and only your own account there. We read your completed activities and the measurements recorded during them, using your connected credential; a ride’s position is requested only if you have given the separate location consent, and your daily wellness entries only if you have agreed to the current wording of this policy. What comes back is turned into the records described above and is not otherwise kept. Disconnecting destroys the key held here and ends the reading. If you choose to send a workout through the Intervals bridge and write access is available, the selected workout is sent to its calendar.
• Weather, if you add a place — MET Norway receives the rounded place described above, from our server, to return a forecast. It is not a processor of ours and receives nothing that identifies you. Weather data: MET Norway, under the Norwegian Licence for Open Government Data and Creative Commons 4.0 BY.
• Weather along a route, when you prepare a Before — the same MET Norway, receiving up to twelve rounded points along the route’s own line, with its altitude where known, described above. Sent only when you prepare or refresh that ride’s Before, or save a change to it that re-times the ride. Same terms as the weather location above.
• Route logistics, if this deployment has turned it on — the OpenStreetMap Overpass API, receiving up to eight rectangular areas rounded outward to two decimal places, from our server, only when you prepare or refresh a Before for a route. Nothing identifying is sent. It is not a processor of ours. Data: © OpenStreetMap contributors, under the Open Database Licence.
• Public research, if this deployment has turned it on — the configured public-search provider (currently Gemini with Google Search; Brave Search remains an optional alternative) receives only the public query text after SoignAI has screened it for athlete-specific information. It is used for outside-world facts such as event dates, race and course details, regulations, product specifications and travel or route logistics. Your name, account id, email, training record, health information, performance figures and private Plan context are not sent with that query. Results come back with their source and retrieval time and are treated as public research, never as authority for your physiology, training dose or nutrition.
• Map tiles, if you draw a route or a ride — OpenFreeMap. Your browser asks it directly for the map under a route or a track, without going through our server first, so it receives the area of map you are viewing as you pan and zoom. It never receives your route or your track as data — no coordinates, no polyline, nothing we hold about where you rode is sent to it as a payload. It is not a processor of ours and receives nothing that identifies you. Map data: © OpenStreetMap contributors, under the Open Database Licence, served by OpenFreeMap.

Other configured services may receive data for specific purposes: Resend receives beta-application details and email contents when email delivery is configured; Stripe receives billing details when billing is enabled; and Sentry receives scrubbed error diagnostics when error reporting is configured. Wahoo delivery requires a reviewed connection before it can receive a selected route or workout; direct Wahoo delivery is currently unavailable. Nothing here is sold or advertised against. A coach receives access only when you deliberately grant it, described next.

If you speak a message instead of typing it, your browser’s own speech recognition turns it into text — on your device in some browsers, on the browser maker’s servers in others, under that company’s terms with you. It is not a processor of ours, and we never receive the audio. The text appears in the message box for you to check, and reaches us only if you send it, like anything you type.

You can give a named person — a coach, a trainer — read access to part of your record. Nothing is shared with anyone unless you do this, and it is off until you do.

• You choose how much. Three settings, each including the one before it: what you eat (your days, targets, meals, sessions and energy availability); the same plus your weight, the trend, body fat and your goal; the same plus your photographs.
• Some things are never shared, at any setting — your conversations with the soigneur, the profile the app has inferred about you, and any safety flag it has recorded. There is no option that shares them.
• They can only read. A coach cannot change your targets, your log, your settings or anything else. There is no way for them to request access, and no way for them to find you — the link comes from you.
• You can see when they looked, and the record of it is in your export alongside the grant itself.
• It ends. You can end access at any moment and it takes effect immediately. Access also lapses on its own after 180 days unless you extend it.

Giving access is your disclosure to make, and your consent to it is recorded with the date and what you chose to show. Deleting your account ends every grant.

• Food logging tied to weight and training is health data, and so is a record of your heart rate and power over a ride — special category data under Article 9 of the GDPR. The basis for processing it is your explicit consent, Article 9(2)(a), given by the checkbox at signup and recorded with a timestamp.
• Running the account itself — signing you in, keeping your settings — rests on Article 6(1)(b), performance of a contract with you.
• Consent can be withdrawn at any time by deleting your account, which erases the data rather than flagging it.

Until you delete it. There is no automatic expiry. Deleting your account removes the account and its consent history, profile, days, meals, components, photographs, conversations, sessions and everything kept from the rides in them, manual activities and their estimate histories, any connection you made and the key held with it, the food list and the usage records, in one cascade. It is immediate and cannot be undone.

An Atlas import archive runs the other way: it is kept only until it has been read, and an unfinished one expires 72 hours after it began and is deleted by an hourly clean-up — no later than about 73 hours after it began — as described in “Atlas: importing your ride history” above.

Backups are the one exception, and it is worth being exact about it. The database and the photographs are copied to an encrypted archive several times a day, so that a failure or a mistake does not lose your record. Those copies are kept for 35 days and then destroyed.

Deleting something removes it from the app at once, and it leaves the backups as they rotate — within 35 days, and sooner for anything copied earlier. It cannot be read out of them in the meantime: the archive is encrypted, and the company storing it does not hold the key. Backups exist to be restored after a disaster, not to be searched.

Deleting a single entry removes both pictures of it. The conversation that produced it is a separate record and stays until the account is deleted.

• Access and portability — Settings → Download everything returns every row held about you as JSON, immediately. That includes what is kept from each ride, and it includes every manual activity, its calculation and quality flags, and any connection you have made — when it was made, when it last ran and when it ended. It does not include the key you pasted: a credential is the one thing in this file that is left out, because who could read your record is part of your record and the means of reading it is not.
• Erasure — Settings → Delete account.
• Rectification — every number is editable in the app. Correcting an estimate is the ordinary way to use it.
• Objection, restriction, complaint — write to soignai.app@gmail.com. You also have the right to complain to your national data protection authority; in France that is the CNIL.

Session cookies from Supabase Auth, which keep you signed in. That is all. There is no analytics, no advertising and no third-party tracking of any kind.

If what happens to your data changes, this page changes with it and the date at the top moves. A change that widens the processing will be asked for again, not announced.