Who else handles the data
Four companies receive something from Recov. This page sets out exactly what reaches each of them, what does not, what protects it, and where the processing happens.
Contents
1. The four recipients
| Recipient | What it is for | What reaches them | The thing to know |
|---|---|---|---|
| Anthropic | Generating a squad's training plan from a coach's brief; reading meal photographs; hand-size calibration; importing a plan from a photograph | Squad specialty, age band, goals, description, the coach's brief text, event names and dates, the training pattern, any prior plan, coach comments; meal photographs, the athlete's typed meal description, a photograph of the athlete's hand, photographs of coach whiteboards | No identifiers are sent when a plan is drafted, and a coach's free text is sent as typed. Whiteboard photographs are not identity-stripped, and staff are required not to photograph a board naming children |
| Resend | Sending sign-in and consent emails | Email address, a single-use link, club name, club identifier | Message bodies are structurally incapable of carrying a child's name |
| Amazon Web Services (KMS) | Wrapping and unwrapping encryption keys | A 32-byte encryption key, and nothing else | No row content ever reaches them — not plaintext, not ciphertext |
| Railway | Hosting the application and the database | Everything. This is where the data physically lives | Meal photograph files are held on the application's own storage rather than in the encrypted database columns |
We do not sell data and we do not share it for advertising. There are no advertising or analytics companies on that list because there are none in the product.
The table is a summary; the sections below are the accurate version. A one-line cell cannot carry the distinction that matters most here — the difference between something Recov is structurally incapable of sending and something it merely does not send today. Where the table and a section differ, the section governs.
2. Anthropic — training plans, photographs and meal descriptions
Anthropic is the only AI provider Recov uses. Its models do four things: drafting a training plan from a coach's brief, reading a photograph of a meal, calibrating hand size from a photograph, and importing a training plan from a photograph of a coach's whiteboard. What is sent differs sharply between them — drafting a plan sends no identifiers at all, while importing one from a photograph deliberately sends whatever is written on the board — so the two are set out separately below.
What is sent — drafting a training plan
- The squad's specialty, age band, goals and description.
- The coach's brief, as free text, exactly as typed.
- Event names and dates, and the squad's training pattern.
- Any previous plan being revised, and the coach's comments on it.
What is not sent — drafting a training plan
No identifiers. No child's name, no email address, no date of birth, no account identifier. This is not a filter that strips them out: the data structure sent to Anthropic has no field capable of carrying one, and an automated test holds that shape closed. Structural absence is a considerably stronger guarantee than a filter, because there is nothing for a filter to miss.
No athlete data is sent — no journal text, no soreness log, no injury reports, no results, no recovery markers, no body measurements.
The exception, and it matters
The structural guarantee covers the fields Recov fills in. It does not cover what a person types into one of them. If a coach writes "Maya is coming back from a stress fracture, keep her volume down", that sentence — including the name and the injury — is transmitted verbatim.
Every coach is bound by a written rule not to do this, set out in the club staff notice: write about the squad, the seat, the session or the group, never the child.
What is sent — photographs and meal descriptions
- Meal photographs taken by the athlete, with their hand often in frame, because it is used as a size reference.
- The athlete's typed meal description, verbatim — up to 2,000 characters of their own words about food.
- A photograph of the athlete's hand, for calibration.
- Photographs of coach whiteboards, imported as training plans.
What is not sent — photographs and meal descriptions
Location data. Photographs have their EXIF metadata, including GPS coordinates, stripped when they reach Recov's servers — before the image is stored and before any of it is sent to Anthropic.
Nothing else Recov holds goes with them: not the journal, not the soreness log, not injury reports, not results or effort ratings, not recovery markers, not body measurements, not welfare records.
Whiteboard photographs are not identity-stripped
A coach's whiteboard often names individual athletes, sometimes next to an injury note. Recov does not attempt to remove those names before sending the photograph, because a plan import that redacted the board would import the wrong plan. That is a deliberate decision, recorded in our decision log.
The control is therefore a human one, and it is written into the club staff notice as an obligation: a board that names individual children must not be photographed into Recov.
The structural guarantee covers a drafted plan only; it does not extend to an imported one. When a plan is drafted, identifiers are structurally incapable of reaching Anthropic. When a plan is imported from a photograph, they deliberately are capable of it. Both paths go to the same company, and they do not carry the same protection — so the honest form of this section is the box above rather than a reassurance.
Model training
We select AI providers on the basis that content submitted through their APIs is not used to train their models, and we contract with them on that footing.
3. Resend — email delivery
Resend sends Recov's emails: sign-in links, consent requests and approvals.
What is sent
- The recipient's email address.
- A single-use sign-in or consent token, in the body of the message.
- The club's name and its identifier.
What is not sent
A child's name cannot reach Resend in a message body. This is enforced rather than intended: every body is rebuilt from a fixed template and byte-compared against that template before the message is sent, so a body that has acquired anything the template did not put there does not go out. No athlete data of any kind is sent.
What protects it
The tokens carried in those emails are single-use, stored only as a hash, and expire after seven days. Anyone holding the email holds the link — which is true of every emailed sign-in link anywhere — but not a lasting credential.
4. Amazon Web Services — key management
The most sensitive fields in Recov are encrypted: dates of birth, journal free text, injury report descriptions, session comments, body measurements, and welfare record pattern text. Each value gets a fresh key, and AWS's key management service wraps and unwraps those keys.
What is sent
A 32-byte data key. That is the whole list.
What is not sent
No row content of any kind reaches AWS — not plaintext, not ciphertext. AWS cannot see the data the keys protect, because the data never travels to them.
What protects it
Encryption is AES-256-GCM with a fresh data key per value. Each ciphertext is bound to the row it belongs to, so a value moved to a different row fails to decrypt rather than quietly succeeding. Decryption fails closed. Plaintext is padded into length buckets, so the length of a stored value does not leak from the length of its ciphertext.
5. Railway — hosting and the database
Railway runs the Recov application, its filesystem and its PostgreSQL database. Everything described in every other Recov policy document physically lives here.
What is sent
All of it. Identity data, athlete data, encrypted columns and unencrypted ones alike. Railway is not the recipient of a subset; it is where Recov is.
What protects it
- Identity data and athlete data are in separate database schemas under separate database roles that cannot read each other, and no query joins them.
- Row-level security is forced on all 43 tables, so one club cannot reach another club's rows even if application code got it wrong.
- The encrypted columns are ciphertext to every database role, including an administrator's. The keys are not in the database.
- No IP addresses are stored anywhere in Recov.
Meal photograph files are the exception. The image files are written to the application's own storage rather than into an encrypted database column, so they are protected by the platform's access controls rather than by Recov's field-level encryption. They are deleted seven days after capture — see the retention schedule.
6. Where the processing happens
Recov is built for UK clubs, and our intent is UK processing. Several of these providers operate globally, however, and personal data may be processed outside the United Kingdom.
Where personal data is transferred outside the UK, we rely on the transfer safeguards in that provider's data processing terms: the UK International Data Transfer Addendum to the European Commission's Standard Contractual Clauses, or UK adequacy regulations where they apply to the country concerned.
You can ask us for the current processing location and the safeguard relied on for any individual provider, and we will tell you. Ask through the rights page.
7. What we do not use at all
The shortest way to describe a lot of privacy risk is to say it is absent. None of the following exists in Recov:
- No analytics and no telemetry. No product analytics service, no usage tracking, no error reporting service.
- No advertising of any kind — no advertising identifiers, no ad networks, no data sold or shared for advertising.
- No link to any watch, fitness tracker or fitness account. No Garmin, Strava, Concept2, Whoop, Fitbit, Oura or Polar account is linked to Recov. Wearable sync reads the health app — Apple Health or Health Connect — on the phone or tablet where it is switched on, and sends the numbers only to Recov's servers. It sends none of those numbers to Apple or Google, and Recov gets them from that device, not from Apple's or Google's servers, so neither is a sub-processor for wearable sync.
- No location data, no contacts, no browsing history. Photographs have their GPS metadata stripped on arrival at our servers, before storage and before onward sending.
- No IP addresses stored, anywhere.
- No push notifications from our servers. The app shows two daily reminders (morning check-in and evening logging), scheduled on the phone. They are on unless switched off, and nothing about them is sent to us, so no push service is a sub-processor.
- No font CDN call from the app. Fonts inside the product are served by Recov itself, so loading a page does not tell a third party that you did.
- No menstrual cycle tracking. There is no table, no field and no route, and nothing is collected.
8. Changes to this list
This page is versioned. When a sub-processor is added, removed or changed, the version moves and the effective date changes with it. A club can ask to be notified of changes to this list as a condition of its agreement with us — see the terms of service.
Related reading. How long we keep data — the retention schedule for every category. Your rights, and how to use them — how to ask us anything on this page, and how to complain if the answer is wrong.
What changed in version 1.2 (10 October 2026). Section 7 now describes wearable sync and why Apple and Google are not sub-processors. No recipient was added or removed.
Version 1.2 · Effective 10 October 2026 · Last reviewed 10 September 2026 · Audience: everyone