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 Carer, 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
The honest headline is that the strongest protection Mothy has against holding a model's opinion about a child is that Mothy has no way to write one. There is no write path for memory yet. Nothing in the product authors a durable statement about anybody, so today nothing authors one about a child.
We are stating that plainly rather than describing the refusal rules as though they were already guarding the door, because protection by absence is real protection right now and it disappears the moment the write path lands. What replaces it has to be built, and it is not built yet. Anyone assessing us should be asking about the date the write path ships, not about today.
What does run is structural, and it is what the refusal rules will be built on.
- 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. This is the one child-specific control running in code today, and its scope is bulk import only.
- 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 three 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
These are the child controls people will most want to hear about, and none of them is in the product today. They are designed, written down and committed to, and they are the next build:
- The write path refusal. A model-authored assertion about a child rejected in either trust tier, and an assertion about a child with no child tag rejected in either trust tier. The predicates that decide "is this about a child" exist in code; nothing calls them yet, because the write path they belong to is not built.
- The child check in the approvals queue. An approvals queue exists in the product for other governed changes, and model-proposed memory will land in it as a visible diff. The child-vocabulary rule that forces an explicit human acknowledgement is not in that queue today.
- The full negative test suite, including memory-poisoning cases.
- 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), and a retrieval path over stored statements. It 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 are guarding anything yet. They are specified and they are next. Today the protection is that no write path exists. A page that described the design as though it were running 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 built. 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 on our own hardware 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. Ask which tests cover the refusal rules, and the answer today should be none, because the rules are not built.
- 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.
Last reviewed against the code on 13 August 2026.