Wizardry Privacy Policy

This policy explains what personal information Wizardry collects about students, why we collect it, who else sees it, how long we keep it, and what you can ask us to do with it.

The Privacy Act 2020 does not require an agency to publish a privacy policy. What it requires is notice at the point of collection, under Information Privacy Principle 3 and, since 1 May 2026, Principle 3A for information collected from someone other than the individual themselves. It also requires every agency to appoint a privacy officer, under section 201.

Wizardry is an online platform that teaches English literature analysis to New Zealand secondary students, covering NCEA, Cambridge International and IB.

It is operated by Michael Sun.

The legal structure is a sole proprietorship. In practical terms that means Michael Sun is personally the 'agency' responsible under the Privacy Act, and personally answerable to the Office of the Privacy Commissioner.

Four people work on the platform. Only one of them, Michael Sun, can reach student information at all. Everyone else works against a separate environment containing invented accounts and no real student records, and everyone is bound by a written confidentiality agreement.

Our privacy officer is Michael Sun. You can reach him at support@wizardry.org.nz. He is responsible for compliance with the information privacy principles, for answering access and correction requests within the statutory timeframe, for assessing and notifying privacy breaches, and for dealing with the Privacy Commissioner.

Children have the same privacy rights as adults under the Privacy Act, and the Act requires particular care when collecting information from them. Our users are roughly 13 to 18 years old.

We collect only what the service needs.

Account details. An email address and a display name, which the signup form asks for as 'first name or nickname'. We need these to create the account, to sign the student in securely, and so that a teacher can tell whose work is whose.

Course and year level. Which qualification the student is working towards, being NCEA, Cambridge International, IB or simply exploring, and their year level. We use these to serve the right curriculum. For students whose school set up their account, both are set by the class rather than by the student.

Study intent. A goal and a pace, chosen during onboarding, which set the student's starting pathway.

Everything the student writes. Essays and their revisions, close-analysis paragraphs and their annotations, practice drill answers, Lab documents and the notes attached to them, case-study reading notes, and any images uploaded. It is necessary for the service, because students cannot be taught to write without their writing being stored.

Student work is unconstrained free text. A student writes about set texts such as Macbeth or Of Mice and Men, but nothing stops them typing anything at all, and we do not filter what they write.

Assessment written about the student. Teacher feedback, grade labels and scores on submitted work, and any note a teacher makes when reviewing a marking complaint. This is academic information about the student written by somebody else.

AI feedback and scores. Feedback, rubric judgements, suggested grades and diagnostic comments generated about the student's work. Section 6 explains this in detail.

Learning activity. A record of meaningful actions: which module was opened, which item was attempted, on which part of the platform, at what time, and in which class context. This is what builds the student's progress view and shows a teacher where somebody is stuck. Forty-one different kinds of action are recorded.

One item inside that record is worth naming specifically. When a student searches the built-in toolbox, the words they typed are stored alongside the action. The searches are short, and we mention them because they are text the student typed rather than an action they took.

Time on task. How long a student was genuinely working, measured by a signal sent every thirty seconds that fires only while the browser tab is visible and the student has interacted within the previous two minutes.

School and class records. School membership, class enrolment, which teacher a student is assigned to, and progression between years.

Invitation email addresses. When school staff invite a student, we hold that address before any account exists. Section 4 explains this, because it is the point at which we hold a child's details having never had contact with them.

Payment identifiers. For individual subscribers only, a Stripe customer reference and a subscription status. Selected schools containing their students, teachers and administrators are not billed, and school users will not pass through Stripe at all.

Records of our own compliance. A record of when notice was given and acknowledged, and a permanent, unalterable record of privileged administrative actions.

What we deliberately do not collect

There is no date of birth, no age, no home address, no phone number, no gender, no ethnicity, no guardian or parent details, no photographs and no government identifier anywhere in our system. There are no fields for any of them.

Because we hold no date of birth, we cannot verify anyone's age. For a school student, age is whatever the school knows. For an individual subscriber, we know nothing about it at all.

Most of what we hold comes from the student directly, at four points: creating an account, completing onboarding, editing their settings, and doing the work itself. Learning activity and time on task are collected automatically as the platform is used, which is disclosed at signup and again in the notice shown at first sign-in.

Payment details, for individual subscribers, are collected by Stripe on a page hosted by Stripe. The browser leaves our site entirely to enter them. Thus no card number, expiry date or security code ever reaches us.

Information we collect about a student from somebody else

Some information reaches us from the school, or is written about the student by others. Principle 3A requires us to take reasonable steps to make the student aware when that happens, and this is where it happens.

The school gives us a student's email address when staff invite them, and their name, class, year level and course when they are placed in a class. Teachers write feedback, grades and scores about the student's work. Our AI marking generates feedback and scores about it. Schools also record progression, graduation and withdrawal.

We give notice of all of this the first time a school-provisioned student signs in, in wording written specifically for that situation, and we record the acknowledgement with a timestamp.

For an individual subscription, supplying a name, an email address and a password is required to create an account. There is no anonymous mode. If you do not supply them you cannot use Wizardry.

Recording learning activity is not optional while a student is using the platform, because the platform cannot teach without it. What a student can do is withdraw consent, which stops us recording anything new from that moment. Section 10 explains what withdrawal does and does not do.

Student writing is marked by Google's Gemini models. We use three of them: gemini-3.5-flash, gemini-3.1-flash-lite and gemini-2.5-flash-lite.

Exactly two things are sent for each marking request: our marking rubric, and the student's writing. No name, no email address, no user identifier, no school name and no class name is included in any of them. We have verified this across every one of the eight components in our system that builds a request. To the model, a submission is a piece of writing with no person attached.

We use Google's paid service. On the paid tier, Google's published terms state that Google does not use submitted content to improve its products. Google retains submitted content for a limited period, solely to detect abuse of its service.

Where the processing physically happens is not guaranteed. We call the Gemini Developer interface, which Google does not restrict to any region, so student writing may be processed outside Australasia. Google offers a service with an Australian regional endpoint and moving to it is on our goals.

What comes back is stored. The AI's feedback, scores, rubric judgements and comments about the student's work are kept against that student's record, and the student can ask to see all of it. Our internal record of AI usage keeps cost and token counts, and it also retains that feedback content. It does not retain the student's submitted text.

Student writing is wrapped in delimiters and framed to the model as material to be marked rather than as instructions to follow, so a student cannot type instructions into their own essay to manipulate their mark or extract our marking rubric.

AI marking is a diagnostic aid. It is never a final grade, it carries no standing with any qualifications authority, and the teacher's judgement governs.

Inside the school

A teacher can read any student in their school, not only the students in their own classes. The interface defaults a teacher to their own classes, but that is a default in the display rather than a wall in the system. A head of department has the same reach, plus staff and class management.

Teachers can read progress summaries, accuracy analytics, the diagnostic showing which analytical step a student breaks at, and the raw record of learning activity. They can read practice drill answers and close-analysis work.

Teachers cannot read drafts a student has not submitted. Work in the Lab and in the essay editor is the student's alone until they hand it in.

Once a student submits, a teacher can read the full text. Submitting freezes a copy and school staff can read all of it. Students are told this when they submit.

Students cannot see anything belonging to another student. There is no messaging, no comments, no forums, no shared files and no public profiles.

Schools cannot see individual subscribers, and individual subscribers cannot see schools.

Teachers and students at one school cannot read identifiable records belonging to another school. That separation is enforced in the database itself and is tested. One qualification: our internal reporting views calculate platform-wide averages for individual practice items, and a signed-in user can read those averages. No name and no identifier is exposed. Where an item has been attempted by only one student, the average is that student's score.

Outside the school

Four providers hold or process information on our behalf.

Supabase, running on Amazon Web Services in Sydney, Australia, holds the database, handles sign-in, stores uploaded files and sends account emails. It holds everything described in section 3.

Vercel, also in Sydney, hosts and delivers the application. Traffic passes through it, and its access logs record IP addresses in the ordinary course of serving a website.

Google receives student writing for marking, with no identifying information attached, as described in section 6.

Stripe receives payment details for individual subscribers only, collected directly by Stripe. It never receives anything about a school user.

We also use Vercel's analytics and performance tools, which collect aggregate page metrics containing no student identifiers, and we keep our source code in a private repository that contains no student data.

We hold no signed data processing agreement with any of these providers, no audit report from any of them, and no completed vendor assessment. All four are used on their standard published terms. If your procurement process requires signed sub-processor agreements, we do not currently meet it, and you should weigh that when deciding.

We will tell your nominated contact in writing at least 20 working days before adding any new provider.

We do not sell personal information, we do not disclose it for advertising, and we run no advertising, marketing or cross-site tracking of any kind.

Your own IP address

We do not store IP addresses in our database. We read one briefly when checking an email address at sign-in, in order to rate-limit abuse, and it is never written down. Our hosting provider logs IP addresses as an ordinary part of serving a website.

All student information is held in Sydney, Australia. Nothing is stored in New Zealand.

Under section 11 of the Privacy Act 2020, where one agency holds information as an agent for another, the information is treated as held by the second agency, and passing it between them is not a disclosure. Supabase and Vercel hold and process information solely on our behalf. Storing your students' information with them is therefore not a cross-border disclosure under Principle 12. It remains our holding and our responsibility, and our obligation is the security obligation in Principle 5.

The same reasoning applies to Google on the paid tier, because Google's terms bar it from using submitted content for its own product improvement. Principle 12 would engage if an overseas recipient used the information for its own purposes.

Stripe sits outside this analysis, because Stripe processes payment information under its own regulatory obligations rather than purely as our agent. Stripe is used only for individual subscriptions, and no school user ever reaches it.

Principle 9 prohibits keeping personal information for longer than it is needed.

We hold a retention schedule in the database itself, with four rules. Closed accounts are erased 365 days after closure, which covers appeals, re-enrolment and end-of-year reporting. Raw learning activity is de-identified after 730 days, being two academic years, so that cohort analytics keep working while the individual trail does not. Our record of AI cost is kept for seven years as an ordinary business record, with the feedback content removed when an account is erased or de-identified. Erasure certificates are kept for ten years, because the proof that an erasure happened has to outlive the data it erased.

The schedule runs as an automated daily sweep.

One thing must be said plainly. The sweep currently runs in observation mode. Each day it calculates what it would erase and records that, and it erases nothing. This was deliberate, so that we could watch the schedule behave correctly against real data before letting it delete anything.

Some records are permanent by design and cannot be edited or removed. Our learning activity log and our administrative audit log are both append-only, enforced by the database. The audit log contains historical email addresses and names. Submitted work snapshots are frozen and cannot be altered afterwards, including by us. Section 10 explains what this means for a correction request.

Deleted information persists in backups until those backups age out on their ordinary cycle.

Records held by others follow their own retention: Stripe under its obligations for payment records, and Google for the limited abuse-monitoring period described in section 6. Draft copies of a student's work are also saved inside their own browser so that work survives a crash, and those stay on the device until overwritten or cleared.

Getting a copy of what we hold

A student can download everything we hold about them from Settings, using 'Download my data'. It comes as a structured file, or as a spreadsheet if preferred, and covers their profile, progress, module attempts, essays and revisions, close-analysis work, Lab documents, practice answers, case-study sessions, submitted assignments, enrolments, school memberships, consent records and sessions.

If you would rather ask us, email support@wizardry.org.nz. We will respond as soon as reasonably practicable and no later than 20 working days after we receive the request, which is what the Privacy Act requires. If we need longer, we will tell you why inside that period. We do not charge.

Correcting something wrong

A student can change their display name themselves. Individual subscribers, teachers and administrators can also change their course and year level. Class-backed school students take both from their class. Classless school accounts can change their year level, but their school-set curriculum cannot be changed.

There is no way to change the email address on an account. No such feature exists.

Learning activity records and administrative audit records are technically unalterable. If a correction were sought against one of those, we could not comply by editing it. Where we cannot correct, Principle 7 entitles you to have a statement of the correction sought attached to the record, and we will attach one.

Teacher-written feedback and grades belong to the school rather than to us. Ask the school.

Withdrawing consent

A student can withdraw consent from Settings, at any time.

Withdrawing stops us recording new activity from that moment. It does not by itself delete what we already hold. Use erasure for that. We state both halves because a withdrawal that quietly left everything in place would be a misleading offer.

One thing that is not deletion

A student can remove an individual essay or paragraph from their workspace. Where the piece contains real writing, this hides it from the student and keeps the record. Where the piece is blank or barely started, it is removed entirely. And if the work had already been submitted, the frozen copy held for the teacher is untouched either way.

We spell this out because 'delete' in that context means 'remove from your workspace', and a student who believed otherwise would have been misled. For real deletion, use erasure.

Who can ask on a student's behalf

We may ask a requester to verify their identity before we release information about a student. Where a parent or guardian asks on a child's behalf, we consider the request in line with the Privacy Commissioner's guidance on requests for a child's personal information, which does not assume that a parent is automatically entitled to everything.

Authorisation is enforced inside the database rather than only in the application, so a defect in the interface cannot hand somebody data they should not have. Every table holding user information is protected, and an unauthenticated request returns nothing from any of them. We test this across every table as a matter of routine.

Traffic is encrypted using TLS 1.2 and 1.3, and the older, weaker versions are refused. Information at rest is encrypted to AES-256 by our hosting provider, which holds the keys; we hold none. Sign-in tokens expire after an hour and are re-checked against the authentication service on every request rather than trusted locally.

Sign-in cookies cannot be read by page scripts. A content security policy and clickjacking protection are configured. A firewall in front of the application rate-limits sign-in attempts.

Administrative access to another person's information is logged.

Answer keys for tests sit in tables that no student and no teacher can read, and students have no route to write to their own grades.

What we do not have: no ISO 27001 certification, no SOC 2 report, no cyber insurance, and no external penetration test. We have not yet been assessed under Safer Technologies for Schools, the Ministry of Education's assessment programme for education technology, and we intend to seek it. A security remediation programme is underway, and section 12 of our Information Security Policy lists every open finding with its fix and target date.

Our users are 13 to 18. New Zealand has no statutory age of privacy consent and no equivalent of the American children's privacy legislation, but the Privacy Commissioner expects heightened care with children's information, and there is no exemption for small operators.

We do not verify age and we do not capture parental consent. Neither is possible without collecting a date of birth, which we have chosen not to do.

We do not read student writing for signs of distress, and no system flags it. If a student writes about self-harm, abuse or a crisis in an essay, nothing detects it and nobody is alerted. The text is stored, and a teacher may read it if the work was submitted and they happen to look.

This is the most important limitation in this document. Your school's own safeguarding processes remain the control. We are not a safeguarding system and must not be relied on as one.

We use cookies that are strictly necessary to run the service, and nothing else.

Sign-in cookies keep a student signed in between pages. They cannot be read by page scripts, and there is no way to use Wizardry without them.

One additional cookie records which school an administrator is currently viewing, and it applies only to administrators.

Our analytics tools measure page performance and load times in aggregate, with no student identifiers.

Separately, the platform saves draft copies of a student's work inside their own browser so that work survives a crash or a closed tab. That content stays on the device and is not sent anywhere until the student saves or submits.

We use no advertising cookies, no marketing cookies and no cross-site tracking of any kind.

If you are unhappy with anything in this policy, or with how we have handled personal information, email support@wizardry.org.nz. Michael Sun, our privacy officer, handles complaints personally.

We will acknowledge your complaint within 10 working days, tell you who is dealing with it, and respond substantively within 20 working days. If we need longer we will tell you why and when to expect an answer.

You can complain to the Office of the Privacy Commissioner at any point. You do not need to come to us first, and you do not need our permission.

• privacy.org.nz
• 0800 803 909

The Commissioner's service is free and independent.

Privacy officer: Michael Sun

Postal address: 60A Bassett Road

Email: support@wizardry.org.nz

This policy is governed by New Zealand law.