What Mothy holds about a child, and how to check it
Mothy is an AI that reads and writes about children: daily logs, case records, statutory deadlines, safeguarding concerns. Most of the public conversation about child AI safety is about the other kind of system, the kind children talk to. This page is mainly about ours, because the failure modes are just as real: a system that asserts things about a child it cannot evidence, or holds things about a child that nobody can find, check or erase.
One part of the product is used by children, and we would rather say so here than have it found. In Chrysalis Luna, our tool for foster carers, a looked-after child can be given their own login and keep a private journal. What is true of it today: no model writes to them, answers them or comments on what they write, and what they write cannot be read by their carer, their supervising social worker or the agency, which is enforced by the database rather than by a screen that declines to show it. One model does touch it: a child who would sooner talk than type can dictate an entry, which turns their own speech into their own words and keeps no recording. A design that would add journalling prompts, weekly patterns and a check for whether a child seems unsafe is written down and is not built. None of it will be put in front of a child before a safeguarding professional has been through it and told us what is wrong with it.
This page says what Mothy does and does not hold about a child, which controls enforce that, which of those controls are running today, and how to check our claims. It also says what we do not claim. If you find a gap between this page and the product, we want to know: email hello@getmothy.ai and we will respond, and correct whichever one is wrong.
The rule
Mothy knows what you told it and what your records say. It never invents facts about a child. Everything it holds about a child is tagged to that child, so it can be shown, corrected and erased in one action.
That is three tiers, and the distinctions matter:
- A conclusion Mothy reached about a child is never stored. Not as memory, not as a record, not in any trust tier. A model's inference is not a record and cannot be signed by anyone. If Mothy notices something worth keeping, its only route is to propose it to a person, visibly, as something that person authors and takes responsibility for.
- A fact you state about a child is held, and must be tagged to that child. A foster carer telling Mothy the age of the child they foster is not an inference; it is the carer stating something they know, and a secretary that refuses to hold it cannot do the job. It is stored with full provenance (who said it, when, in which session), it is visible to the carer, and it is correctable and erasable per child.
- Where a governed record exists, Mothy stores a reference to the record, not a copy of its contents. A statutory deadline or a placement is looked up at the moment it is needed, so an amendment to the record changes the answer and an erasure removes it automatically. There is one version of the truth and it is the record. This tier is preferred wherever a record exists, and it is also the accurate one: a stored age goes wrong within twelve months, a reference survives the birthday.
Why tagging is the control, and prohibition is not
The intuitive rule is "hold nothing about a child at all". We built that first, and it was wrong, for a reason worth stating in public because it generalises.
A blanket ban does not stop a fact arriving. The carer needs the fact held, so it gets rephrased until nothing recognises it as child data, and then it is stored anyway, untagged. An untagged fact about a child is the worst possible outcome, because erasure works by tag: the untagged fact is exactly the one that an erasure request cannot find. We saw this in our own development database, where a plainly child-related fact had been stored by an older code path as ordinary untagged prose, invisible to erasure by subject. That row has since been deleted, and its content lives on as a test fixture that fails the build if the scan ever stops recognising it.
So the enforcement point is not the presence of child data. It is authorship and tagging: what we are building rejects anything model-authored about a child in either trust tier, and rejects any assertion about a child that does not carry a tag naming which child. Tagging is what makes showing, correcting and erasing possible. Prohibition manufactures the untagged kind.
The rest of this page is about how much of that is code today, because the distinction between a policy and a control is the whole point of the exercise.
What enforces it today
When this page was first published, on 13 August 2026, the strongest protection Mothy had against holding a model's opinion about a child was that it had no way to write one. That changed the next day. On 14 August the write path landed with the child boundary built into it, and on 19 August the route by which a model can propose a memory for a person to approve. Both are in the code and tested on every change.
Both are also switched off for every real organisation, behind one setting, and they stay off until our own data protection impact assessment for persistent memory is complete. So the protection today is two things at once: the rules are built, and nothing runs them for a real child yet. Anyone assessing us should be asking about the date the setting turns on, not about today.
What runs in code today, each asserted by a named test on every change.
- The write path refuses a model's assertion about a child, in every trust tier. A statement tagged as being about a child is held only as the person's own statement. A conclusion the model reached is refused, and so is a conclusion a person approved, because agreement does not turn an inference into a record. A statement that reads as being about a child and carries no child tag is refused whoever wrote it, because the untagged kind is the one erasure cannot find. The rule is a database constraint as well as a check in the code, so a new caller cannot skip it. Landed 14 August 2026.
- A child-related candidate is dropped before a reviewer sees it. When the model distils a conversation into things worth remembering, anything that reads as being about a child is rejected at that step, with the reason recorded, rather than reaching the approvals queue. Landed 19 August 2026.
- The store cannot hold a shapeless or unattributed statement. Every statement carries who authored it, where it came from and which trust tier it belongs to, and those are database constraints rather than API checks, so a new caller cannot skip them. An assertion must carry its text and no record pointer; a reference must carry a record pointer and no text. That separation is what makes the reference tier meaningful instead of a naming convention.
- A deterministic scan guards bulk import. Legacy memory being migrated into the new store is scanned against the child records the system knows and a child-vocabulary check. A flagged row is not imported. It is skipped, written to an exclusions report, and left for a human decision, because legacy rows carry no subject tags and a row nobody can tag is a row erasure cannot reach. Its scope is bulk import only; the write path above covers everything written from now on.
- Erasure by subject works, and is tested on every build. Tagged statements about a child are removed by an erasure request for that child. The audit chain still verifies afterwards, so the erasure is itself evidenced.
Underneath all five sit the controls that are not memory-specific and have been live longer: the tamper-evident audit log, per-organisation row-level security, and erasure by data subject across every owned table.
What is specified and not yet built
Two child controls are designed, written down and committed to, and not in the product today:
- The explicit acknowledgement in the approvals queue. An approvals queue exists, model-proposed memory lands in it as a visible diff, and a child assertion cannot be pushed through it, because the write path refuses it whoever approves. What is not built is the step that makes a reviewer say in words that they have read a child-vocabulary flag before anything near it is approved.
- The safeguarding lane that will exclude safeguarding-flagged sessions from memory construction entirely.
Also built and merged, but shipping switched off: the memory store itself, with provenance and supersession on every statement, the reference tier with its resolver tests (an amendment changes the answer, an erasure removes the reference, a missing record renders nothing rather than stale text), a retrieval path over stored statements, and since August the write path and the proposals route described above. It all stays off for real organisations until our own data protection impact assessment for persistent memory is complete. We gate our own features on our own paperwork, and we think that is the right order.
This page will be updated as each item lands. Where it says "not yet built", that should either become true or be publicly withdrawn, not quietly reworded.
What we do not claim
- We do not claim Mothy holds no data about children. It holds what a carer states and tags, because that is what makes the data findable, correctable and erasable. Anyone who tells you their system holds nothing about a child is describing their write policy, not their database.
- We do not claim the refusal rules have guarded a real child yet. They are built, tested and switched off. The first real organisation they run for is when they earn the claim, and this page will say when that is. A page that described them as already guarding the door would be exactly the kind of claim this page exists to argue against.
- We do not claim the boundary will be absolute once it is switched on. The guard turns on a fact about a child being recognised and tagged as one. Something about a child that nothing recognises as child-related is caught only by the deterministic scan and the vocabulary check, and if both miss, it is written untagged. The number that matters is tagging accuracy, and we will measure ourselves on it rather than on the policy's existence. A control described without its edge is marketing.
- We do not quote benchmark numbers for any of this. Any figure we publish comes from our own test harness and says so.
- We do not claim the child's journal has been reviewed by anyone qualified. It has not. The wording a child reads about who can see what is ours, written by people who are not safeguarding professionals, and getting it in front of one is the next thing rather than a finished thing. Until that has happened, treat the journal as a design we are willing to defend and not as a design anyone has approved.
- We are not child-safety researchers. Geoff is a foster carer and a supplier. We are volunteering to be held to a standard, not claiming authority over how it should be set.
How to check us
- Ask us for the audit export and the test list. The shape and provenance constraints, the migration exclusions, the resolver behaviour and the erasure cascade are each asserted by named tests that run on every change. So are the refusal rules: ask for the tests on the child boundary, on the write path, and the memory-poisoning cases, and for the run that exercises them on every change.
- Try to falsify the rule. If you can find a child fact that erasure by subject cannot reach, that is a reportable failure: hello@getmothy.ai.
- Compare this page against the product after each release. The list above is written so that you can hold us to it item by item.
Why we are publishing this
"Won't Somebody Think of the Children? The Case for a UK Child AI Safety Institute" (Ellie Prosser, August 2026) argues that children need a defined, testable standard for the AI systems in their lives, with evidence against a threshold instead of "we added safeguards". We support that standard, and we think it must also cover the systems that write about children, not only the ones children talk to. The Department for Education flagged AI case recording as a gap in September 2025, and no institution owns it yet.
This page is our contribution: the standard we hold ourselves to, published before anyone requires it, in a form a sceptical reader can test. Including the part where we say which half of it is not built.
First published 13 August 2026. Reviewed against the code on 1 October 2026, when this page was found to be seven weeks behind it: the write path and its refusals landed on 14 and 19 August and the page went on saying they were not built. That is the fault this page exists to prevent, so it is recorded here rather than tidied away.