Security, privacy, and compliance

Compliance status.

Where every compliance item stands as of 19 August 2026. Some of it is built and working. Some of it is written down but not yet enforced by code, and we say which is which. Nothing here is softened.

Why this page exists

When we wrote the first version of our own product description, several of its claims turned out to be wrong. We only found them by opening the code and checking each sentence against what it actually does.

So we did that for every sentence, and we keep doing it. This page is what falls out. It holds four kinds of thing: where each compliance item really stands, claims we had to correct, defects we found while checking, and work we know is unfinished.

What a gap list is worth

A gap we published is a gap we are managing. A gap you found is a gap we were hiding, whether we meant to or not. We would rather be in the first situation, so this is deliberately the least flattering page we have written.

Where each compliance item stands

The whole picture in one table. Read the middle column as the honest answer and the right column as the reason.

Item
Children's privacy law, the reason for our design
Status
Built
What that means
A family is never given a child account, so we collect nothing from a child. A parent describes their own child in their own account.
Item
Verifiable parental permission for a child under 13
Status
Built
What that means
A refunded fifty-cent card charge, a check that the payment belongs to you, a permission record, and a separate yes for each outside company. Set out on the privacy page.
Item
Permission is asked again when the wording changes
Status
Built
What that means
Every permission carries a version, currently 2026-08-26. A newer version sends you back to read it before you can carry on.
Item
Saving each per-company permission
Status
Defective
What that means
The code could not detect its own failure to save. Fixed 2026-08-09; described in the defects section below. We checked the live database and it never affected a real family.
Item
Getting a copy of your data
Status
Built
What that means
A button in settings, twice a day, gathering from thirteen tables. The download link lasts seven days, which is longer than we would now choose.
Item
Deleting your account
Status
Built, partly silent
What that means
Switched off at once, erased after thirty days across thirty-four tables. Since 2026-08-09 a failure in any of them stops the job and it retries, rather than carrying on and reporting success.
Item
Turning off data sharing
Status
Built
What that means
One switch, enforced in your browser and again on our server. Already on for families in California.
Item
How long we keep things
Status
Policy, not code
What that means
Three years for permission records and seven for money records are written down and intended. No job deletes them when the clock runs out. What the code does is strip the personal parts out immediately.
Item
Records nobody can change
Status
Built
What that means
The activity record and the money ledger cannot be edited or deleted by anyone signed in to the app, because the permission to do either does not exist in the database. To be exact about the limit: that protection binds users, not the key our own servers use. What covers our side is the nightly copy into a separate store the app cannot write to, so a later change would show up as a difference between the two.
Item
The lock on every table
Status
Built
What that means
Every table checks who is asking, on each individual row. Two deliberate exceptions are named on the security page.
Item
A second step before money moves
Status
Built
What that means
Approving a payment asks for a code, texted to your phone by default, or from an authenticator app if you choose one. We required the app at first and changed it on 2026-08-19: a payment moves a parent's own money to their own child's account, the rail that would let a thief take it elsewhere is switched off, and requiring an app most parents do not have was buying very little at a real cost. Turning the second step off asks for a code first, so knowing the password is never enough to switch it off. The day a balance can reach an account the family does not control, this gets decided again.
Item
Password strength
Status
Built
What that means
A new password must be twelve characters and is checked against known breached passwords, without the password or its full fingerprint leaving our servers. Accounts made before the rule keep working and meet it on their next change.
Item
Tests that prove the lock works
Status
Now real
What that means
Until 2026-08-09 thirteen tests existed and only one was a real check; the rest could not fail. All fifteen now sign in as real people, run against the live database, and go red if they cannot reach it. The first honest run was eight passes and five failures. All five are fixed and written out below rather than hidden.
Item
Naming every outside company
Status
Two mismatches
What that means
Seven companies are named when we ask permission. One is missing from our published list, and one appears to be named but unused.
Item
State-by-state comparison
Status
Incomplete
What that means
California, Florida, Texas, and New York are tracked. The full comparison of each rule against what we do is not finished.
Item
Review by an outside lawyer
Status
Not started
What that means
Our founder signed off on these pages. An outside engagement is planned and has not happened.
Item
A children's privacy certification
Status
Written, not submitted
What that means
The application is finished and ready. It has not been sent.

Compliance item status as of 19 August 2026
Item	Status	What that means
Children's privacy law, the reason for our design	Built	A family is never given a child account, so we collect nothing from a child. A parent describes their own child in their own account.
Verifiable parental permission for a child under 13	Built	A refunded fifty-cent card charge, a check that the payment belongs to you, a permission record, and a separate yes for each outside company. Set out on the privacy page.
Permission is asked again when the wording changes	Built	Every permission carries a version, currently 2026-08-26. A newer version sends you back to read it before you can carry on.
Saving each per-company permission	Defective	The code could not detect its own failure to save. Fixed 2026-08-09; described in the defects section below. We checked the live database and it never affected a real family.
Getting a copy of your data	Built	A button in settings, twice a day, gathering from thirteen tables. The download link lasts seven days, which is longer than we would now choose.
Deleting your account	Built, partly silent	Switched off at once, erased after thirty days across thirty-four tables. Since 2026-08-09 a failure in any of them stops the job and it retries, rather than carrying on and reporting success.
Turning off data sharing	Built	One switch, enforced in your browser and again on our server. Already on for families in California.
How long we keep things	Policy, not code	Three years for permission records and seven for money records are written down and intended. No job deletes them when the clock runs out. What the code does is strip the personal parts out immediately.
Records nobody can change	Built	The activity record and the money ledger cannot be edited or deleted by anyone signed in to the app, because the permission to do either does not exist in the database. To be exact about the limit: that protection binds users, not the key our own servers use. What covers our side is the nightly copy into a separate store the app cannot write to, so a later change would show up as a difference between the two.
The lock on every table	Built	Every table checks who is asking, on each individual row. Two deliberate exceptions are named on the security page.
A second step before money moves	Built	Approving a payment asks for a code, texted to your phone by default, or from an authenticator app if you choose one. We required the app at first and changed it on 2026-08-19: a payment moves a parent's own money to their own child's account, the rail that would let a thief take it elsewhere is switched off, and requiring an app most parents do not have was buying very little at a real cost. Turning the second step off asks for a code first, so knowing the password is never enough to switch it off. The day a balance can reach an account the family does not control, this gets decided again.
Password strength	Built	A new password must be twelve characters and is checked against known breached passwords, without the password or its full fingerprint leaving our servers. Accounts made before the rule keep working and meet it on their next change.
Tests that prove the lock works	Now real	Until 2026-08-09 thirteen tests existed and only one was a real check; the rest could not fail. All fifteen now sign in as real people, run against the live database, and go red if they cannot reach it. The first honest run was eight passes and five failures. All five are fixed and written out below rather than hidden.
Naming every outside company	Two mismatches	Seven companies are named when we ask permission. One is missing from our published list, and one appears to be named but unused.
State-by-state comparison	Incomplete	California, Florida, Texas, and New York are tracked. The full comparison of each rule against what we do is not finished.
Review by an outside lawyer	Not started	Our founder signed off on these pages. An outside engagement is planned and has not happened.
A children's privacy certification	Written, not submitted	The application is finished and ready. It has not been sent.

Claims of ours that turned out to be wrong

We check our own public claims against the running code one at a time. These are the ones that did not survive the check.

We said
You sign in with a magic link emailed to you.
The code says
You sign in with an email and a password. We only email links to confirm an address or reset a password.
Where it was published
Our internal product document and our public how-it-works page.
We said
The dashboard shows your child's team and school.
The code says
It shows a first name, a status, and a wallet balance. Team and school appear only in our public demo, which runs on invented families.
Where it was published
Our internal product document.
We said
Finishing a pillar releases that pillar's share of the money.
The code says
Every enabled part of the agreement must be finished before the whole payment can be approved. All or nothing.
Where it was published
Our internal product document and our how-it-works page.
We said
The visit tracker loads on ten public pages.
The code says
Nine.
Where it was published
Our internal product document.
We said
We never store a child's exact date of birth.
The code says
Setup asks a parent for it and saves it. The tool that reduces it to an age range only runs when a child completes their own sign-up, which never happens.
Where it was published
Our internal product document and our how-it-works page.
We said
We do not collect a school name for a child under 13.
The code says
The form asks for a school or team for every child, with no age check. This is the most serious wording error on the list.
Where it was published
A public legal page.
We said
There is no free typing box in any AI feature.
The code says
The encouragement screen has a box where a parent describes a feeling for a picture to carry, capped at 280 characters.
Where it was published
Our internal product document.
We said
Every AI surface passes through the safety screen.
The code says
Every note that can reach a child does, and it is screened before it is saved. The short description a parent gives the picture tool does not.
Where it was published
Our internal product document.

Corrected claims
We said	The code says	Where it was published
You sign in with a magic link emailed to you.	You sign in with an email and a password. We only email links to confirm an address or reset a password.	Our internal product document and our public how-it-works page.
The dashboard shows your child's team and school.	It shows a first name, a status, and a wallet balance. Team and school appear only in our public demo, which runs on invented families.	Our internal product document.
Finishing a pillar releases that pillar's share of the money.	Every enabled part of the agreement must be finished before the whole payment can be approved. All or nothing.	Our internal product document and our how-it-works page.
The visit tracker loads on ten public pages.	Nine.	Our internal product document.
We never store a child's exact date of birth.	Setup asks a parent for it and saves it. The tool that reduces it to an age range only runs when a child completes their own sign-up, which never happens.	Our internal product document and our how-it-works page.
We do not collect a school name for a child under 13.	The form asks for a school or team for every child, with no age check. This is the most serious wording error on the list.	A public legal page.
There is no free typing box in any AI feature.	The encouragement screen has a box where a parent describes a feeling for a picture to carry, capped at 280 characters.	Our internal product document.
Every AI surface passes through the safety screen.	Every note that can reach a child does, and it is screened before it is saved. The short description a parent gives the picture tool does not.	Our internal product document.

One we corrected in the other direction

This page used to understate our own privacy

An earlier version of these pages said our general analytics tool recorded page views across the whole site, including the signed-in dashboard. That was true on the day we wrote it.

It is not true now. A fix landed the same evening, adding a list of signed-in areas where analytics must not record anything: the dashboard, setup, the agreement builder, the locked-parent screen, and the staff area. Recording is off there for everyone, separately from your own do-not-share switch.

We are writing it down because a claim that drifts in our favour needs the same treatment as one that drifts against us. A reviewer should be able to see that we corrected it rather than quietly enjoying the better answer.

Defects we found while checking

What
A parent could not see what we hold about their own child.
Severity
Fixed
What it means
Every question the data export asked was scoped to the person asking, so a parent received their own profile and nothing about their child. An under-13 child has no login here by design, which makes the parent the only person who could ever ask — so this was not an awkward right, it was an unusable one. Fixed 2026-08-11: the export now includes each linked child's profile, goals, wallet, school records, stats, encouragement, Study Hall messages, social posts, schedule, learning progress and trips.
What
A parent could not withdraw permission without disputing a charge.
Severity
Fixed
What it means
Withdrawal was honoured everywhere in our code, and no screen ever offered it. A parent's only routes were to dispute the fifty-cent charge on their card or to email us and wait. Fixed 2026-08-11: Settings and Privacy now has a control that withdraws every per-company permission and switches the AI features off immediately. The original consent record is kept, because we are required to be able to show we asked properly.
What
Deleting a child left their login and their assistant conversations behind.
Severity
Fixed
What it means
The erase job removed the profile but never the underlying login account, and some records — including the child's conversations with our assistant — are filed against that login rather than the profile. They survived a deletion the record described as complete. Fixed 2026-08-11.
What
A failure to schedule the erasure was never noticed.
Severity
Fixed
What it means
Removing a child scheduled the permanent erasure for thirty days later, and nothing checked that the scheduling succeeded. If it failed the child was hidden but never erased, the parent was told deletion was scheduled, and nothing reconciled the two. Fixed 2026-08-11: the failure is now recorded and the parent is told plainly to contact us so we can finish it.
What
Anyone signed in could promote themselves and read another child's school records.
Severity
Fixed
What it means
The most serious item we found. Our database rules govern which row a person may edit but not which parts of it, so the field naming your own role was editable by you. Confirmed end to end against our live system on 2026-08-07 and then undone. Corrected in the database on 2026-08-09, and we re-ran the attack afterwards rather than trusting the change: it is now refused, nothing is saved, and ordinary edits like changing your name still work. Detail is in the security-tests section below.
What
Under-13 sign-up could not be completed at all.
Severity
Fixed
What it means
The check for a completed payment permission counted every permission line a family had, then insisted on finding exactly one. A family who had finished every step had eight, so the check errored and told them to go back and finish the steps they had just finished. Fixed 2026-08-09. This is why no family in our system has ever completed the per-company permission step.
What
Our safety check for children's AI was skipped for the children it protects.
Severity
Fixed
What it means
The check worked out whether a child was under 13 from their exact birthday. Erasing that birthday is the privacy protection described above, so any child it had been applied to looked ageless and the check was skipped. One child was in that state. Fixed 2026-08-09 by falling back to the age range, which is what the other four AI features already did.
What
Per-company permission saves could not report their own failure.
Severity
Fixed
What it means
The code asked whether each save was rejected. An ordinary database refusal is not reported that way, so the check never fired: every permission line could fail to save, a parent would be told it worked, and our records would claim a permission we never stored. Fixed 2026-08-09. We also checked the live database, and this never happened to a real family.
What
The erase job hid most of its own failures.
Severity
Fixed
What it means
It works through thirty-four tables. For twenty-five of them a failure was written to a log while the job carried on and reported success, so data could survive a deletion with nobody told. Fixed 2026-08-09: any failure now stops the job and it retries.
What
The under-13 age-range tool never runs.
Severity
Safe to run
What it means
It is wired to a child completing their own sign-up. Under-13 children never do: their parent does the setup, so the exact birthday a parent typed is kept — 10 children as of 2026-08-09. We built the tool to erase them and then did not run it, because we found something worse waiting on the other side: nothing in our system ever moved a child out of the under-13 bracket when they turned 13. Erasing the birthday would have frozen those ten children as under-13 for life, with the evidence of their real age gone. We built the birthday transition first, on 2026-08-10. It records the month a child turns 13 before the birthday is erased, rounds forward so the change is never early, and moves them automatically. Erasing the birthdays is now safe and is the next step.
What
Our break-in tests could not fail.
Severity
Fixed
What it means
A test that always passes is worse than no test at all. Fixed 2026-08-09, and running them for the first time is what found the access-control gaps now listed above. Its own section is below.
What
We ask for a child's email address and have no use for it.
Severity
Medium
What it means
The setup form asks for it and saves it. Nothing we are launching sends a child an email, so this is data collected for no purpose we can defend. It should come off the form.
What
One AI company is missing from our published list.
Severity
Fixed
What it means
Parents agreed to Voyage by name in the permission form while it appeared in neither our vendor inventory nor our privacy policy. Fixed 2026-08-09: it is now named in both, and in the compliance hub's processor table.
What
One company is named but appears unused.
Severity
Closed
What it means
Plaid was on the permission form and unused. Bank linking runs through Stripe. Form caught up 2026-08-26; Plaid is no longer a required consent.
What
The approval step does not check the bank link again.
Severity
Medium
What it means
It checks who you are, whether the payment is yours, whether you are the primary parent, and whether the work is done. The bank-verified check runs when the payment is created, not when it is approved. A balance can be recorded with no real money moving.
What
Anyone in a family can still add a ledger line.
Severity
Medium
What it means
Editing and deleting were removed from the database. The permission to add was left behind from an older version. The ledger is unchangeable once written, but it is not restricted to our server for writing.
What
The data-export download link lasts seven days.
Severity
Medium
What it means
It is a private, unguessable web address emailed to you, and it holds a full copy of your family's data. Seven days is longer than that link should live, and we would now choose hours.
What
The free typing box is capped in the page, not on the server.
Severity
Low
What it means
Two thousand characters in the browser, four thousand accepted by the server. The cap is a courtesy, not a control.
What
Two names for the same field in our records.
Severity
Low
What it means
The AI fingerprint is stored under two different spellings depending on which feature wrote it. A search for one silently misses the other.

Defects found during our own review
What	Severity	What it means
A parent could not see what we hold about their own child.	Fixed	Every question the data export asked was scoped to the person asking, so a parent received their own profile and nothing about their child. An under-13 child has no login here by design, which makes the parent the only person who could ever ask — so this was not an awkward right, it was an unusable one. Fixed 2026-08-11: the export now includes each linked child's profile, goals, wallet, school records, stats, encouragement, Study Hall messages, social posts, schedule, learning progress and trips.
A parent could not withdraw permission without disputing a charge.	Fixed	Withdrawal was honoured everywhere in our code, and no screen ever offered it. A parent's only routes were to dispute the fifty-cent charge on their card or to email us and wait. Fixed 2026-08-11: Settings and Privacy now has a control that withdraws every per-company permission and switches the AI features off immediately. The original consent record is kept, because we are required to be able to show we asked properly.
Deleting a child left their login and their assistant conversations behind.	Fixed	The erase job removed the profile but never the underlying login account, and some records — including the child's conversations with our assistant — are filed against that login rather than the profile. They survived a deletion the record described as complete. Fixed 2026-08-11.
A failure to schedule the erasure was never noticed.	Fixed	Removing a child scheduled the permanent erasure for thirty days later, and nothing checked that the scheduling succeeded. If it failed the child was hidden but never erased, the parent was told deletion was scheduled, and nothing reconciled the two. Fixed 2026-08-11: the failure is now recorded and the parent is told plainly to contact us so we can finish it.
Anyone signed in could promote themselves and read another child's school records.	Fixed	The most serious item we found. Our database rules govern which row a person may edit but not which parts of it, so the field naming your own role was editable by you. Confirmed end to end against our live system on 2026-08-07 and then undone. Corrected in the database on 2026-08-09, and we re-ran the attack afterwards rather than trusting the change: it is now refused, nothing is saved, and ordinary edits like changing your name still work. Detail is in the security-tests section below.
Under-13 sign-up could not be completed at all.	Fixed	The check for a completed payment permission counted every permission line a family had, then insisted on finding exactly one. A family who had finished every step had eight, so the check errored and told them to go back and finish the steps they had just finished. Fixed 2026-08-09. This is why no family in our system has ever completed the per-company permission step.
Our safety check for children's AI was skipped for the children it protects.	Fixed	The check worked out whether a child was under 13 from their exact birthday. Erasing that birthday is the privacy protection described above, so any child it had been applied to looked ageless and the check was skipped. One child was in that state. Fixed 2026-08-09 by falling back to the age range, which is what the other four AI features already did.
Per-company permission saves could not report their own failure.	Fixed	The code asked whether each save was rejected. An ordinary database refusal is not reported that way, so the check never fired: every permission line could fail to save, a parent would be told it worked, and our records would claim a permission we never stored. Fixed 2026-08-09. We also checked the live database, and this never happened to a real family.
The erase job hid most of its own failures.	Fixed	It works through thirty-four tables. For twenty-five of them a failure was written to a log while the job carried on and reported success, so data could survive a deletion with nobody told. Fixed 2026-08-09: any failure now stops the job and it retries.
The under-13 age-range tool never runs.	Safe to run	It is wired to a child completing their own sign-up. Under-13 children never do: their parent does the setup, so the exact birthday a parent typed is kept — 10 children as of 2026-08-09. We built the tool to erase them and then did not run it, because we found something worse waiting on the other side: nothing in our system ever moved a child out of the under-13 bracket when they turned 13. Erasing the birthday would have frozen those ten children as under-13 for life, with the evidence of their real age gone. We built the birthday transition first, on 2026-08-10. It records the month a child turns 13 before the birthday is erased, rounds forward so the change is never early, and moves them automatically. Erasing the birthdays is now safe and is the next step.
Our break-in tests could not fail.	Fixed	A test that always passes is worse than no test at all. Fixed 2026-08-09, and running them for the first time is what found the access-control gaps now listed above. Its own section is below.
We ask for a child's email address and have no use for it.	Medium	The setup form asks for it and saves it. Nothing we are launching sends a child an email, so this is data collected for no purpose we can defend. It should come off the form.
One AI company is missing from our published list.	Fixed	Parents agreed to Voyage by name in the permission form while it appeared in neither our vendor inventory nor our privacy policy. Fixed 2026-08-09: it is now named in both, and in the compliance hub's processor table.
One company is named but appears unused.	Closed	Plaid was on the permission form and unused. Bank linking runs through Stripe. Form caught up 2026-08-26; Plaid is no longer a required consent.
The approval step does not check the bank link again.	Medium	It checks who you are, whether the payment is yours, whether you are the primary parent, and whether the work is done. The bank-verified check runs when the payment is created, not when it is approved. A balance can be recorded with no real money moving.
Anyone in a family can still add a ledger line.	Medium	Editing and deleting were removed from the database. The permission to add was left behind from an older version. The ledger is unchangeable once written, but it is not restricted to our server for writing.
The data-export download link lasts seven days.	Medium	It is a private, unguessable web address emailed to you, and it holds a full copy of your family's data. Seven days is longer than that link should live, and we would now choose hours.
The free typing box is capped in the page, not on the server.	Low	Two thousand characters in the browser, four thousand accepted by the server. The cap is a courtesy, not a control.
Two names for the same field in our records.	Low	The AI fingerprint is stored under two different spellings depending on which feature wrote it. A search for one silently misses the other.

Every one of these was found by us, by reading the code rather than the documents. None was reported by a user or by an attacker.

Our security tests, in full

We have thirteen tests that try to reach data they should not. Until 2026-08-07 every one of them was worthless, and on that date we rewrote them and ran them against the live database for the first time. A reviewer will ask what they really prove, so here is the whole answer rather than a number.

Why the old green result meant nothing

They passed when they did not run. The test runner never loaded our database credentials, so every test stopped early and reported success. A test that stops early is recorded as passed, not as skipped. Every green run in this project's history proved nothing, because none of them ever reached a database.

Four of them could not fail. Each accepted three outcomes as success and one of the three was always true, because of how the database library reports a row count when it was not asked for one. They would have passed against a completely open table. Two of those four also aimed at a record that does not exist.

Seven were empty placeholders that asserted something true of themselves, and one merely checked whether some settings were present.

All of them now sign in as real people, attempt the thing they are meant to prevent, and then read the record back to confirm nothing moved. They fail loudly if they cannot reach the database, so a run that proves nothing is red rather than green.

The first real run was eight passes and five failures. We left those five failing rather than quieting them, fixed the causes over the following two days, and the suite now passes fifteen of fifteen against the live database. What each failure turned out to be is below, because the findings are more useful to a reviewer than the score.

What we found
Anyone signed in can make themselves a coach, join any team, and read those children's school records, including their grade average.
Severity
Fixed
Status
We confirmed this end to end against our live system and then undid it. The cause is that our database rules control which row a person may edit but not which parts of it, so the field naming your role was editable by you. Corrected 2026-08-09. Our first attempt at the correction ran without error and changed nothing, which we only caught because we re-ran the attack instead of trusting it. A person may now change 42 of the 54 things on their own record, and not the twelve that grant access or assert a verification.
What we found
A coach could read the school records of children on their own team.
Severity
Fixed
Status
Our own written rule says grades are for parents and athletes and never coaches. The rule that shipped allowed it. Nothing in the product ever used that access, so on 2026-08-09 we removed it and the database now matches what we had written down.
What we found
A coach could not message a child directly through the app, but nothing in the database stopped it.
Severity
Fixed
Status
The block was real but it lived only in the application, and the application is not the only way in. The database now enforces the same rule: an individual message requires the child to be on that coach's roster, and a message to an under-13 child is refused outright. Messaging a 13-or-older athlete on your own team still works, which we test for so the guard cannot quietly break the thing it wraps.
What we found
A removed child's goals were still visible to their parent.
Severity
Fixed
Status
Three rules governed reading goals and the database applies whichever one permits. Two of them checked whether the child had been removed; the original, written earlier, did not, so it granted access every time and removal hid nothing. Removing that leftover rule on 2026-08-09 closed it.
What we found
A child can read their own money history.
Severity
Not a fault
Status
Our documentation described this as parent-only. It is the child's own record and reading it is not a leak, so the documentation was wrong rather than the rule, and we corrected the documentation. The test now checks the thing that does matter, which is that one child cannot read another child's money history.

What the five failing tests found, and what happened to each
What we found	Severity	Status
Anyone signed in can make themselves a coach, join any team, and read those children's school records, including their grade average.	Fixed	We confirmed this end to end against our live system and then undid it. The cause is that our database rules control which row a person may edit but not which parts of it, so the field naming your role was editable by you. Corrected 2026-08-09. Our first attempt at the correction ran without error and changed nothing, which we only caught because we re-ran the attack instead of trusting it. A person may now change 42 of the 54 things on their own record, and not the twelve that grant access or assert a verification.
A coach could read the school records of children on their own team.	Fixed	Our own written rule says grades are for parents and athletes and never coaches. The rule that shipped allowed it. Nothing in the product ever used that access, so on 2026-08-09 we removed it and the database now matches what we had written down.
A coach could not message a child directly through the app, but nothing in the database stopped it.	Fixed	The block was real but it lived only in the application, and the application is not the only way in. The database now enforces the same rule: an individual message requires the child to be on that coach's roster, and a message to an under-13 child is refused outright. Messaging a 13-or-older athlete on your own team still works, which we test for so the guard cannot quietly break the thing it wraps.
A removed child's goals were still visible to their parent.	Fixed	Three rules governed reading goals and the database applies whichever one permits. Two of them checked whether the child had been removed; the original, written earlier, did not, so it granted access every time and removal hid nothing. Removing that leftover rule on 2026-08-09 closed it.
A child can read their own money history.	Not a fault	Our documentation described this as parent-only. It is the child's own record and reading it is not a leak, so the documentation was wrong rather than the rule, and we corrected the documentation. The test now checks the thing that does matter, which is that one child cannot read another child's money history.

What this section is for

None of these five would have been found by the tests as they were written. They were found in the first hour the tests could actually fail, and closed within two days. We would rather publish that sentence than have a reviewer arrive at it on their own.

One detail is worth repeating because it is the lesson rather than the result. Our first attempt at the most serious fix ran without any error and changed nothing at all, for a reason specific to how database permissions combine. We caught it only because we re-ran the attack afterwards instead of trusting that a command which did not complain had worked.

Work we know is unfinished

Code from the platform we built first

We built a larger platform before narrowing to what we are launching. Code from it is still in our repository. None of it is part of what a launching family is given, and none of it is described anywhere in these pages. Taking it out of the code is unfinished, so a reviewer reading our source will find more there than a launching family can reach.

The protection that does not depend on finishing that cleanup is the one that matters: a family is never given a child account, so no child ever signs in and no child ever types anything, whatever else is still in the repository.

How a family marks progress

A parent cannot tick a box themselves. The database refuses a direct write from a parent account, which is deliberate: the person who benefits from the answer should not be the person recording it. Our staff can apply and reverse progress, and every action is written to a permanent record.

Which route a launching family uses day to day is a design decision we have not settled. It is open, it is not a bug, and a reviewer should ask us about it.

Time limits that are policy, not code

We say we keep permission records for three years and money records for seven. No job deletes them when the time is up. What the code does is keep them with the personal parts stripped out. That is stricter in one sense, because the personal information goes immediately, and weaker in another, because the rows stay.

The state-by-state comparison

California, Florida, Texas, and New York are tracked. The full comparison of each rule against what we do is written down and not finished.

About eighty coding shortcuts

Our own rules forbid quietly substituting a default value when data is missing, because it hides bugs instead of showing them. About eighty of those remain from earlier work. None is a security hole. We are clearing them file by file rather than in one risky sweep.

Outside review

What
Review by an outside lawyer
Status
Not started
What
Children's privacy certification
Status
Written, not submitted
What
Security certification
Status
Not started
What
Break-in testing by an outside firm
Status
Not started
What
Cyber insurance
Status
Under review

Independent review status
What	Status
Review by an outside lawyer	Not started
Children's privacy certification	Written, not submitted
Security certification	Not started
Break-in testing by an outside firm	Not started
Cyber insurance	Under review

The companies that run our machines hold their own security certifications. That covers the infrastructure underneath us. It says nothing about our own code, and we do not present it as though it does.

What is not on this list

One thing is worth saying clearly, because the length of this page could give the wrong impression.

Not one gap here involves a child's own data

Nothing on this page is about information a child gave us, because a child never gives us any. No child signs in. No child types.

The gaps are about our own record keeping, our own test coverage, our own documentation, and finishing a cleanup we already decided on. They are real and we are not minimising them. They are a different category from a child's data being exposed.

What we are asking a reviewer to tell us

Is one adult account per family enough for districts and leagues in our target states, and what evidence will each district want to see?
Which items on this page must close before a paid launch, and which can close before a wider rollout?
Should we get the children's privacy certification before talking to districts, or at the same time?
What data retention periods will each district require, and do our current holds conflict with any district policy?
What outside proof will districts expect: break-in testing, a security certification, a completed questionnaire, or something else?

If you are reading this as part of a review, the fastest way to be useful to us is to answer those five, and to tell us which line on this page you would move to the top. Our own answer is the test suite described above.