Privacy
What this site collects, which is one form and two cookies.
This page has not been through a lawyer, because there is not yet a company for a lawyer to advise. A privacy policy assembled from a template is exactly the document this site tells you not to accept from a supplier, so what follows is the plainer thing instead: a statement of what the system does with personal data, written on 5 August 2026 and checked against the code the same day.
There is no registered company yet, so there is no legal entity to name as the controller of what you send us. The footer says the same thing for the same reason. Until there is one, the people answerable for this page are the people who wrote the software, and the only route to them is the form on the contact page.
When the entity exists this page is replaced by a document somebody qualified has read, and that replacement will carry a date as well.
What we collect
Everything the system stores about you
The contact form
One submission writes one row to one table. Below are its columns. The row belongs to no organisation, because somebody writing in to ask whether they should become a customer belongs to none, and that is the whole point of the message.
- Your name
- Required. Between 1 and 120 characters, checked by the database rather than only by the form.
- Your email
- Required. Trimmed and lower-cased before it is stored, so the same address written two ways is one address.
- Your school
- Optional, up to 200 characters. Empty if you leave it empty.
- What you wrote
- Required, between 20 and 4,000 characters. The 20-character floor is the cheapest spam filter available: free for a real enquiry and fatal to a bot with nothing to say.
- A hash of what you wrote
- A SHA-256 digest of the message. It exists so that pressing the button twice, because nothing visibly happened, produces one row instead of two.
- A keyed hash of your address
- HMAC-SHA256 of your IP address under a server-side secret, truncated to 32 characters. The address itself is never written down. The only question ever asked of this value is whether the same submitter appeared in the last ten minutes.
- Whether it contains a link
- One true-or-false flag. It sorts the list a person reads. It never rejects anything, because a genuine enquirer linking their own school is the likeliest single use of a URL in that box.
- Three timestamps
- When it arrived, when somebody marked it handled, and the date it expires. The expiry is a column on the row rather than a sentence in a policy document, which is what makes the retention period below a thing you could check rather than a thing we assert.
There is one more field on that form, positioned off the screen and taken out of the accessibility tree, which no person ever meets. If something fills it in, the submission is answered exactly as a real one is and no row is written. Telling a bot it was detected tells it what to change next time.
What is not here
The parts of a privacy policy anybody actually reads
- There is no analytics beacon. Not Google Analytics, not a privacy-friendly alternative, not a counter of our own. Nobody is tallying your visit, so there is nothing to tell you about what we do with the tally.
- There is no advertising pixel and no third-party tracker. The public site ships a short list of third-party libraries and every one of them renders, validates or draws — none of them reports anywhere, and none of them opens a connection to anybody. We are not putting a number on that list here, because a number is wrong the first time somebody adds a package and nobody thinks to come back to this page.
- The typeface is compiled into the build rather than fetched from a font service, so opening a page here makes no request to a third party at all.
- There is no cookie banner, because there is nothing to consent to. Two cookies exist in the whole application, both strictly necessary, and a visitor who neither signs in nor has a submission rejected leaves with none.
- There is no mailing list, no newsletter and no follow-up sequence. There is no mail library anywhere in the dependency tree and no code path that opens a connection to a mail server. One email exists in the whole product and it is described below.
- Nothing is bought, sold, enriched or appended. There is no customer-relationship system behind the form. It writes a row, and a person reads the row.
- You are not profiled and nothing decides anything about you. Three automated rules do act on a submission — the hidden field, a ten-minute duplicate check, and a ceiling of five submissions an hour from one address. All three decide whether a row is written. None of them draws a conclusion about the person writing.
Retention
What happens to an enquiry, in order
- 01
It is written
One row, one table, one database. Nothing is copied anywhere else on the way in — the log line recording that an enquiry arrived carries no name and no address, deliberately, because a second copy in a log store with a different retention period is a copy nobody remembers to delete. - 02
A person reads it
From a terminal, with a command run against the database. There is no admin console, no inbox inside the product and no endpoint that hands an enquiry back — the public interface can write one and cannot read one. Reading requires the database credential, which the people who operate the system hold and nobody else does. - 03
It is marked as handled
A timestamp on the row. Handled enquiries drop out of the default listing and are not looked at again. - 04
It reaches its expiry date
The row carries the day it was written and the day it expires. The retention period is 180 days, which is the six months the contact page promises, and it is set once when the row is created rather than calculated later by anything. - 05
Somebody runs the deletion by hand
This is the part worth stating plainly. Deleting expired enquiries is an operator command, not a scheduled job: this product has three deployable pieces and a timer would be a fourth. So the expiry date on the row is exact and the moment of deletion is not. If it matters to you that one particular enquiry is gone, ask, and it is deleted then rather than at the end of the window.
Your side of it
Asking for a copy, or asking us to delete it
The route is the contact form. There is no published mailbox yet because there is no mailbox yet, and the footer prints nothing rather than an address nobody reads. Say what you want done. Producing a copy is one command and deleting the row is another, and both are run by the same person who read the enquiry in the first place.
We are not going to quote you a statutory response time we have never had to meet. What the contact page already commits to is that somebody reads what arrives, by hand, inside two working days. That is the same person and the same two days.
Three things a finished privacy policy contains that this one cannot: the controller’s registered name and address, the supervisory authority you would complain to, and a data protection officer. All three follow the company, and there is no company yet. Leaving the three gaps visible is more use to you than filling them with something that reads right.
If you are asking on behalf of your students rather than about yourself, the processing terms are the next page, including the country the data would sit in. Data processing
Send one chapter.
Not a demo of somebody else’s course. A chapter of yours, converted properly, so you can look at your own questions and your own page numbers and decide whether it is any good. Pick the chapter you know best. If it is no good, you have lost an email.
We will ask who owns the copyright before we convert anything. If you do not hold the rights to the material, we will say so rather than take the work.