Children's Code Conformance Statement

Why this statement exists

The ICO's Age Appropriate Design Code — the Children's Code — applies to online services likely to be accessed by children. SailCoach is not merely likely to be accessed by children: most of our sailors are under 18, and the racing data at the heart of the product is overwhelmingly Optimist-class, a fleet sailed by eight- to fifteen-year-olds. The code applies to us squarely, and it is the standard against which we expect to be judged.

This is our self-assessment against its fifteen standards.

It is based on a line-by-line audit of the SailCoach source code carried out on 17 September 2026. Where it says a control exists, there is code behind it. Where it says one does not, we looked for it and it was not there. No standard is yet fully met, one is not applicable, and two are plain failures.

Innovology Ltd is the data controller and is registered in England and Wales. We have not appointed a Data Protection Officer. Our assessment is that our current size and scale of processing sits below the Article 37 threshold for mandatory appointment — but given the volume of children's data we hold, we regard that as a close call, we keep it under review, and we will appoint if the scale grows.

Summary

Standard 1 — Best interests of the child

Status: partly met.

Several decisions in this product were made in children's interests and can be evidenced in code, not only in intention:

• There is no directory of sailors. The only people-search over accounts is by exact email address or phone number; a name does not find anyone. A child cannot be found by browsing or filtering users. One route falls short of that, and we name it here rather than leave it to standard 9: any signed-in person can type an arbitrary sail number and get back the names and race history attached to it. Sail numbers are short and guessable, so that is a way of finding a child by guessing, and closing it is on the register.
• A coach's public page never names the sailors they coach. The projection that builds it is a whitelist, and sailors are not on it.
• Nothing behind a sign-in is indexed by search engines, by explicit rule rather than by accident.
• A guardian can never send a message as their child. The permission is refused unconditionally.
• Guardian oversight ends automatically on the child's eighteenth birthday.
• Head-to-head rivalry comparisons are hidden for sailors under 13.
• Medical notes appear on a squad roster only as a tick, never as text. The day view shows the words only to the coach running that sailor's group. There is no CSV, no print view and no email path for them.

Where we fall short: there is no server-side age assurance (standard 3); a child has no route inside the product to raise a concern that is not attached to a specific message (standard 6); the day-view restriction on medical notes does not hold everywhere, because any coach listed on a squad can open any member's page and read their medical note on any day, whether or not they are running that sailor's group; and any adult who shares a club with a child can open a private conversation with them without a connection, without guardian approval and without anyone being notified. That fallback was built for club-wide and emergency broadcasts and was never restricted to them.

We regard that last point as the most serious gap in this statement. Restricting the same-club conversation fallback to broadcast conversations only is the first safeguarding change on our register.

Standard 2 — Data protection impact assessments

Status: partly met.

A DPIA covering children's data is published at Data Protection Impact Assessment. It covers the high-risk processing we identified: precise location data about named children, special category health data, criminal-records data about coaches, adult-to-child private messaging, profiling of children, large-scale collection of published results about children who have never signed up, and transfers to processors outside the UK.

Honesty about the history: no DPIA existed before 17 September 2026. Processing children's data at this scale without one was itself a failure of this standard, and the DPIA was produced as part of correcting it.

Why this is not scored as met. The standard asks us to assess and mitigate. A DPIA that exists is the start of that obligation, not the discharge of it, and most of the mitigations it identifies are still on the register. The standard also expects children's views to be taken into account, and this statement was written entirely by adults: no sailor, parent or coach has been consulted. Those consultations are dated in the DPIA — coaches and parents by 31 March 2027, young sailors by 30 June 2027. This standard moves to met when the consultations have happened and the items under standards 3, 8, 9 and 15 have landed.

We will review it at least annually, and immediately on any of: a new processor, a new profiling output, the introduction of named grade bands, a change to how adults may contact children, or the launch of paid plans.

Standard 3 — Age appropriate application

Status: not met. This is the clearest failure in this statement and we are recording it as a failure, not as a risk.

The code asks us either to establish age with a level of certainty appropriate to the risks, or to apply the standards to all users.

What exists. Date of birth is asked for at registration. A sailor who says they are under 18 is asked for a parent or guardian email. An account with no date of birth is treated as a minor everywhere in the product — oversight fails closed rather than open, which is the right default and is genuinely implemented.

What does not exist.

1. The registration rules are enforced in the browser only. The service that actually creates accounts declares both date of birth and parent email optional. A request sent directly to the signup endpoint creates an account with neither. There is no server-side age assertion anywhere in the platform.
2. The parent email we collect is an unverified hint. Nobody emails it. A child can name a parent at signup and that parent is never contacted. It is only ever acted on if that adult independently registers and verifies the same address.
3. A sailor can edit their own date of birth through the ordinary profile form. A thirteen-year-old who sets it back twenty years removes, in a single request, their guardian's access to their profile, to coach notes about them, to their session membership and to their message history — with no notification to the guardian and no alert to anyone.

Our previously published privacy notice stated that "for users under 18, we require parental consent". That was not true of the system as built, there has never been a parental consent flow, and the claim has been removed rather than re-worded.

What we will do, in this order:

• lock date of birth against self-editing: once set, a change by a sailor recorded as a minor requires a guardian or an administrator, and notifies the guardian;
• make date of birth required and validated on the server, not in the browser;
• verify the parent or guardian email before a self-registered minor can connect to an adult or send a message;
• until all three are live, continue to apply this code to every user regardless of declared age, which is what the fail-closed minor rule already does for the oversight gates.

We will record the date each of these lands in a future version of this statement.

Standard 4 — Transparency

Status: partly met.

What we have done. Privacy for young sailors is written for a reader of about eleven, in the second person, and covers the things a child actually wants to know: who reads their notes, what their parent can and cannot do, what happens to photographs of them, and what to do if something feels wrong. The adult set — Privacy Policy, Cookies and storage, Subprocessors, AI and automated decisions — sits alongside it.

Non-essential storage is now gated behind consent, so the notice precedes the collection rather than following it. The banner offers reject and accept with equal prominence, and a Global Privacy Control signal from the browser is treated as a refusal without a prompt. Until 17 September 2026 a permanent anonymous identifier was written to a child's browser on first page load, before any notice was shown.

Where we fall short.

• Until this version, the published privacy notice was materially incomplete — it did not mention scraped results, GPS tracks, medical notes, IP addresses, video, criminal-records data or a single processor — and it contained the false parental-consent statement above.
• We do not yet provide short, in-context explanations at the moment a child enters data — on the medical-note field, the weight field, or the sharing choices made when connecting to a coach.
• The reading level of the young sailors page is our own estimate. No child has been asked whether it works.

What we will do. Add just-in-time explanations to those three fields, and review the young sailors page with actual sailors of that age before the next version rather than assuming we have hit the reading level.

Standard 5 — Detrimental use of data

Status: partly met.

The place we could most plainly do a child harm is by rating them. The Helm Grade does exactly that: it estimates a sailor's standing in the fleet from their race results.

Protections that exist in shipped code, and that we commit to keeping:

• Bands are unnamed neutral quintiles. A percentile is never labelled "Club", "National" or "International". A raw circuit percentile has not earned those words. Named bands are gated behind a calibration tool that must first demonstrate predictive accuracy; it has not yet passed, and we will not ship named bands before it does.
• Uncertainty is drawn, not hidden. The statistical confidence in a rating is shown on the face of it.
• Below roughly the 55th percentile, nothing normative is said at all. A sailor in the lower tiers receives no headline telling them anything about their standing. This is described in the code as a tested contract rather than a stylistic preference, and we treat it as one.
• After a sailor is told they are ready to step up, their first two events or ninety days at the larger fleet are held in a neutral state — so a promoted child's first mid-fleet result at a bigger regatta cannot read as a fall backwards.
• Self-reported results can never trigger the step-up verdict. Only officially published results and tracked races can.

Where we fall short.

• A coaching-relationship health score bands a named child as "at-risk" when what it actually measures is how often their coach has logged anything. It applies a safeguarding word to a child because of an adult's inactivity. We are renaming it.
• Error-session replay records the screen on a sample of sessions, and on every session where an error occurs. Since 17 September 2026 every word of text is masked and all media is blocked before the recording leaves the browser, and replay only attaches for someone who has accepted analytics — so a replay shows layout and interaction, not the content of a note about a child. Before 17 September 2026 it recorded on-screen text unmasked, which on this platform could mean a child's coaching or medical note. Whether replay should run on signed-in pages at all is still an open decision on the DPIA register.

Standard 6 — Policies and community standards

Status: partly met.

What we uphold. Our published standards are at Terms, Acceptable Use, Code of Conduct and Safeguarding Policy. In the product: a message cannot be edited or deleted by anyone, so what was sent stays sent; every message sent is written to an audit log with the account, the time, the IP address and the device; and coaches are deliberately not moderators — reviewing reported messages exposes the content of private conversations including children's, so it is an administrative trust-and-safety function held by club and system administrators, not a coaching one.

Where we fall short.

• The automated check on message content is a seven-word profanity list. A module containing contact-detail, secrecy and meeting-request patterns exists in the codebase but is not called when a message is sent. It will detect swearing and nothing else. We will wire the pattern check into the send path and route matches to a human rather than only setting a flag.
• Reporting a message does not reach a person. The report is stored and the message is flagged, but nothing notifies anybody, no screen in the product displays the queue, and a report on a one-to-one conversation is not visible to a club administrator at all — only to us, by querying the database. A child who uses Report today has told a database, not a human. Nothing in the product should be relied on for this: the route that reaches a person is [email protected].
• A report is logged without the reporter's IP address or device, even though a message send is. That is the record a safeguarding investigation most needs and it is the one we do not capture.
• Safeguarding and DBS certificates are recorded but never enforced. The credential model itself is good — certificates are typed rather than free text, verification is the club's to give and never the coach's to claim, editing a certificate re-voids its verification, and expiry is tracked. But nothing anywhere blocks on the result. A coach with no certificates at all is functionally unrestricted. We will make DBS and safeguarding status a club-configurable requirement that can gate coach-to-minor connection, messaging and squad assignment.
• A coach's free-text credentials are still unmarked. The self-asserted "Background Check" field is gone (below), but the free-text "certifications" box on a profile, and the qualifications list on a public coach page, are typed by the coach, checked by nobody, and displayed without anything saying so. Labelling every credential as verified or unverified is on the register.
• The only in-product report path routes to the child's own club — which is the wrong destination when the concern is about someone at that club. Our independent route is [email protected]. That inbox is monitored every working day, acknowledged within one working day, and the escalation procedure behind it is written down in Safeguarding Policy. There is no named welfare officer role in the data model; adding one, with an out-of-club escalation path, is on the register.

Closed in this release. A legacy self-asserted field used to let a coach set their own "Background Check: APPROVED" and have it displayed to parents as a fact, alongside and indistinguishable from the club-verified record. On 17 September 2026 it was removed: the profile update schema rejects it outright, a test pins that behaviour, and the field is gone from the interface. Nobody can set or change it. Values recorded before this release may still sit on old records and are not displayed; clearing them is on the register.

Standard 7 — Default settings

Status: partly met.

Where the default is already high-privacy.

• Nothing optional is stored on a device until the visitor has chosen. Analytics and error-session replay both sit behind a consent banner with equally weighted accept and reject controls, and a preference panel that can be reopened at any time from the Cookies and storage page. Both categories start off. A browser sending Global Privacy Control is not asked and gets nothing. Withdrawing consent, or signing out, deletes what was stored under it. Until 17 September 2026 analytics and replay ran for everyone, including children, from the first page load with no consent and no off switch.
• A coach's profile is not public unless the coach chooses it. We deliberately did not migrate an older "visible" setting into the new public-profile field, because the old setting only ever meant "visible to other signed-in members" and never "on the internet". Nobody was published who did not choose to be.
• All photographs and video sit in a private store behind short-lived links. A link is only minted after an access check on the record the file belongs to — the note, the session or the event. Separately, the server refuses to store a file reference that does not sit under the uploader's own prefix, which blocks the common trick of borrowing someone else's file reference to get a working link back.
• A sailor shares nothing with a coach until they choose what to share, item by item.
• Body weight is optional, private by default, recorded by a parent for under-13s, and never plotted as a trend line.
• Squad grading is not visible to parents by default.
• A coach's session write-up is visible to the sailor by default; hiding it is the deliberate act.

Where the default is wrong.

• A coach note defaults to "shared with everyone on the session." A note about one named sailor requires the coach to actively choose "private". The safer default is the other way round, and we are switching it. This is now the only default in the product we think is wrong, which is why this standard is partly met rather than not met.

Standard 8 — Data minimisation

Status: partly met.

Genuine minimisation already built. A squad roster exposes only a boolean "has a medical note", never the text. Date of birth, phone number, medical notes, emergency contact and parent email are stripped out before a merely-connected coach or peer sees a profile — a fix for a real bug in which a bare connection leaked a minor's medical data. No child's name is sent to our AI provider on any path: every prompt refers to "the sailor" and instructs the model never to guess a name, and where several coaches' feedback is synthesised they appear only as "Coach 1", "Coach 2". Group-level insights additionally have names stripped from the text itself before leaving the platform. Guardianship invitations are sent by email only and never as a shareable link, because a URL carries too much authority for whoever happens to hold it.

Where we hold more than we need.

• Every analytics event stores a full IP address and user-agent string, for children as well as adults. A ninety-day expiry exists in the codebase but is attached to a collection name that is never written to, so it does nothing at all. Treat current analytics retention as indefinite until that is fixed and verified — we will not publish a retention figure we cannot evidence.
• GPS tracks of named children are written to durable storage with no expiry and described in the code as the authoritative record.
• Published race results are retained including the original page HTML, for provenance.
• A club administrator can download the whole club membership as a spreadsheet — every member's name, email address, date of birth and parent's name and email address, minors included, in one request, with nothing recorded to say it happened.
• Free-text boxes about a child are unbounded and unclassified. That is where health information is most likely to enter the system outside the two designated medical fields, and nothing lints, redacts or flags it.

What we will do. Truncate or drop the IP address at analytics ingest; create and verify a working retention index; set and then implement retention periods for GPS tracks and scraped results (see Data Retention); and log, restrict or narrow the club membership export.

Standard 9 — Data sharing

Status: partly met.

What holds up. We do not sell personal data. There is no advertising network, no ad SDK and no third-party analytics product anywhere in the codebase — the analytics are entirely first-party. Sharing between a sailor and a coach is opt-in and itemised. A guardian gets read access to a minor child, not write access, and it ends at 18. Every processor we use is now listed at Subprocessors.

Where we fall short.

• Until this version, none of our processors were disclosed at all.
• Children's coaching prose is sent to an AI provider in the United States, with the child and the coaches unnamed. Prose written about one identified child does not stop being about them because the name has gone, so this is still a transfer of personal data. Nothing in our systems evidences a data processing agreement with the provider; putting one in place, with a transfer mechanism, is on the register.
• Voice notes use the browser's speech recognition. On Chrome that streams the child's voice to Google before the transcript reaches us. A comment in our own code claimed "no upload"; that was wrong, and it has been corrected, as have the Privacy Policy and the AI page. What is still missing is the disclosure at the point of use: nothing on the dictation screen tells a child, before the microphone starts, where their voice is going. This was the least well disclosed flow in the audit.
• Thousands of children are in our results corpus because we collect published results, and they were never told. Article 14 of the UK GDPR requires that they are, unless the disproportionate-effort exemption applies. We rely on that exemption, which obliges us to publish the information instead — Privacy Policy now does. The objection route is the privacy mailbox and it works. What does not exist is a technical suppression list, so a removal has to be re-applied by hand after each collection run; building the technical list is on the register.
• Any signed-in user can resolve an arbitrary sail number to a child's name and full race history. That is not restricted to the caller's own numbers, it is not rate-limited, and the lookups are not recorded — so misuse would leave no trail. Restricting, rate-limiting and logging it are all on the register and none of the three is built.

Standard 10 — Geolocation

Status: partly met.

We do not track children's devices. There is no background location collection and no live location sharing between users. Nothing in the product shows one user where another currently is, and there is no setting that could make a child's live location visible to anyone.

Precise location of a child does exist, in one form: GPS tracks from regatta tracking systems, attributable to a named sailor via their sail number. Those tracks are visible to the sailor, to their guardian while they are a minor, to an administrator at their club, and to a coach only where the sailor has shared their events. They are never public. They are historic race data, recorded by the regatta organiser's equipment, not by us.

Where we fall short.

• One form asks the browser for the sailor's current position automatically when it opens — the post-sail training log, which uses it to guess the venue. The browser does prompt for permission and a refusal is handled cleanly, but under this standard the request should be made only when the sailor asks for it. We are changing it to a button.
• GPS tracks have no retention limit (standard 8).

Venue coordinates are sent to a weather and geocoding service. Those are the coordinates of a sailing venue, not of anyone's home.

Standard 11 — Parental controls

Status: largely met. This is the strongest area in the product.

• The child's own record holds the link. A parent cannot attach themselves to a child; the link is written only by server-side flows and never from anything a client sends.
• A maximum of two guardians per child.
• Invitations are sent by email only, never as a shareable link, on the explicit reasoning that a URL carries too much authority for whoever ends up holding it.
• Read parity, not control. A guardian sees what the child sees — profile, coach notes, sessions, race analysis, message history — and may reply to a coach's note. They cannot write the child's reflection once the child owns the account. For a parent-created account that has not yet been handed over, the guardian is the sole operator and may write reflections recorded as the child's; the moment the child sets their own password, that stops. We think the handover should be more visible to the child than it currently is.
• A guardian can never speak as the child. The permission to send a message in the child's voice is refused unconditionally, for every guardian, in every circumstance, whether the account is parent-managed or self-owned. This is a deliberate safeguarding control and it holds.
• Oversight ends automatically at 18. Every gate combines guardianship with a live age check; after the birthday the link survives only so the family still appears on a dashboard, and grants no data access. Two qualifications. The adult threshold is a deployment setting — 18 in production — not a constant in the code. And because a missing date of birth is treated as "minor" so that oversight fails closed, an account with no date of birth never reaches the sunset at all: the fail-safe default praised under standard 3 is a fail-open default here. Requiring a date of birth on the server closes both.
• The child is told all of this in their own words, at Privacy for young sailors.

Where we fall short.

• The code asks for an obvious sign to the child when a parent can monitor them. A guardian can read a minor's entire message history and the child sees no indicator in the product. We publish the fact; we do not yet show it. We are adding a persistent marker on the messages screen for any sailor whose guardian has oversight.
• A parent is never notified of anything. Not when an adult requests a connection to their child, not when their child is first messaged by someone new, and not when their child's date of birth changes. Oversight is entirely pull: a parent who never opens the right page learns nothing. The architecture makes the right privacy trade-off in keeping parents out of the conversation itself — but it omits the compensating control of telling them the conversation exists. Guardian notifications on those three events are on the register.
• The whole model rests on a self-editable date of birth (standard 3).

Standard 12 — Profiling

Status: partly met.

What profiles a child: the Helm Grade (a Bayesian skill rating replayed from race results), the step-up verdict, the phase profile of where a sailor gains and loses places, a coaching-relationship health band, and the analytics journey — which includes stitching a pre-signup browsing trail onto the account once someone registers.

Protections. The standard 5 list applies in full. In addition: the rating and verdict are readable only by the sailor, their guardian while a minor, an administrator at their club, a system administrator, and a coach only where the sailor chose to share their events. The verdict is advisory — nothing downstream in the product consumes it or acts on it. The rating is a published, deterministic algorithm reproducible from the observation log, not a learned model trained on user data. RYA-style grading levels are awarded by a named human and marked as confirmed by a human; no algorithm assigns anyone a level.

Four commitments we are binding ourselves to, because our assessment in AI and automated decisions that this processing is not high-risk depends on all four remaining true:

1. The Helm Grade and the step-up verdict must not be the sole basis for squad selection, team picks or event entry. They exist to be interrogated by a human, which is why the gates and the underlying events are exposed alongside the result.
2. No named grade bands without published calibration.
3. The below-threshold silence stays.
4. Grading levels remain human-awarded and human-confirmed.

Where we fall short. A sailor cannot switch the rating off. The code expects profiling to be off by default unless there is a compelling reason to have it on. Our reason — competitive standing is the point of the racing section — is an argument for asking, not for assuming. We will add a per-sailor control that hides the grade and the verdict while leaving the underlying results intact, by 30 June 2027. Separately, ratings are computed over identities belonging to people who never signed up, which is the Article 14 problem set out under standard 9.

Standard 13 — Nudge techniques

Status: partly met.

What we do not do. There is no advertising, no follower count, no public like count, no leaderboard of children by name shown to other children, no infinite content feed, and no autoplaying feed. The language rules on the training-to-racing comparison are enforced in code: observational only, never causal, a flat outcome stays flat, and a negative outcome is expressed as a coaching question rather than a verdict.

We no longer dress arithmetic as machine reasoning. Until 17 September 2026 one feature animated "reading feedback… identifying patterns… writing insights…" over a result produced by joining strings together, and a card labelled "AI Insights" was threshold logic with no model behind it. Both were relabelled in this release: the summary now gets an ordinary loading state, the card is "Training Patterns" and is not styled as AI, and the animation appears only over a genuine model call. What is still outstanding is driving every label from a provenance field, so that a future model swap cannot ship silently.

Where we do nudge, and should not.

• A consecutive-days streak, with a flame, milestones, and a "streak freeze" to protect it. That is a standard engagement mechanic and it is pointed at children. It nudges a child to log activity in order to protect a number, which is not the same thing as sailing more. We are reviewing whether to keep it at all; if we keep it, the loss-framing goes.

What we commit to. We will not use notifications, timing, wording or visual design to push a child towards switching off a privacy protection, sharing more than they intended, or staying on the platform longer than they meant to.

Standard 14 — Connected toys and devices

Status: not applicable.

SailCoach supplies no hardware. There is no device pairing, no Bluetooth, no USB and no IoT integration of any kind.

The one thing that might look like an exception is not one: we ingest GPS data from regatta tracking systems. Those trackers are deployed and operated by the race organiser, we have no connection to the device, and we read the resulting data after the event. We are a recipient of published data, not a connected-device operator.

If we ever supply or pair with a device, this standard becomes live and we will reassess before shipping it.

Standard 15 — Online tools

Status: not met.

The code asks for prominent, accessible tools that help a child exercise their data protection rights.

• There is no self-service data export.
• There is no self-service account deletion.
• There is no in-product request form.
• The one administrative deletion route removes the user record and leaves the child's notes, messages, media, sessions, training records, goals and analytics behind. It is not an erasure mechanism and we will not describe it as one.

What operates today is a person, not a product. Requests go to [email protected], or to [email protected] for anything touching a child's safety. We acknowledge within five working days and complete within one month, which is the statutory period under the UK GDPR. A child may make the request themselves; they do not need a parent to make it for them. The process is set out at Your Data Rights.

What we will build, and this is the largest single piece of work in this statement:

• a cascading deletion routine that reaches every collection and every stored file, so that "delete my account" means what it says;
• a data export a sailor or guardian can download without asking anyone;
• a "download or delete my data" control reachable from the sailor's own profile in two taps;
• a child-readable version of the request flow, matching the reading level of Privacy for young sailors.

How we will keep this honest

We will review this statement at least every six months, and immediately whenever the product changes in a way that affects a standard. Each remediation item above will be dated in this document as it lands, and if something regresses we will say that too. A statement that only ever improves is not being written honestly.

Questions or challenges: [email protected]. Anything about a child's safety: [email protected].

If you think we are getting this wrong, you can complain to us at [email protected], and you can complain to the Information Commissioner's Office at ico.org.uk/make-a-complaint at any time. You do not have to come to us first.