Child Safety and Reportable Conduct

1 Why we are in scope at all

1.1We do not teach children, supervise them, or meet them. We build software that holds a child’s handwriting, their name, their year level and a teacher’s judgements about their maths.

1.2Three of our people can, with a school’s permission, look at a page a nine-year-old drew. That is enough. An organisation whose staff can see children’s work is an organisation that needs to know who those staff are, who hears it when something goes wrong, and what it does next. We treat ourselves as in scope of the Victorian Child Safe Standards and we design to them.

1.3We are careful about one thing. The Reportable Conduct Scheme duty for conduct by a school’s own staff sits with the school, as the entity that engages them. Our duty is to our own people, and to tell the school promptly so it can discharge its duty. We do not do a school’s reporting for it, and we do not tell a school what its obligations are.

2 Working with Children Checks

2.1No person gets access to any system holding student data until a current Working with Children Clearance is verified and recorded. Not on the day they start. Before.

2.2As at today, no check has been obtained. Not one. Applications for all three founders are scheduled for 25 August 2026, and every clearance is verified before the first school holds a live account. That is the date to hold us to, and we would rather state it than write this section in a present tense that is not true yet.

2.3The mechanics are set out once, elsewhere. Who is screened, employee category and why not volunteer, the online verification, the organisation listing that makes revocation reach us, the renewal cycle and the register are all in our Personnel Screening Procedure, and are not repeated here. Four things belong in this policy because they are child safety obligations rather than screening administration.

2.4We are careful about the legal position. As the business currently operates, no one here has direct contact with a child, so a Working with Children Check is probably not legally compelled. We hold one anyway, and our Personnel Screening Procedure says why in full rather than implying an obligation that does not exist.

3 Who receives an allegation

3.1Contact. policies@reasoneducation.com.au.

3.2The split matters and is deliberate. A person who can be the subject of an allegation must not be the person who receives it.

3.3Anyone may raise an allegation — a school, a teacher, a parent, a founder, a contractor, or a person with no connection to us. We do not require it in writing, we do not require the person to be certain, and we do not ask them to gather evidence first. Our threshold for acting is a reasonable belief, not proof.

4 What happens when an allegation is received

4.1Same day, in this order.

4.2We do not investigate in parallel with police in a way that could contaminate their work. Where police or the Commission are involved, our own inquiry pauses and we say so in the register.

4.3Outcome. Every allegation closes with a written finding, a date, and either a change we made or a recorded reason no change was warranted. Access is restored only by a decision of the Child Safety Contact, in writing, in the register.

5 Crisis response — when a child discloses harm through the product

This is new. It is written here because the code that routes a disclosure needs something to route to, and building the route before deciding where it goes is how a disclosure ends up in a support inbox nobody opens on a Saturday.

What can reach us

A child cannot message anyone in this product. There is no chat, no comment box, no peer visibility. The only free-form thing a child produces is the drawn canvas — the space where they show their maths working out. A child can write or draw anything there.

So a disclosure can reach us in exactly three ways: a founder sees it while supporting a school; it appears in the AI quarantine queue; or a school forwards it to us. In every case the child is not talking to us. They are drawing on a page and someone has seen it.

What we do

1. Do not respond to the child. Not in the product, not through the school, not at all. The AI never talks to a child and neither do we. A child who has disclosed something needs a trusted adult in the room, not a message from a software company.
2. Do not screenshot, forward, copy into chat, or discuss it outside the route below. The image stays where it is.
3. Notify the Child Safety Contact within one hour of seeing it, by email to policies@reasoneducation.com.au with URGENT at the start of the subject line. Where the child appears to be in immediate danger, the next step comes first.
4. If the child appears to be in immediate danger, call 000 first, then the Child Safety Contact.
5. The Child Safety Contact notifies the school’s nominated child safety contact the same day, by phone, and confirms in writing. The school holds the duty of care, the relationship with the family, and the mandatory reporting obligations of its teaching staff. Our job is to make sure a person who can act on it knows, today.
6. Where a sexual offence against a child under 16 is reasonably believed, the Child Safety Contact discloses to Victoria Police — independently of what the school does, and without waiting for the school to respond.
7. Preserve, do not delete. The submission, the image and the audit trail are preserved intact. Nothing is edited or removed, including at a school’s request, until police or the Commission confirm they do not need it.
8. Tell no one who does not need to know, and in particular no one who could alert a person the disclosure concerns.
9. Record it in the Child Safety Register — what was seen, when, who was told, when, and by what means. Undated is unusable.

What we do not do

• We do not assess whether a disclosure is credible.
• We do not contact a parent.
• We do not decide whether the school should tell the family.
• We do not build any capability to read children’s pages looking for disclosures — that would be monitoring children, which the Responsible AI Policy rules out.

This protocol handles what a human happens to see. It is not a search.

Our Incident Response Plan classifies a canvas disclosure as a severity-1 incident and routes it here. That plan governs the incident mechanics — severity, preservation, the register entry, the school notification letter. This section governs what is done about the child.

6 Staff obligations — induction, supervision, training, design

Delivered through the induction and annual cycle already defined in our Awareness Programme, and recorded in the training register. This section is the child safety content of that programme, not a second training system running beside it.

6.1 Child safety induction

Every founder and every contractor completes a child safety induction before first access, not in their first month. It is short, and it is recorded, dated and signed in the training register. It covers: this policy; who the Child Safety Contact is and how to reach them out of hours; the crisis protocol at section 5; the rule that a person cannot be their own allegation recipient.

Repeated annually, and re-run whenever this policy changes.

6.2 Supervision when supporting schools

We will at times be in a school, or in a screen-share with a teacher, with children’s work on the screen.

• No unaccompanied contact with a child, ever. Not in a classroom, not in a corridor, not online. If a child is present, a school staff member is present.
• On-site work happens under the school’s own visitor and child safety arrangements — sign-in, supervision, and their code of conduct, which we follow rather than substitute with our own.
• No founder works alone in a school on a first engagement. Two of us, or one of us alongside a school staff member.
• Support access to student data is by named request, time-boxed, and logged. Every view of a child’s work is written to the audit log. Support sessions are reviewed monthly against the log by the founder who did not run them.
• No photographs, no recordings, no images of children on our devices, including screen recordings of a session showing children’s work.

6.3 Training that acknowledges student diversity

Annual, recorded, and specific rather than a slide about respect. It covers: Aboriginal and Torres Strait Islander cultural safety, including that a child’s name, community and identity are not ours to interpret; children with disability and children with communication support needs; children from culturally and linguistically diverse backgrounds, and children who are learning English while learning maths; gender-diverse children, and why we hold no gender field; children in out-of-home care and children for whom a name change or a suppressed enrolment is a safety matter.

First delivery before the first school holds a live account. Provider not yet selected — this is a live decision, and we would rather name it than list a training programme we have not booked.

6.4 Diversity in the product design

Design decisions we can point at, not intentions.

• We hold no gender field, no date of birth, no religion, no cultural background, no parent details and no health data. The system does not need them to do arithmetic. A field that does not exist cannot be used to sort children, cannot leak, and cannot out a child.
• A name is displayed exactly as the school entered it and is escaped as data everywhere. This is a correctness fix that is also a dignity fix: an apostrophe in O’Brien once broke a page, and a system that mangles a child’s name is telling them something.
• “Unreadable” is a first-class answer. A child with faint pencil, a tremor, a plaster cast or unusual handwriting is never marked down for it, never guessed at, and never inferred about. Unreadable influences nothing.
• Read-aloud is available on the child’s screen, and the type stack is local system fonts so that a device’s own accessibility settings apply.
• The AI never compares one child to another, or to a norm. No ranking, no “below average”, no cohort percentile. A comparison is where cultural and linguistic difference turns into a deficit judgement, so we removed the mechanism rather than the wording.
• No wellbeing, behaviour, effort or attitude inference, and no detection of any condition, disorder or disability.
• Themes and badges carry no cultural or religious content and no imagery a family could reasonably object to.

Every new user-facing feature is checked against this list at design time under the Safety by Design Statement.

7 The Child Safety Register

7.1One register, held by the Child Safety Contact, separate from the support and privacy logs because its contents are more sensitive than either.

7.2Each entry, dated. What was raised or seen; the date and time received; who received it; the date and time access was suspended; who was notified — police, the Commission, the school, the screening unit — with the date and time of each; the outcome; the date closed; and the change made or the reason none was.

7.3Reviewed by both officers every quarter. An empty quarter is recorded as empty and signed — a register with no entries and no dates cannot be distinguished from a register nobody kept.

9 Related documents

• Incident Response Plan — incident classification, severity, containment and notification mechanics, and its section on online safety incidents. A child safety decision is made under this policy; the incident mechanics are that plan’s, and where a data breach is also involved the plan governs the breach response.
• Personnel Screening Procedure — Working with Children and police checks, the screening register, and the gate that puts screening before access.
• Awareness Programme and training register — how the induction and annual training in section 6 are delivered and recorded.
• Support and Complaints — how a child safety complaint arrives.
• Safety by Design Statement — the design controls this policy relies on.
• Access Control Policy — how access is granted, reviewed and removed.
• Responsible AI Policy — the AI never talks to a child; no monitoring.

10 Contact

We do not require an allegation in writing, we do not require the person to be certain, and we do not ask them to gather evidence first.

11 Version history

• 1.018 August 2026First issue.

Signed by Jake Gatto, Founder and CEO, Privacy Officer and Child Safety Contact, and countersigned by Jacob Clemens, Founder and CTO, Security Officer, on 18 August 2026. Next review 18 August 2027, or on any change to the founders, to contractors, or to what a child can see in the product.