The eSafety Commissioner's Safety by Design principles are three: service provider responsibility, user empowerment and autonomy, and transparency and accountability. This statement takes each one in turn and sets it against the controls that implement it in the Reason Education product.
It is written for a school assessing us, and it is written to be checked. Where a principle is met, the control that meets it is named. Where a principle is not met, section 7 says so plainly, with a date against it. This document is reviewed annually, and again at every release-planning point — see section 6.
What this document is and is not
1.1What it is. A mapping of each of the three Safety by Design principles onto controls that exist in the source code, and a statement of the places where the principle is not yet met.
1.2What it is not. It is not a statement of intent. Every control in sections 3, 4 and 5 was verified in the source before it was written down, and anything not verified is in section 7 with a date against it.
- Not a statement of intent — the controls below were read in the code, not planned for it.
- Not a claim that the AI is running — the model is not provisioned, the version constant reads not-provisioned, and the analysis pipeline refuses to run.
- Not evidence from the field — the controls are built and tested, and most have never been exercised by a real child.
1.3Read it against section 7. A statement of controls without a statement of gaps is a marketing document. Section 7 is part of this one, not an appendix to it.
The safest design decision we made
The decision everything else rests on
Before the principles, the decision they all rest on: a child in this product cannot reach another person.
Most online safety harm to children is one person reaching another. We removed the mechanism. Everything below is what remains once that is done.
2.1There is nothing to misuse. A child cannot see that another child exists, cannot search for one, and cannot be found by one. None of the following is in the product:
- Chat, messaging, comments or a forum
- A display name, or an avatar a child chooses
- A shared space of any kind
2.2The scoping is structural. Every student-facing query is scoped to the signed-in student's own id. The query names its columns one by one rather than selecting everything, so a column added next year cannot widen what a child sees.
Principle 1 — Service provider responsibility
What the principle asks: the burden of safety sits with us, not with the child or the teacher.
| Control | What it does |
|---|---|
| No chat, messaging or peer visibility | A child cannot contact anyone, and no one outside the school can contact a child. There is no feature to misuse. |
| Every student query scoped to the signed-in student's own id | Structural, not a permission check that a caller could forget. A child cannot see another child's work even if a link is typed by hand. |
| Teacher release gate | Nothing reaches a child until a teacher releases it, for that child, individually. The gate is inside the query, not in the calling code. |
| The AI never talks to a child | No chatbot, no hints, no tutor, no student-facing model output of any kind. The function that assembles everything a child may see mentions no AI column. |
| No third-party scripts on any page a child sees | No analytics, no trackers, no ad networks, no remote CDN, no hosted webfonts. The type stack is local system fonts specifically so a child's IP address and user agent are never sent to a font host. Two JavaScript libraries ship vendored and served from our own origin. |
| No monitoring of children | The product records work a child deliberately submits in an assessment. No device tracking, no location, no browsing history, no activity monitoring, no idle timers, no keystroke capture. |
| No child-facing contact channel by design | A child has no way to reach us and is not meant to have one. Their route to an adult is their teacher, in the room. |
| Working with Children Clearance before access | No person can reach a child's work until a current clearance is verified and recorded. See Child Safety and Reportable Conduct. |
| Minimal data | No date of birth, no gender, no religion, no cultural background, no parent details, no health data, no government identifier. A field that does not exist cannot be misused. |
| Audit log | Every change and every view of a child's work is logged, deduplicated to one entry per person per child per screen per hour. |
ST4S SC5
There are no student communication features or methods. The control that guarantees it is the id-scoping above, not a setting a school could switch on.
What is collected, why it is held and what the model is sent are set out in the Privacy Policy.
Principle 2 — User empowerment and autonomy
What the principle asks: a child and a teacher both have real control over what happens to them.
What we actually do — for the child
4.1"Unreadable" is a first-class answer. A child with faint pencil, unusual handwriting, a shaky line or a plaster cast loses nothing. Unreadable is never treated as wrong, never guessed at, never inferred from, and influences no judgement. This is an autonomy control: it means a child does not have to write like the system expects in order to be treated fairly.
4.2The AI never compares one child to another, or to a norm. No ranking, no percentile, no "below average", no "compared to peers". No child is placed against another child anywhere in the product.
4.3No inference about the child. No wellbeing, effort, attitude or behaviour inference, and no detection of any condition, disorder or disability. The product describes a method on a page. It does not describe the child.
4.4The child chooses their own screen. Theme, and read-aloud on demand. Small, and the point: their preference is stored on their own device, not on us.
4.5"Not me?" signs a child out in one tap. On the first screen, in words a seven-year-old uses.
4.6A child's work is their own work. Nothing is released to them until a teacher has decided, and nothing model-derived reaches them at all.
What we actually do — for the school
4.7The school controls every account. The school creates and controls every account, issues and revokes the sign-in cards, and decides who among its staff sees what. What a school and its staff may and may not do with the service is set out in the Acceptable Use Policy.
4.8The teacher is the decision-maker structurally. A model's reading is not a finding until a teacher opens the working out and decides. A curriculum judgement is made on correctness alone.
4.9A school can switch the AI off. A school can ask us to suspend AI analysis for it, and we do it with one version constant, without argument and without a commercial conversation.
4.10A school has a named route to raise something. A fault, a security concern, a privacy request or a child safety complaint goes through a named person with a stated timeframe — see Support and Complaints.
Principle 3 — Transparency and accountability
What the principle asks: a reader can tell what the system did, who is answerable for it, and what is not working.
5.1Every evaluative statement carries a visible provenance chip. Not a tooltip — computed from marks, an unchecked model reading, or a reading a teacher has agreed with or overruled. A principal reading over a teacher's shoulder can tell AI from arithmetic without hovering anything.
5.2An in-product AI disclosure. It appears on both surfaces where AI output is acted on: what the AI does, what it does not, what a child can see, and what to do when it is wrong.
5.3Forwarded reports carry the source per question. A report that leaves the building still says who made each claim.
5.4Named accountable people. Jacob Clemens (Security Officer and AI Accountability Owner), Jake Gatto (Privacy Officer and Child Safety Contact), Liam Nuttman-Steet (AI development and product). The AI Accountability Owner holds a documented escalation right over AI development and product changes, including the right to halt a release or stop model calls.
5.5No accuracy figure is published. None will be until there is a stated evaluation set, method, date and model version. A percentage on a marketing page is a claim about children.
5.6We publish our gaps. Section 7 of this document, section 8 of the Child Safety and Reportable Conduct policy, and section 0 of the Responsible AI Policy all state things that do not work yet. Three claims previously made on our public website were wrong and are being corrected rather than quietly dropped.
5.7Silence is reported, not hidden. Where a panel aggregates, it reports how many items are still undecided. An unread model flag sits in "Working out to read" rather than rendering as a green light.
How Safety by Design is reviewed
A principle applied once at design time and never revisited is not applied. This is the part ST4S SFP1 actually asks about.
6.1At design time — the gate. No new user-facing feature ships until it is checked against seven questions, and the answers are written down in the design doc for that feature:
- Can this let one child reach another, or let a non-school person reach a child?
- Does it widen what a child can see, and is the widening scoped to their own id?
- Does it add any third-party request to a page a child sees?
- Does it create free-form content that nothing inspects?
- Does it compare a child to another child or to a norm?
- Does it produce an evaluative statement without a provenance source?
- Does it collect a field we do not need?
6.2What a "yes" costs. A "yes" to 1, 3, 5 or 6 stops the feature. A "yes" to 4 requires a named compensating control before it ships — this is the question the drawn canvas fails, and section 7 is the consequence.
6.3Quarterly. The two officers review the gate answers recorded that quarter, the audit log sample, the support and complaints register, and the AI quarantine counts. Dated and signed, including a quarter with nothing in it.
6.4Annually. This statement, against the current eSafety Safety by Design principles and any updated guidance, and against what the product actually does by then. Reviewed alongside the Responsible AI Policy and the AI Risk Assessment.
6.5On event. Any child safety matter, any security incident touching a child-facing surface, and any change of model, prompt or provider triggers a review of this document rather than waiting for the annual date.
Who is accountable, and how to reach us
| This statement, AI accountability and releases | Jacob Clemens, Founder and CTO, Security Officer and AI Accountability Owner |
|---|---|
| Privacy and child safety | Jake Gatto, Founder and CEO, Privacy Officer and Child Safety Contact — policies@reasoneducation.com.au |
| AI development and product | Liam Nuttman-Steet |
| Anything else, including a fault or a complaint | policies@reasoneducation.com.au — every channel, its owner and its timeframe is listed in Support and Complaints |
A child is not expected to reach us, and has no way to do so. Their route to an adult is their teacher, in the room.
Version history
- 1.0First issue.
Signed by Jacob Clemens, Founder and CTO, AI Accountability Owner, and countersigned by Jake Gatto, Founder and CEO, Privacy Officer and Child Safety Contact, on 18 August 2026. Next review 18 August 2027, and at every release-planning point set out in section 6.