Privacy notice
Loading.
Loading.
Last updated 19 October 2026
The short version: we hold a nickname and a school year for your child, the topics you have asked about, the packs we built, and — if you have registered — your email address. Nothing about your child is ever sent to the company whose language model writes the packs. There are no tracking cookies and no advertisers. You can download all of it or delete all of it, yourself, in two clicks.
ParenTeacher is operated by SATAXI Labs, Inc., a corporation incorporated in the State of Delaware, United States (“we”, “us” or “our”).
Our correspondence address is 1111B South Governors Avenue, Suite 54009, Dover, DE 19904, United States.
You can contact us at support@parenteacher.app.
SATAXI Labs, Inc. is the controller for everything described on this page. The service is offered to families in the United Kingdom, so UK GDPR and the Data Protection Act 2018 apply to how we handle your personal information.
About you: your email address, but only if you have registered — during the guest period we have none. How you described your own confidence with maths, which is one of three options and changes the tone of the briefing you get. Which plan your account is on and how many packs you have used this month. If one of us has added packs to your allowance, how many and why. Whether you have asked us to stop emailing you.
About your child: the nickname you chose for them and their school year. That is the entire list. There is no field for their real name, their school, their date of birth, their address, a photograph or anything a school would call a record, because a pack does not need any of it and holding it would make us a target.
About the work: what you told us they were stuck on, in your own words, and which topic that resolved to. Each pack we built — the questions and answers in it, the two PDFs, and the report from the checks it passed. A list of the numbers and puzzle values already used for that child, so the next pack does not repeat them. How you told us a pack went — “Cracked it”, “Getting there” or “Still stuck” — and any report you filed that something in a pack was wrong, with any words you added to it. Changing your answer simply replaces it. The one exception dates from before we fixed a fault: if an early pack was answered twice at the same moment, the spare answer was moved to a separate table that nothing in the service reads — it is there so that a repair we once had to make to the database is reversible by hand, it goes when the pack it belongs to goes, and it is included in everything we hold when you ask for a copy.
About keeping the service running: unfinished and finished generation jobs with their timings and any error — kept for a fixed period and then deleted, see below — sign-in links and their expiry, live sessions, and a ledger the rate limiter uses. The ledger is worth a sentence of its own: it holds no IP address or email address, only a one-way digest of one, computed under a secret key. That makes it pseudonymous rather than anonymous — nobody can read an address back out of it, but with the key a known address can be matched to its entries. It is used only to count attempts from one network, one email address or one account, so that a single visitor cannot run up our costs, and each entry is deleted once it is more than 25 hours old.
Almost all of it is there because it is the service: we cannot build a pack for a child whose year group we do not know, or keep numbers fresh without recording which ones we have used. The lawful basis for that is performance of a contract — you asked for a pack, this is what making one takes.
Some of it is there so the service survives contact with the internet: the rate limiter’s ledger, the record of which sign-in links have been used, and the operational logs. The basis for those is our legitimate interest in keeping a free service available and not being run up a bill by a script — and they are designed to hold as little as possible while doing it.
One email is different: a single message, once, asking how a pack went, sent about a day after you built it — and only if you have registered an address and have not already told us. If it has not gone within a week, it is not sent at all. That is also a legitimate interest — the whole product depends on knowing whether the packs actually help — and every one of those messages carries a one-tap unsubscribe that needs no sign-in and is honoured immediately. Sign-in links are not marketing and cannot be unsubscribed from; they only ever arrive because you have just asked for one.
You can build 2 packs without giving us an email address. During that time you still have an account in our database — a nickname, a school year, the packs — but it has no address on it, and the only thing connecting you to it is a signed cookie in your browser. We do not know who you are and we have no way to find out.
That has a consequence we would rather you heard from us than discovered: if you clear your cookies or move to another device, that account is unreachable, by you and by us. We cannot restore it, because we cannot tell it was yours.
A guest account that nobody returns to is deleted automatically after 30 days without a new ask or a new pack — each of those restarts the clock, but simply visiting does not. The guest cookie itself lasts 30 days from the day the guest account was started and is not renewed, so registering before then is the only way to keep the account reachable. The child’s nickname, the packs, the PDFs on disk and the record of which numbers were used all go with it. Keeping a child’s nickname indefinitely with nobody left to ask about it is not caution, so we do not.
Putting an email address to a guest account keeps everything already in it and ends the automatic deletion.
The packs are written by a large language model run by Anthropic. What we send it is a short, closed list: which topic to write about, one of four difficulty settings, an optional theme chosen from a fixed menu, a random seed, a list of number patterns already used for this child so it avoids them, and — if an earlier attempt failed the checks — what the checker objected to.
It does not receive your child’s nickname. It does not receive their school year as anything other than the topic’s own year range. It does not receive your email address, your name, your account, or the words you typed to describe what they were stuck on. Your own description is read by a matching program that runs here, on our side, and what crosses to the model is the topic it resolved to — a value from a list of nine. There is a test in our build that reads every file in the generation service and fails if the column your words are stored in is so much as mentioned there.
So the model has no way to know anything about your child, and the pack it writes cannot be traced back to a person by the company that runs it.
SATAXI Labs, Inc. is a US company. Our application runs on Railway infrastructure in the United States, and our primary database is hosted by Supabase in London, United Kingdom. Information passes through our US application infrastructure when you use ParenTeacher.
We also use providers for authentication, email delivery, file storage, error monitoring, tips, development and maintenance. These include Supabase, Cloudflare, Sentry, DigitalOcean, GitHub, Anthropic and Stripe, where those services process personal information. Processing may take place outside the UK. Our operator also accesses information from the United Arab Emirates to administer the service and respond to support requests.
To do that, the few people we have authorised can use an admin console that looks up one account at a time, by its email address or account number. It shows the address, the plan, how many packs have been used, how many children and packs there are and why a recent pack failed to build — never a child’s nickname or the words you typed about them — and it can show the words you added to a report that a pack was wrong. Every look-up is written to a permanent record of which of those people looked at what, and when.
Where UK data protection law requires a safeguard for a transfer to a separate organisation outside the UK, we use the applicable transfer arrangements in our provider agreements.
For eligible US recipients, this may be the UK–US Data Bridge, which applies to organisations participating in the UK Extension to the EU–US Data Privacy Framework. For other transfers requiring contractual safeguards, we use the European Commission’s Standard Contractual Clauses together with the UK International Data Transfer Addendum.
You can request information about the safeguards applying to your information, including a copy of the relevant contractual safeguards, by emailing support@parenteacher.app. We may redact confidential information.
SATAXI Labs, Inc. has appointed JP Consulting London, Limited as its representative under Article 27 of the UK GDPR.
You can contact our representative about our processing of personal information and your rights under UK data protection law: JP Consulting London, Limited, Suite 365, 19–21 Crawford Street, London W1H 1PJ, United Kingdom. Email: info@jpcl.uk.com.
SATAXI Labs, Inc. remains the controller responsible for your personal information.
When a page or a pack fails, our servers send a report about the failure to Sentry, an error-reporting service, so that a fault which happens to you is a fault we find out about rather than one you have to tell us about. The project is hosted in Sentry’s European Union region, and the reports go from our servers: there is no error-reporting script on any page, which is why there is none in the cookie list either.
A report holds the error’s type and message, the lines of our own code it happened in, which part of the service it was, which release was running and whether that was the live service or a test one. With it go a few technical references — the identifiers of the request, the generation job and the pack request it belongs to — and, for a page error, the short reference the error page shows you, so that a support message quoting it finds the failure behind it.
A report holds no name, no email address, no nickname, no school year, none of the words you typed, no cookie or session, no web address with your answers in it, and no IP address. There is no visitor record attached to a report at all. We do not use the vendor’s ready-made toolkit, which collects several of those things unless it is told not to; the report is assembled field by field in our own code, and tests fail the build if a report starts carrying a visitor, a request, the contents of a form, or anything in a stack line beyond a filename, a function and a line number.
Two things we would rather state than have you assume. The technical references are random identifiers that mean nothing to Sentry, but we can look them up in our own records and arrive at an account, which is exactly what they are for — without them a fault report is unattached to the pack that failed. And the text of an error can quote the part of a pack our own checks rejected, such as a question whose answer did not add up: that is material the model wrote, not anything you or your child told us.
The basis for this is our legitimate interest in a service that works, and in knowing when it does not. A fault report is about our software rather than about you.
Fault-report events are retained in Sentry for 90 days. Residual backup copies expire under Sentry’s backup-retention schedule.
The tip link takes you to a payment page that Stripe runs on our own Stripe account, where Stripe collects your card details, your email address and anything else that page asks for. None of it reaches ParenTeacher: the app receives nothing back from Stripe, holds no list of people who tipped and cannot tell whether you gave — which is deliberate, because a tip buys nothing and the surest way to keep that promise is to be unable to break it. We can see each tip, with the details Stripe collected, in our Stripe account.
We retain tip transaction records for as long as necessary to meet applicable tax and accounting requirements and resolve refunds or payment disputes. Stripe also retains payment information under its own legal obligations and retention policies. See Stripe’s Privacy Policy at stripe.com/privacy.
We also count what happens in the service — a guest starting, a pack being asked for, built, failed, previewed or downloaded, an answer about how a pack went, the allowance running out, and the tip link being followed, with which of the three places on the site it was followed from. Each count holds the event, the time and a few words from a fixed list, such as which of the nine topics a pack was about; it holds no account, no address, no cookie and nothing you typed. Three of the counts about building a pack carry a one-way digest of the build’s reference, so that one build is counted once. The counts are kept for as long as the service runs, and tell us whether it is working and whether the tip ask is worth keeping. A click on the tip link also leaves a rate-limiter entry, described above, for up to 25 hours.
Guest accounts: deleted 30 days after the last new ask or new pack, with the packs and the files that belong to them.
Registered accounts: kept until you delete them. We do not expire an account for being quiet, because an address means there is somebody to ask, and a pack from last spring is still the pack that worked.
Sign-in links: 15 minutes, then dead. The row recording that the link existed is swept a day later, which is what makes a used link unusable a second time. Sessions: 30 days, or until you sign out or delete the account.
The record of how a pack was built — which stage it reached, how long each one took, what it cost us — we keep for 30 days after the job stopped, then it goes. The pack itself is not touched by that: what we keep of a pack is the pack.
The rate limiter’s ledger: each pseudonymous entry is deleted once it is more than 25 hours old — a day, the longest window it counts over, plus an hour.
The record of what our authorised people looked up in the admin console is kept for as long as the service runs and is not removed when an account is deleted, so that nobody can tidy away their own trail. It holds the account’s number rather than its address; where somebody searched by address, it holds a pseudonymous digest of the address instead.
When you delete, deletion is immediate and it is real: the rows go, and so do the PDFs on disk and the record our sign-in provider keeps of your address and your sign-ins. There is no thirty-day recycle bin holding your child’s worksheets where you cannot see them. There are no backup copies of the database at present, so nothing you delete lives on in one; if we start keeping backups, this page will say for how long before we do.
The one thing that stays is the set of questions and answers written for a pack, and the briefing that went with it, which we keep filed under the topic so that later packs can reuse work that has already been checked. That copy holds nothing about you or your child — no account, no nickname, nothing you typed — and once the pack is deleted nothing links it back to you.
Session and guest cookies are signed, so one cannot be edited into somebody else’s account. Sign-in links work once and are checked against a ledger, so a forwarded or intercepted link is dead the moment it has been used. The generation service will not answer a request that does not carry a shared secret, and the app refuses to start in production if any of its secrets is missing or is still the example value from the repository.
No system is perfectly safe, and we would rather hold little than promise much: the shortest section on this page is the list of what we hold about a child, and that is the main control.
You have the right to see what we hold, to have it corrected, to have it deleted, to restrict or object to how we use it, and to take it elsewhere. Two of those are buttons rather than requests, and they work for guests as well as registered accounts, because a person with no account is exactly the person who should not have to make one to be forgotten.
“Everything we hold”, on your children’s page, builds a file containing every row about your account and every pack, with a note listing the few tables that are left out and why. “Delete everything” removes the account, the children, the packs, your answers and reports, and the files, after asking you to type a word so it cannot happen by accident. There is also a per-child delete, for when one child is finished with and the others are not.
You do not need a reason and you will not be asked for one, and using either of them costs nothing and affects nothing else.
There are two kinds. Sign-in links arrive because you have just asked for one; they are how the product works and there is nothing to unsubscribe from. The other is a single message asking how a pack went, sent about a day after the pack was built, once per pack and never twice — and not at all if you have already told us how it went.
Every one of those carries an unsubscribe link that takes one tap, needs no sign-in and is acted on straight away, and your email client’s own unsubscribe button works too. Stopping them does not affect your sign-in links, which will keep arriving whenever you ask.
There is one more way our email to you can stop, and it is not a choice either of us made. If your mail server tells us an address does not exist, we record that and stop sending to it — including sign-in links, which means the account behind that address cannot be opened until the mailbox accepts our mail again. We keep that record as a one-way digest of the address, computed under a secret key, rather than the address itself. That is pseudonymous rather than anonymous: the list cannot be read back as anybody’s email addresses, but an address we already hold can be checked against it, which is the only thing it is used for. It is kept until we release the address — write to us if your mailbox works again — and deleting your account does not remove it, because the mailbox is still not there.
The account here belongs to an adult, and the child is not a user of this service: they never sign in, never type anything into it and never see it. What is held about them is a nickname you chose and a school year, and both exist because the pack has to be addressed to somebody and pitched somewhere.
We have designed on the assumption that the child’s data is the most sensitive thing here even though it is the smallest, which is why the nickname never leaves this system, is never sent to the model, and is not used in any email subject line.
Please tell us first — most of what a complaint is about, we would want to fix. You also have the right to complain to the Information Commissioner’s Office, the UK regulator, at ico.org.uk, and you can do that without coming to us first.
The date at the top is the date these words last changed. If we ever start holding something new, or sending something somewhere new, this page changes before that happens rather than after it, and if the change is significant and we have an address for you, we will email you.
You can write to support@parenteacher.app about anything on this page, including a request to see, correct or delete what is held about you. Two of those are also buttons in the app, and the buttons are faster: “Everything we hold” on your children’s page gives you a copy of all of it, and “Delete everything” removes it.