Hosting and Data Residency

1 The short answer

1.1All school and student data will be stored in Australia. Production is specified as Microsoft Azure, Australia Southeast (Melbourne), with backups in Australia and working-out images in the same region — held inside the database today, and in Azure Blob Storage once migrated.

1.2Three narrow outbound flows leave Australia, and they are named below. Two of them carry no school or student data at all. The third — transactional email — carries staff contact details and must be pinned to an Australian region before go-live; the provider is not yet chosen. They are set out in section 3.

1.3We do not say “nothing leaves Australian jurisdiction”. That claim has appeared on the public website and it is over-broad; it is being removed. The precise form is this document, and it is more useful to a school than the slogan was.

2 Every component, and where it is

Every component of the service, including the ones that hold nothing.

2.1Azure Australia Southeast is a Melbourne region under Microsoft's published data-residency commitment for Australian customers, and the services used are ISO 27001, SOC 2 Type 2 and IRAP assessed. Evidence is collected before go-live and filed with our third-party assurance records.

3 The three flows that leave Australia

These are stated at the front of any hosting answer, not buried. An assessor reading the source will find all three, and a school that learns about them from someone else has been misled by omission. Every third party that receives data is listed in the Sub-Processor Register.

3.1 Model provider — United States

Two separate calls to the same provider.

Inference. A page of a child's handwritten working out crosses to the United States for a model to describe the method used. The payload is assembled from an allow-list: the image, the question, the answer given, the mark our own code has already decided, and the year level as a band — “middle primary”, never a number. No identifier of any kind crosses: not a name, not a student number, not a database id, not a pseudonymous token. One answer per request.

The working-out image is pseudonymised, and we do not use the stronger word. A child may write their name on their page — every child has been taught to do exactly that since Foundation. Four controls apply, plus a contractual no-training term, and the fourth control is a scan of the model's own response, which fires after the call rather than preventing it. We never claim the AI can never see a name; we say what we detect and quarantine, and we say where the residual sits. What is sent to the model, and why, is also set out in the Privacy Policy.

Admin API. Provisioning a per-school workspace and API key sends the school's name to the provider. No student data, no staff data, no email addresses. It is named here because it is a real outbound call to a US endpoint and it is not covered by the inference description.

3.2 Password breach check — global endpoint

When a staff member sets or changes a password, the first five hexadecimal characters of a SHA-1 of the candidate password are sent to the Have I Been Pwned range API, which returns every hash suffix sharing that prefix. The match is made on our server.

No password, no username, no email address, no school name and no student data leaves. The endpoint cannot reconstruct the password or identify the account — that is what k-anonymity means here. Padding is requested so response size reveals nothing. The call is never made for a student; students have no password. A failed or slow call returns “unknown” rather than “safe”, so an outage cannot quietly weaken the check, and a school that objects to the call can have it turned off, leaving the built-in common-password list.

3.3 Transactional email — provider not yet chosen

Two messages leave the product: a teacher's account-setup invitation and a password reset. Each carries the staff member's first name, their email address, their school's name in the subject line, and a single-use link containing a bearer token.

That token is the reason this is the most sensitive of the three flows, despite being the least technical-sounding. Anyone holding the URL can set that account's password until the link is used or expires. Setup links last 7 days and work once; reset links are short-lived; every send is recorded with its transport and purpose.

Three providers are named in the code as candidates: Resend, Postmark and Amazon SES. Two of the three have no Australian region. Amazon SES has ap-southeast-2 (Sydney). All three would deliver the mail, so this is not a deliverability question — the choice decides whether staff names, staff email addresses, school names and live password-setting tokens are processed and logged offshore.

4 Backups and disaster recovery

4.1Database backups. Azure-managed, 35 days, point-in-time restore, encrypted with AES-256 at rest by default. They stay in Australia Southeast. Where geo-redundant backup is enabled, the paired region is Australia East (Sydney) — still Australia, and the setting is confirmed and recorded rather than assumed.

4.2Working-out images. Held inside the database today, so they are covered by the database backup rather than by an object store with its own lifecycle. Once migrated, blob storage uses same-region redundancy with soft delete and versioning, and cross-region replication stays off unless the pair is confirmed Australian.

4.3Disaster recovery. Zone-redundant high availability within Australia Southeast, with a restore into Australia East if the whole region is lost. A restore has never been tested, because there is nothing to restore. The first test is at go-live and its date will be recorded.

4.4Where a backup may go. Backups are never restored into the test environment or onto a laptop.

4.5Retention today is honest and unflattering. Nothing is ever deleted. There is no purge routine, no deletion action and no export. Encrypted backups held for 100 days is a commitment, not a deployed fact, and the retention work is tracked separately.

5 Test and development environments

ST4S H1 asks about all components, so both are stated even though neither holds anything real.

5.1Test. A shared cPanel host carrying synthetic data only — invented schools, invented students, invented staff, invented email addresses. No school data and no student data ever goes on it, and a production backup is never restored into it.

5.2Development. Three founders' laptops in Victoria, working against synthetic data with full-disk encryption and no production credentials. No school or student data is ever copied to a laptop.

6 Who can access the data, and from where

6.1From Australia only. All access to production data is by the three founders, from Australia only. There are no employees, no contractors and no offshore support.

6.2Notice before, not after. If that ever changes — a person outside Australia, or a provider moving a component — schools are told before it takes effect, not after.

9 Who to ask

This statement is owned by the Security Officer and countersigned on privacy review by the Privacy Officer. If a school believes a line here is wrong, or that a component is missing from the table in section 2, say so — the correction goes into the next version.

10 Version history

• 1.018 August 2026First issue.

Next review 18 February 2027, and immediately on any change to a provider's region.

Signed by Jacob Clemens, Founder and CTO and Security Officer, on 18 August 2026. Privacy review countersigned by Jake Gatto, Founder and CEO and Privacy Officer, on 18 August 2026.