Privacy Policy

1. Information the Service handles

District and school staff enter or upload the following to build a schedule:

• School settings — the bell schedule (its periods and their names, the days each meets, semesters or quarters, and how many periods a full-time teacher teaches), enrollment per grade (a number), class-size caps by class type, program toggles (CTE, honors, special-day classes), the school's FTE total, the rooms on the site (name, type, seats, and optionally a room extension), and a calendar of the year's scheduling steps with the dates you set, a note of who owns each (a role, or a name you choose to type), and which steps you have marked done, and when.
• The course master — a course list: the Synergy CRS401 export, the printed course catalog PDF, or another course spreadsheet. Only course IDs, titles, departments, credits and college-prep status (with its UC/CSU a–g subject letter, when the file shows one) are kept; a PDF's course descriptions are never read. No student information is in this file, and a file with a student column is refused. A district catalog is stored per district: one uploaded by the district director on the district page is the catalog in force for every site in that district, and it overrules a site's own. A site's catalog is stored per site: a site administrator uploads one only while the district has none; it is kept for that site only, the moment it is read, and Undo (or "Remove it") removes it again. When the district later uploads its catalog, a site's earlier upload is kept but not used — it stays in the database, visible to that site's administrator and to the district's director, until the site deletes it or the district removes its catalog (then it is in force again). While a site's plan is finalized its catalog cannot be changed at all, by anyone, until the plan is unlocked. A district default bell is stored per district: the district director may build one on the district page; a new site starts from a copy of it, kept in that site's own schedule, and saving a new default never changes a site that already has a bell. Neither the district default bell nor the district default graduation requirements (below) contains student information.
• Graduation requirements — the district board's graduation policy (credits by subject), pasted or dropped as a PDF, Word or text file so the Service can propose the site's requirement rows. The file is opened in your browser and only its text is sent to be read (see below); the file and the text are not stored. What is kept is what was read from it — each subject, its credits, the named courses, any grade the policy names for one, any choice-of-courses requirement with its listed options, and the sentence each was read from — and the requirement rows a site accepts, in that site's own plan. A director's read on the district page is kept once per district and is the policy in force for every site in that district: a site then cannot read its own, and a read it made before is kept but not used (it comes back if the district removes its policy). Each site still keeps its own accepted rows, and a record of which version of the district's policy it last reviewed, so a new district policy can ask it to review. A text that looks like student records (a roster, a transcript, a birthdate) is refused before anything is sent.
• Course-request counts — Synergy's course-request count report: one row per course (per grade where the report gives it) with the number of primary and alternate requests. A site may also add last year’s report, kept the same way beside this year’s to show the trend. Only the resulting counts are kept; the uploaded file is discarded as soon as it is read.
• This year’s section list (optional) — Synergy’s master schedule section report (MST403 or MST402) or ABL’s section export: one row per section. Per course the tool keeps how many sections run, how many students are enrolled in them in total, how many seats they hold, and which teacher taught it, in which room and in which period — so next year can start from last year’s teachers and rooms. The school name, staff ids and any program or group columns in the file are never read; a list with a column naming a student is refused. The uploaded file is discarded as soon as it is read.
• Department rounds (once switched on) — a site administrator may send a department chair a link to that department’s plan. The chair needs no account. The chair’s name and email, as the administrator types them, are kept with the link. The link carries a random token; only a fingerprint of it (its SHA-256) is stored, and the link stops working when the administrator closes the round or the schedule is finalized. Through it the chair sees only their department: its courses with their request counts and section counts, the department’s teachers for next year with their FTE, the bell’s periods, any teacher, period and last year’s room already on its sections, and which periods its teachers already teach in another department (so the page can warn about a clash). The chair’s unsent draft is kept only in their own browser. What the chair sends — section counts, a teacher and a period for each section, and their notes — is stored with the administrator’s answer to each change. Nothing a chair sends changes the schedule until the administrator approves it. No student information is ever part of a round.
• Staff roster and preferences — teacher names, departments, credential areas, whether each teacher is returning, leaving or new next year (only which of the three — never a reason), and (where a district enables the optional teacher survey) each teacher's own stated credentials (the areas they tick, with a CTE specialty or other credential typed in — a claim their department chair confirms), course preferences (the courses they tick, and any course not on the list they suggest) and constraints for the coming year, whether they expect to come back, ask for a leave or a transfer, or retire (only which one — never a reason), and which kinds of class they are willing to take on (honors or AP, an extra class, AVID, an English-learner cluster, a named program). Teachers are identified to the survey by a single-use link; the survey stores no account for them. The survey link a site admin copies for teachers carries the school's course list (Course IDs, titles and departments, never a name) in the part of the link after #, which a browser never sends to any server.
• New-course proposals (through the optional teacher survey) — courses a teacher proposes, in their words, and whether the school accepted them: each one's title, department, the teacher's one-line reason and whether they would teach it, the date it arrived, the administrator's decision, kept with the administrator's display name and the date, the administrator's note, once the district creates the course its Course ID, and any Course ID the administrator said was not it (so it is not offered again). Nothing a teacher proposes enters the plan by itself.
• The schedule itself — the sections planned, which period and term each is placed in, and which teacher and room are assigned (on the board or on the staffing plan's Teachers view — one record, shared by both; a teacher picked by hand outside their credential or department carries a flag naming the department, so the publish check can list it); earlier versions of the schedule are kept so a change can be reviewed or undone. Each singleton decision and period lock is kept with the administrator’s display name and the date, as a round approval is.
• Notes on a schedule — a district director or a site's own admin may leave a short note on that site's schedule; each note is labelled by its author and the time it was written, never about a student. When the district office edits a site's schedule directly, the reason given for doing so is recorded as a note on that schedule.
• RSP and pathway figures — headcounts per grade and per course (e.g. 28 ninth graders in RSP English 9) — never a roster, never a student's name or ID.
• Account information — a staff member's email address and assigned role and school site, used for sign-in and access control.
• Customer type — whether a customer is a district of several schools or one school. It is business data the founder keeps on the district record, set at purchase; the pages read it only to choose their wording, and it is never sent anywhere.

Identifying a dropped file. When you drop a file, its header row and the shape of up to five sample rows are sent to Anthropic to work out what the file is and which column is which. A shape replaces every letter and digit with a placeholder ("Ava Diaz" is sent as "Aaa Aaaa", "412" as "999"), so no value from your file leaves your browser — only the header row as written. They are not stored — not on disk, not in a log. A file with a column about students is refused before anything is sent. If the identification service is unavailable, the file is identified by the Service's own rules instead, and nothing leaves your browser.

Reading graduation requirements. When you paste or drop your district's graduation policy, its text (at most 20,000 characters) is sent to Anthropic to be read into subjects and credits. It is not stored — not on disk, not in a log, not in a database. Only the accepted rows (in the site's plan) and the district default (on the district page) are kept, as described above. Text that looks like it is about individual students is refused in your browser and again by the Service, before it reaches Anthropic.

Reading a bell schedule. When you drop your site's published bell schedule on the bell builder — or on the setup drop zone and then press Read it as the bell — a PDF or a picture (PNG or JPEG), the file is sent to Anthropic to be read into periods, the days each meets and semesters or quarters. A Word (.docx) file is opened in your browser and only its text (at most 20,000 characters) is sent. The file and the text are not stored — not on disk, not in a log, not in a database. What comes back is a proposal shown beside your current bell; nothing is kept unless you press Use this bell, and then only the bell itself, in your site's settings (or, on the district page, in the district's default bell once the director saves it). A bell schedule holds no student information.

The setup assistant. The plan pages have a setup assistant. Its questions come from rules in the Service and its manual is part of the page: neither ever leaves your browser. The only thing it keeps is whether each of its questions was answered or put away (a flag and a short fingerprint of what caused the question, in the site's plan) — never anything you type. A question you type into its Ask box is sent to Anthropic, together with a summary of the plan's counts (for example sections per department, FTE totals, how many rooms and teachers) and no names of any person, to be answered. The question, the summary and the answer are not stored — not on disk, not in a log, not in a database — and the conversation ends when the panel closes or the page reloads. The answer only explains; it never changes the plan. A district director can turn typed questions off for the whole district on the district page; the questions and the manual keep working.

2. Where the data is stored

• Supabase (PostgreSQL), United States — us-west-1. Schedules, settings, each site's course catalog and the district's default catalog, staff rosters, survey responses, notes left on a schedule, and accounts are stored in a private database, encrypted at rest.
• Vercel serves the application and holds no district data at rest.
• Your browser keeps a working copy of the schedule you are editing (in the browser's local storage) so the page works offline and reloads instantly; it is the same data the database holds, on your own device, and is cleared when you sign out or clear site data.

3. Who can access the data

Access is enforced at the database with row-level security, so it cannot be bypassed by the app:

Sure Step personnel do not access a district's data except where a district explicitly requests support and authorizes it in writing.

4. How the data is used

District data is used solely to provide the Service to the district: computing sections and FTE from counts, checking rooms and contract caps, placing sections on the board, assigning teachers by credential, and exporting the plan and roster the district asked for. We do not sell data, do not advertise, do not profile, and run no analytics or tracking scripts of any kind.

5. Subprocessors

We use the following service providers. None of them receives student information, because the Service holds none.

Sign-in emails (the welcome email an invited person receives, and sign-in links) are sent by Supabase's authentication service through Resend, listed above. They contain only the recipient's email address and a sign-in link. Adding any new subprocessor is disclosed here before it is used.

6. Security

• All connections use HTTPS/TLS encryption in transit; data at rest is encrypted by our database provider.
• Row-level security isolates every site and district at the database layer, and keeps Sure Step's own founder accounts out of district schedules and rosters — these guarantees do not depend on application code being bug-free.
• Sign-in is required for all access; the public application key cannot read data without an authenticated, authorized session.
• Two people editing the same schedule are protected by a version check: a save made on top of someone else's newer save is refused and shown, never silently overwritten.
• Teacher-survey links are long random single-use tokens with an expiry; a used or expired link discloses nothing.

No system is perfectly secure, and we do not claim otherwise. We work to protect data using reasonable, industry-standard measures appropriate to its sensitivity.

7. Data retention and deletion

• Schedules and settings persist until deleted by district staff or at the end of the district's agreement, per the district's instructions.
• Uploaded files (the course master, the request-count report, a section list, a graduation policy, a bell schedule, a site map, a roster file) are read once and discarded; only the values the district chose to keep are stored.
• On termination of a district's agreement, we provide the district its data and delete records according to the schedule in the district's data-protection agreement.

8. Student privacy

The Service is operated by district and school staff; it is not directed to or used by students, and it stores no student records. Because it plans from counts, a district's FERPA obligations for education records are not engaged by this Service. Where a district chooses to sign a data-protection agreement covering all Sure Step products, this Service is included in it.

9. Changes to this policy

If we make a material change to how district data is handled — in particular, if the Service ever began to hold student-level information — we will update this page and notify districts before the change takes effect.

10. Contact

Questions about this policy or a district's data can be directed to:

Nicholas Crabtree, Sure Step Education — nick@surestepeducation.com