SproutSprout
Child safety and data

What we do with children’s data, in plain English

Sprout is used by teachers and by families, which means it sits close to children without ever being handed to one. This page explains what that looks like in practice: what we collect, what we deliberately do not build, who else sees anything, and the two places where we make a different trade-off from other children’s learning products. Both of those are spelled out rather than buried, because a trust page that only lists the comfortable facts is not worth reading.

The binding versions are the Privacy Policy and the Terms of Use. This page is the same commitments without the legal grammar, and nothing here is intended to weaken either.

Five things that are true today

Not roadmap items. These are properties of the product as it is built right now, and we would have to write new code to break any of them.

Children do not have accounts

Sprout accounts belong to adults: a teacher, a parent, or a carer. There is no child sign-up and no way for a child to create a profile, an email address or a password. Sprout Tutor gives a child a 4-digit PIN so they can start a practice session, but a PIN is not an account: it unlocks one student’s tutor on a page the account holder already controls, and it is issued, viewed and revoked by that adult.

No chat, no messaging, no feed

There is nothing for one child to send to another, because there is nothing to send it with. Sprout has no messaging, no comments, no social feed and no user-to-user contact of any kind. A lesson is a page, not a place.

No leaderboards, no ranking

Children are never scored against each other, publicly or privately. Sprout Tutor does record how a child is going so the adult who owns the account can see it, but that record is theirs alone: it is never shown to another child, never turned into a rank or a class table, and never compared with anyone outside the account.

Interests, not identities

What makes a Sprout lesson personal is what a child is into: dinosaurs, netball, Minecraft, horses. That is the only thing we ask for, and we ask adults not to enter a child’s full name, contact details or photographs. Personalisation should never need to know who a child is.

Nothing sold, nothing advertised

We do not sell personal information, we do not share it with advertisers, and there are no ads anywhere in Sprout. There are no third-party advertising or profiling trackers on the site. Our revenue comes from subscriptions and credits, which is the whole business model.

The adult is the human in the loop

Some children’s learning products review every question by hand before any child sees it. That works when the question bank is fixed and shared by everyone: write ten thousand questions once, check them once, ship them to every child. It is a genuinely good model and we are not going to pretend otherwise.

Sprout does not work that way, and it cannot. Every Sprout lesson is written from scratch, for one child, at the moment an adult asks for it, wrapped around that child’s interests and pitched at their year level. There is no shared bank to pre-review. Nobody at Sprout has read your child’s lesson, because it did not exist until you asked for it, and nobody else will ever be served that same lesson.

So the human in the loop is you, and the product is built so that you always are. A lesson is generated because an adult requested it, it opens in front of that adult, and it only reaches a child when that adult hands it over. There is no feed, no recommendation engine and no autoplay: nothing in Sprout can put generated content in front of a child that an adult did not deliberately give them.

Underneath that, this is what runs automatically on every lesson:

  • Curriculum grounding. Lessons are aligned against the official curriculum datasets we hold for the Australian Curriculum v9, the Victorian Curriculum 2.0, the NSW syllabuses, US Common Core and NGSS, and the Ontario, British Columbia and Alberta curricula. The codes it aligned to are printed in the lesson footer so you can check the claim rather than take it.
  • Answer keys, checked in the page. In a full-page lesson, every self-check question carries its accepted answers with it and the check happens in the browser against that key, so nothing a child types leaves the page. Sprout Tutor works differently and records answers on purpose, which is set out in full below.
  • Hints that cannot leak the answer. Hints are constrained to point at the method rather than the result, and a lesson that fails that constraint is regenerated.
  • Structural validation. Every generated page is checked for completeness before it is stored, and a lesson that fails is regenerated rather than served.

None of that is the same thing as a person reading every question, and we are not going to describe it as if it were. What it means for you is one small habit that we would ask for anyway: read the lesson before you hand it over. It takes about a minute, it is the step that catches a pitch that landed too high or an example that will not suit your class, and it is the only review that knows the child.

If a lesson ever comes out wrong in a way that matters, tell us at contact@sproutlessons.com. We read those, and prompt-level problems get fixed for everybody.

What we actually store about a child

Less than you might expect, because Sprout is a tool for the adult rather than a service for the child. If you add students to a roster, each entry holds:

  • A name you choose. It can be a first name, a nickname, or “Student 3”. It is private to your account, and it is never shown on a shared page.
  • A display pseudonym such as “Curious Otter”, generated automatically when you add the student and editable at any time. This, and never the name you entered, is what appears on that student’s share page, so a safe default costs you no thought.
  • Interests, in your words. Private, used only to shape the lesson, and never published on a shared page even when sharing is on. We treat interests as a soft identifier, because a detailed enough description of what a child loves starts to point at a particular child.
  • The lessons assigned to that student, so you can find them again.
  • If you switch Sprout Tutor on for that student, their practice record. This is the one part of Sprout that deliberately keeps a history, and it is set out in detail in the next section.

We do not collect a child’s date of birth, contact details, photograph, school, or location, and we ask you not to type any of those in either. A year level and a couple of interests is genuinely all a lesson needs.

About the adult account holder we store the ordinary things: name, email, subscription and credit balance, billing references from Stripe, and internal usage and error events used to run and debug the service. The full list is in section 2 of the Privacy Policy.

Sprout Tutor keeps a record, on purpose

Everything above describes full-page lessons, where nothing a child does is recorded. Sprout Tutor is different, and it is different by design, so it gets its own explanation rather than a footnote.

Sprout Tutor is an adaptive practice mode: the child works through questions on a curriculum code, and the difficulty moves with them. That cannot work without a memory. To know that a child is ready for something harder, or that they have been struggling long enough to need easier work, the product has to remember how the last few questions went. The same record is what lets you, as the parent or teacher, open a page and see how they are actually going.

It is off unless you turn it on. Sprout Tutor is disabled for every student until the account holder enables it for that specific student and assigns them a subject. A roster entry with the tutor switched off has no practice record at all.

Once it is on, here is exactly what is kept:

  • One row per question the child answers. It holds the curriculum code, the difficulty tier, the type of question, whether they got it right, whether they used the hint, whether they revealed the answer, and the time. It also holds the question itself, the options, the hint and the child’s answer, so that you can see what they actually saw rather than a bare “three wrong on AC9M4N05”. This log is append-only: it is never edited after the fact.
  • Where they are up to. The code they are currently on, the difficulty tier, and the streak counters the adaptive engine uses to decide when to move them.
  • Any change in working level, and why. If sustained struggle moves a child to work a year below their assigned level, or progress moves them back up, that move is recorded with its date and its reason. We would rather you could see “we moved them down on this date, and here is what led to it” than discover it as a silent change.

Who can see it. The account holder, and the child. Reports are served only on authenticated routes scoped to the owner of the roster, and the same row-level security that protects everything else applies here: another account cannot read your students’ practice records, and the public share page cannot reach them at all. The child sees their own progress, and never anybody else’s.

The AI does not see the answers. Marking is done by ordinary server-side code, one deterministic check per question type, not by a language model. The adaptive decisions (harder, easier, move on, move down a year) are made by that same server-side engine from its own counters. The model’s only job is to write the question it is asked for, on the code and at the difficulty the engine has already chosen. It is not given the child’s practice history, and it does not read or write the progress tables.

What it is not. It is not a behaviour profile, a wellbeing assessment, or a judgement about a child. It records what was asked and what was answered on a curriculum code, and nothing about attention, conduct or character. It is never used to rank children against each other, it is never shown to another family or another student, and it is never sold or shared for advertising. It is also not a diagnosis: a child working below their year level in the tutor is a signal to look at, not a conclusion.

The PIN. A child unlocks the tutor with a 4-digit PIN that you issue. Stored hashed for checking, plus encrypted separately so you can look it up again when a child forgets it. Repeated wrong guesses lock that student out until you clear it from your dashboard, and the lockout counts per student rather than per device, so a shared classroom tablet cannot be used to work through one child’s PIN a few guesses at a time. The public page that checks a PIN never has access to the readable copy.

Deleting a student removes their practice record along with everything else, immediately. If you want the record gone but the student kept, ask us and we will clear it.

Who else sees any of it

Five providers, each doing one job. All of them are based in the United States, which matters under Australian privacy law and is explained properly in section 5 of the Privacy Policy.

ProviderWhat it doesWhat it sees
Supabase (on AWS)Database, login and file storageYour account, your roster, your lessons
AnthropicLesson and tutor question generationThe request: topic or curriculum code, year level, interests. Never a child’s answers
OpenRouterRouting some generation requestsThe same request
StripePaymentsBilling references only, never card numbers
VercelHosting and aggregate site analyticsPage requests

That is the complete list. There is no advertising network, no data broker, no profiling service, and no analytics product that follows a visitor between sites. Site analytics are aggregate page-request counts only.

How your data is kept separate

Every table that holds your content is protected by row-level security at the database level, which means the rule that you can only read your own rows is enforced by the database itself rather than by application code remembering to check. Data is encrypted in transit. Administrative keys are used only in server-side code and are never exposed to the browser.

Student share pages are the one deliberate exception, and they are narrow by design. A student page can be read without logging in by anyone holding its link, which is why the query that serves it is written so that the private fields, the name you entered and the interests, are never even requested. What that page can show is the pseudonym, the titles of that student’s lessons and whether each one finished generating. Nothing else. The link contains a random identifier, so it is not guessable, and the page is marked so search engines do not index it. You can switch sharing off for any student at any time, and because these pages are never cached, the link stops resolving on the very next request.

Getting your data out, or getting it deleted

You can ask for a copy of everything we hold about you, ask us to correct it, or ask us to delete your account and its contents. Email contact@sproutlessons.com and we will respond within 30 days. Deleting a student from your roster removes that entry immediately.

Some records survive deletion where the law requires it, principally financial records, which Australian tax law requires us to keep for seven years. That is invoices and payments, not lessons and not children.

If we ever have a data breach likely to cause serious harm, we are required to notify both the Office of the Australian Information Commissioner and the people affected, and we will. That obligation applies whether the breach starts with us or with one of the providers above.

If something is not right

Email contact@sproutlessons.com. A person reads it.

The full documents

This page is the plain-English version. These are the ones that bind us.