Privacy

Who we are

Omibrook is operated by an independent sole operator trading as Omibrook. Enquiries about this page, and any request to export or delete data, go to privacy@omibrook.com.

On roles, because it determines who you should ask for what. For the records a teacher creates about her students, the school or district is the party that decides what is collected and why; Omibrook stores and processes it on her behalf, and acts under her instructions. For a teacher’s own account details we are the party responsible. Where a district requires it, we will sign a data processing agreement that says this in enforceable language — see Security and subprocessors.

What we hold about students

A student record in Omibrook has two required fields and one optional one. That is the whole record.

• Initials — required, four characters maximum.
• Grade band — required. One of pre-K, K–2, 3–5, 6–8, 9–12, or transition. A band, not a grade and not an age.
• A display name — optional, blank by default, never required and never asked for during sign-up. A teacher who will not put student names in a third-party tool can run the entire product without ever filling this in, and nothing degrades if she doesn’t: progress reports fall back to initials. If she does fill it in, it is because she chose to, and she can clear it at any time.

Attached to a student, we then hold the work:

• Goals, stored exactly as the teacher wrote or pasted them, plus the measurement definition (method, cadence, baseline, criterion). A goal is free text authored by a teacher, so whatever she typed is what we hold — including a name, if she wrote one into the goal itself.
• Probe sheets — the generated specification for each of the eighteen sheets, and a short code identifying each one.
• Data points — a score, when it was collected, and who collected it. A correction never overwrites a score: it is recorded as a new entry that supersedes the old one, and both are retained. That is deliberate, because a progress record that can be silently rewritten is not evidence.
• Accommodations — the list for a student, an optional check cadence, and a log of when each was provided.

Printed sheets carry initials only, always, regardless of whether a display name was entered — and so does any link sent to a paraprofessional or general-education teacher to collect data.

We do not claim this data is anonymous, and you should not accept a product that does. Initials plus a grade band plus a detailed IEP goal plus a progress history is directly related to an identifiable student — the teacher can identify the child instantly, and so can anyone holding that caseload. We treat these records as education records and the obligations that follow from that as ours.

What we cannot hold

The fields below do not exist as columns in our database. This is not a setting that defaults to off, and it is not a promise not to use them — there is nowhere to put them, a test in our build fails if anyone adds one, and a migration that introduced one would have to be written deliberately and would show up in our version history.

• Date of birth
• District or state student identifier
• Home address, or any address
• Parent or guardian contact details
• Disability category, as a structured field
• Photographs of a student
• Pronouns or gender

On that last one: the product never infers a student’s gender, including from a name a teacher has typed. Our goal-drafting and report-drafting prompts are instructed not to use gendered pronouns about a student at all, and we test for it.

Students do not have accounts and never interact with Omibrook. There is no student login, no student-facing screen, and no mechanism by which we could collect anything from a child directly.

What we hold about you, the teacher

• Your email address, and a name if your sign-in provider supplies one. Authentication is handled by Clerk; sign-in is by email or a Google account. Clerk holds teacher identity only and never holds student data.
• No password. We never see one — Clerk handles credentials, and there is no password field anywhere in our database.
• Server logs, which record the request path, a request identifier, a timestamp and the response status. These exist to diagnose faults and investigate abuse, and are kept for a short period.
• Error reports, when something breaks. These are sent to Sentry with personally identifying information switched off and request bodies scrubbed, because an unfiltered error report is a copy of student data sitting in a third-party system.

What is sent to an AI model, and what is not

Three features use a large language model: parsing a goal you have pasted, drafting a goal from a skill you describe, and generating reading-passage content for certain probe types.

What is sent, stated plainly: the goal text itself, the student’s initials and their grade band. The goal text is whatever you wrote — so if you typed a child’s first name into a goal, that name is in what we send. Nothing else about the student is included, because nothing else exists.

Where it goes: Anthropic’s API, in the United States. Under their commercial terms, data sent through the API is not used to train their models. We do not send data to any other model provider.

What is never sent: collected scores, the data-point history, your caseload as a whole, or any student’s optional display name as a field. The model is used to structure text you wrote; it is not given the record.

If your district’s policy prohibits sending any student-related text to a model vendor, the probe stack, data collection, the caseload view, the graph and accommodations all work without these three features — you write the goal and its measurement definition yourself, which takes longer and is otherwise identical.

Cookies and analytics

No third-party script runs on any page that can display student data. This is an engineering rule in our codebase with an automated check that fails our build if it is broken, not a policy we remember to follow. The analytics below run on this public website — the home page and these legal pages — and nowhere else. Once you sign in, there is no Google or PostHog code on the page at all.

On the signed-in product

• A session cookie, set by Clerk, which is what keeps you signed in. Strictly necessary; the product cannot work without it.
• A display preference, kept on your device, for whether optional student names are masked on screen — for an IEP meeting where you are screen-sharing in front of other families. When masking is on the name is not sent to your browser at all, rather than hidden with styling, so it is not recoverable from the page by anyone in the room. The preference itself never leaves your device.

On this public website

• Google Analytics 4 (cookies beginning _ga), to count visits and see which pages are read. IP anonymisation is on.
• PostHog (cookies beginning ph_), to see which parts of the home page people click. Session recording is switched off, both in our code and in the PostHog project, so there is no video of your visit. Visitors are counted anonymously; we do not build a profile for anyone who has not signed in.

We do not show a cookie consent banner. Our audience is in the United States, these cookies are analytics rather than advertising, no advertising or cross-site tracking network is loaded, and nothing is shared with an ad platform. If you would rather not be counted, your browser’s tracking protection or any blocker will stop both, and nothing on this site breaks as a result.

Who else can see it

We do not sell data, we do not share it for advertising, and we do not disclose it to anyone outside the list on our subprocessor page. That page names every company in the chain, what each one holds, and which country it is held in. It is maintained as part of the product rather than written once.

Beyond those processors, data leaves our systems in exactly three cases:

1. Because you sent it. You print a probe sheet, export a progress report, or send a colleague a link to collect data. Where you send such a link, it shows initials only, is scoped to the goals you picked, and can be revoked.
2. Because the law requires it. A valid legal order. If we receive one covering student data and we are permitted to tell you, we will, so that your district can respond.
3. Because the business changed hands. If Omibrook were acquired or transferred, records would move with it, and this policy and any signed data processing agreement would bind the recipient. We would notify account holders before it happened.

Export, correction and deletion

Today these are handled by email, and we answer within seven days. Write to privacy@omibrook.com from the address on the account and say what you want: a copy of everything, a single student removed, or the whole account deleted. Nothing is charged for and no reason has to be given.

We would rather these were buttons, and they are being built — a privacy right with an inbox in front of it is a privacy right with a queue in front of it. This page will say so when they ship. We are telling you which it is today rather than describing the intended version, because the difference is the kind of thing you would reasonably check.

• Export gives you your caseload, goals, every data point and the accommodation log in a machine-readable file you can keep or hand to your district.
• Deleting a student removes that student and everything attached to them — goals, probe sheets, data points, accommodation records. That is a cascade in the database rather than a flag being set, so there is no copy left marked inactive.
• Deleting your account removes every student record you created, by the same cascade.
• Correction is ordinary editing for a student record or a goal. Collected scores work differently on purpose: a correction is appended and supersedes the earlier value rather than overwriting it, so both remain. If you need an erroneous value removed outright rather than superseded, write to privacy@omibrook.com.

A deletion is permanent in our live database immediately. Encrypted backups are kept for a short rolling window for disaster recovery, so a deleted record may persist inside a backup until that window passes, after which it is gone. Backups are never queried to answer anything; they exist only to restore the whole database.

If you are a parent or guardian, the record about your child belongs to the school, not to us. Your rights of access and correction run through the school or district, which can retrieve or delete anything in Omibrook themselves. Write to privacy@omibrook.com if a school is not responding and we will help it do so.

How long it is kept

• Student records and the data attached to them: until you delete them or close your account. We do not expire a caseload — a progress history spanning several years is the point of it.
• An inactive account: if an account goes unused for two years, we will write to the address on it before deleting anything, because a teacher who has changed districts should not lose records without warning.
• Server logs and error reports: a short retention window, then discarded.
• Analytics on this public site: as configured in Google Analytics and PostHog, and not joined to any account.

How it is protected

The detail is on Security and subprocessors. The short version:

• Isolation is enforced by the database, not by our code remembering to filter. Every table holding student data has row-level security, every query runs under the identity of the signed-in teacher, and the role the application connects as owns nothing and cannot bypass those policies. An application bug that forgot a filter would return nothing rather than someone else’s caseload.
• Student data is read and written only on the server. Your browser never queries the database.
• Encrypted in transit and at rest.
• Two-factor authentication on every operator account that can reach the data.

We are a small operation and will not pretend otherwise: we hold no SOC 2 or ISO 27001 certification, because those start at several hundred dollars a month with our vendors. What we offer instead is specific and verifiable — a signable data processing agreement, a US hosting statement that is true, and a subprocessor list that is complete.

Changes to this page

The effective date at the top is the date the current text took effect, and it is updated by hand when the substance changes rather than on every deploy. If a change materially affects what we collect or who processes it, we will email account holders before it takes effect, not after.

Contact

Privacy, data processing agreements, export and deletion requests: privacy@omibrook.com.

Anything else: support@omibrook.com.