Perfect Start privacy notice
The short version: a rider's start is filmed and measured so we can return a replay. Video is short-lived — we delete our copy after 30 days, automatically, every night. Rider history lasts longer. Numeric body points are still personal data while we can link them to a rider. Only telemetry that has been irreversibly anonymised may enter the proposed indefinite research dataset.
Effective date: 26 September 2026 · Version: uk-standard-2026-09-26.
1. Who is responsible
[FULL LEGAL ENTITY, NUMBER AND ADDRESS] is the controller for account, rider-history, service-security and Perfect Start product-improvement processing described here. Email [PRIVACY EMAIL]. Our representative or data protection officer, if required, is [DETAILS]. A club may separately control its roster, attendance, coaching and exported records. Before club launch, the session notice and club data-role schedule will say who is responsible for each use rather than relying on a blanket label.
2. Information we collect
| Category | Examples | Source |
|---|---|---|
| Account and contact | Email, verified Google subject, identity-provider status, account role, support messages | You and Google sign-in |
| Rider and authority | Rider name/display name, age or age band, managing account, relationship and authority, club links | You, guardian, authorised operator |
| Permissions | Capture, cloud storage, club/affiliate access, research, leaderboard, marketing choices; notice/version, granter, time and withdrawal | You or authorised guardian |
| Source media | Video, image, sound, bystanders and surroundings accidentally in frame | Session camera/microphone |
| Derived start data | Body landmark coordinates, wheel/motion tracks, cadence timing, reaction, velocity, launch/jump-start readings, technique traces, replay and confidence/quality information | Our analysis of the recording |
| Session and calibration | Session/run UUID, mode, operator organisation, approximate time, sequence, device/camera/framerate and marker/floor calibration | App and operator |
| Usage, device and security | IP address, browser/app version, requests, sign-in and access/audit events, QR/claim scans, failures, suspected abuse | Your device and our systems |
| Payment | [BILLING CONTACT, PLAN, TRANSACTION AND LIMITED PAYMENT-PROVIDER DATA] | You and [PAYMENT PROVIDER], once launched |
We do not intend to derive identity, health, ethnicity or emotion from body landmarks. Movement can nevertheless be sensitive in context, and applicable biometric laws differ. We will complete a launch-country assessment before offering the service there.
3. Why we use it and our legal basis
| Purpose | Information | Proposed UK basis — counsel to confirm |
|---|---|---|
| Create and secure an account; provide rider history | Account, rider, authority, security | Contract; legitimate interests in security; legal obligation where applicable |
| Capture, analyse and deliver a start | Source media, calibration, derived start data | Contract with the account holder and/or consent where legally required; child flows require a documented assessment |
| Store and show a replay for 30 days | Source/rendered video and access records | Contract and/or consent according to final flow |
| Show a club its own session or shared history | Profile, run, replay, metrics | Separate sharing authority; contract/legitimate interests may support strictly necessary session access but do not replace child safeguards |
| Support, reliability, fraud, security and model-extraction prevention | Account, run quality, logs, limited diagnostic telemetry | Legitimate interests and legal obligations; balancing and child-best-interests assessment required |
| Improve current measurement and create a de-identified research corpus | Telemetry and quality/context metadata | Separate opt-in; any changed approach requires the DPIA and counsel review; anonymous data is outside data-protection law only after effective anonymisation |
| Payments, tax, disputes and legal claims | Account, transaction, audit records | Contract, legal obligation and legitimate interests |
| Marketing or public leaderboards | Contact/profile/result chosen for that feature | Separate opt-in where required; off by default for children |
Where we rely on legitimate interests, you may ask for the balancing assessment and object. Where we rely on consent, you can withdraw without affecting earlier lawful processing. Required and optional fields/choices will be identified at collection.
4. Telemetry, anonymisation and future AI
A landmark file without a name is not necessarily anonymous. Until links and reasonably available ways of singling out or reconnecting the run are removed, we treat it as personal data and apply your rights.
The proposed research pipeline will take only the numeric movement and performance record needed to test and improve measurement. Before indefinite retention it will remove video, replay, audio, contact and profile data, account/rider/club identifiers, exact time/place, persistent run IDs and lookup tables; generalise rare combinations; assess re-identification risk; restrict access; and contractually prohibit re-identification. It will retain the relationship among points within that one performance because that is what makes the run scientifically useful, but not a relationship back to the rider.
If that standard is not met, the record stays personal and follows the finite schedule below. Anonymous records cannot later be searched by rider, so an erasure request cannot retrieve a record already irreversibly anonymised. We will not claim this process is operating until it has been built, tested and documented.
5. Children
We design for riders, including children, rather than pretending only the account holder matters. We will provide a short child-facing notice, high-privacy defaults and choices appropriate to age. We verify the authority required for a parent or legal guardian to manage capture. A club coach or volunteer is not automatically authorised. Children can ask us or the operator questions and can object to filming. We do not knowingly use child data for behavioural advertising or sell it.
For a US launch involving children under 13, we will either implement the notice, verifiable parental consent, parental access/deletion, minimisation, security and retention programme required by COPPA, or exclude that use. A generic waiver is not that programme.
6. Who receives information
- The rider and managing account, for their complete assigned history.
- Session organisation and authorised operators, for a run it operated and only the stated purposes; wider history only when separately shared.
- Perfect Start authorised staff, on least privilege for support, security and approved diagnostics. Impersonation and reassignment should be audited.
- Service providers: Railway [CONTRACTING ENTITY/REGIONS] for application/database/object infrastructure; Google for identity; [EMAIL, SUPPORT, ANALYTICS, PAYMENT, ERROR AND BACKUP PROVIDERS OR “NONE”]. Complete the live subprocessor list at [URL].
- Authorities or professional advisers where reasonably necessary and lawful for safeguarding, security, claims or compliance.
- A buyer/reorganisation party under confidentiality and with notice where required; no reduction of rider rights.
We do not sell rider video or personal telemetry. We do not allow clubs to treat it as their asset.
7. International transfers and storage location
The current prototype uses Railway infrastructure and has used a US deployment. Before launch we will publish the actual region of the application, database, bucket, logs and backups. If UK personal data is transferred outside the UK, we will identify an adequacy regulation or approved safeguard (such as the UK IDTA/Addendum), complete any required transfer risk assessment, and provide a copy or summary on request. Moving the server alone does not remove all transfers: support access and every subprocessor must be mapped.
8. How long we keep it
| Record | Proposed period |
|---|---|
| Source video/audio and rendered replay | 30 days from the recording, then deletion by a nightly scheduled job; earlier deletion on a valid request; [BACKUP AGE-OUT] |
| Unclaimed event recording | [SHORT PERIOD, PROPOSED 30 DAYS] unless securely claimed |
| Account, rider profile and identifiable numeric history | While the profile/account is active, then deletion or anonymisation within [PERIOD], subject to stated legal records |
| Linkable detailed per-frame telemetry | Kept with the rider's history while the profile and account are active — it is what a disputed measurement is re-checked against, and it is deliberately not on the video clock — then deleted or irreversibly anonymised with that history. Deleted immediately on a valid erasure request for the rider or the start. |
| Irreversibly anonymised research telemetry | Indefinitely, reviewed periodically for re-identification risk |
| Consent, assignment, access and safeguarding audit | [PERIOD SET AFTER LIMITATION/SAFEGUARDING REVIEW] |
| Security/application logs | [30–90 DAYS BY LOG TYPE] |
| Payment/tax records | Applicable statutory period |
| Backups | [PROPOSED 35-DAY ROLLING WINDOW]; erasures reapplied if restored |
Legal holds are narrow, documented and access-restricted. We do not keep content merely because storage is cheap.
The two deletions
Deleting a video means two different things here, and we describe them separately rather than blurring them into one promise.
- Server expiry — automatic, ours only. Thirty days after a start is recorded, a scheduled job deletes the source recording and the rendered replay from our storage and marks the record expired. It runs every night, we log each execution and the counts it deleted, and it needs nobody to ask. It removes our copy and reaches nothing else: a recording already saved on a phone or tablet belongs to that device. The start, its measurements and its movement telemetry are not affected — a start outlives its film.
- Permanent erasure — requested, everywhere. The account that holds the rider can ask us to destroy a start's video outright. We delete our copies and record a durable instruction that every device signed in to the accounts responsible for that start applies to its own storage the next time it connects, even after months offline. This is what an erasure request produces; it cannot be undone and the video cannot be recovered.
Only the account that holds a rider — the rider, or the adult managing their profile — can request that erasure for a start assigned to that rider. A club, a coach or the operator whose device recorded it cannot, whatever access they have to view it. Where no rider has been assigned yet, the account that owns the session can. This is the deletion route for a rights request under section 9; the thirty-day expiry happens regardless of whether anyone asks.
9. Your choices and rights
Depending on your country, you may have rights to be informed; access a copy; correct; erase; restrict or object; withdraw consent; obtain portable information; and complain about solely automated decisions with legal or similarly significant effects. Perfect Start does not intend to make such significant automated decisions.
Use [IN-APP CONTROLS] or email [PRIVACY EMAIL]. We may verify identity/authority without collecting excessive information. We normally respond within the legal deadline. A managing adult can act for a child where authorised; a competent child may exercise rights directly. Club unlinking, wider-history sharing, research and marketing controls are separate. Removing club access does not delete the rider's own history.
UK users can complain to the Information Commissioner's Office and may also go to court. [ADD OTHER LAUNCH REGULATORS.] Please contact us first if comfortable so we can try to fix the issue.
10. Security and incidents
We use a private object bucket, opaque storage keys, short-lived download links, authenticated access, role restrictions and audit records as foundations. Before launch we will confirm encryption, key/access management, admin MFA, patching, monitoring, backups, deletion testing and incident response. No system is completely secure. Report a lost device, exposed link or misassigned run immediately to [SECURITY EMAIL]. Safeguarding concerns go to [SAFEGUARDING EMAIL] and emergency concerns to local emergency services.
11. Changes and contact
We will date and version this notice, describe material changes and obtain a new choice if a new purpose requires one. Previous versions will remain at [URL]. Privacy: [PRIVACY EMAIL]. Safeguarding: [SAFEGUARDING EMAIL]. Postal: [LEGAL ENTITY AND ADDRESS].