Privacy & data · Schedule.software
We book time. Here is exactly what that means for the data we hold.
A scheduling product has a narrow appetite by construction. It needs to know when a slot is open, who is entitled to take it, and whether taking it would break a rule. Most of what a school worries about handing to a vendor, a scheduler never needs.
This page describes schedule.software and speaks for no other product. Every other product in the Stanley Studios family publishes its own policy on its own site; if a sentence about photographs or face matching would be relevant to you, you want that product’s page, not this one.
What a booking record actually holds
Five kinds of data, and that is the list.
✓Time, and who may take it
Availability windows, slots and their capacity, and the booking rows against them: who booked, for which slot, in which state (held, confirmed, cancelled). This is the substance of the product — a calendar, and the rules about who may put something on it.
✓The people a booking has to name, and no more
A booking references a person by the narrowest handle the surface can work with: a hash-verified guardian claim for a family booking, a server-resolved staff identity for a staff or substitute shift, an opaque lead reference for an admissions tour. The admissions surface owns no student census at all.
✓Resources, rooms and equipment
Rooms, gyms, fields, auditoriums and equipment, with their booking windows. The availability view is authorized-only — it is never a public room roster.
✓Crew assignments and the credential facts that gate them
For studio crew dispatch: the job, the assignment, and the credential facts the gate reads — expiry date, district match, verified flag. The gate throws before any write. These are employment facts about working adults, not student data.
✓Roster rows, when a school turns on the scheduling module
The advisory master schedule and the volunteer shift surfaces read a roster. Every identity field on a roster route passes through a consent chokepoint first: a suppressed, lapsed or do-not-publish student has their name masked and grade nulled at the server. The row still counts; only the identity is stripped.
What this product is not — said plainly, because it has been confused before
A scheduler is not a camera, a gallery, or a store.
✓No facial recognition, because there are no faces here
Schedule.software books time. Every one of its surfaces is a slot, a booking, an assignment or an availability window — not an image. Picture day is scheduled here; the photographs themselves live in the school-photography product that runs the shoot, and its policy is published on its own site, not borrowed onto this one. There is no face matching in a scheduler because there is nothing in a scheduler to match.
✓No photo store, no photo sale, no image library
This product sells nothing to a family and holds no gallery. If you arrived looking for a picture-day ordering policy, this is the wrong page and we would rather say so than hand you a page that looks like an answer.
✓No advertising profile, and scheduling data is not a product we sell
We do not build an advertising or behavioural profile from a booking, and we do not sell or rent scheduling data. There is no third-party analytics or advertising script on this site.
✓No public roster, ever
There is no open sign-up sheet to browse. A guardian’s student identifier comes from a hash-verified server-side claim, never from the request body, and a cross-family or cross-school request returns a uniform 404 — so the surface cannot be used as an oracle to enumerate a roster.
✓No automated decision about a child
The advisory master schedule proposes a timetable and explains what it could not place. A human reviews and commits; the engine never enrolls a student on its own, and prerequisite or grade-eligibility gating is not wired and is not claimed.
Minors
Minor scheduling data is consent-aware, access-controlled, and never public.
Three mechanisms carry that, and each one runs on the server where a client request cannot reach it:
The consent chokepoint. Every identity field on a roster route passes through it. A suppressed, lapsed or do-not-publish student has their name masked and their grade nulled before the route returns — stripped, not merely hidden by a user-interface filter that a crafted request could switch off. The row still counts toward capacity; only the identity goes.
The family wall. A guardian reaches their own claimed children and nothing else. The student identifier is resolved from a hash-verified server-side claim rather than accepted from the request body, and anything outside that claim returns the same uniform 404 an unknown path returns — the surface gives an enumerating client no signal to work from.
The calendar feed carries no names. The subscribable .ics feed uses opaque labels: no student name, no teacher name, and a non-PII handle rather than a real address in the ORGANIZER field. A guardian who subscribes to their own conference calendar cannot accidentally publish a list of teacher or student names into whatever calendar application they happen to use.
The volunteer and student-helper surface adds one more: an unverified volunteer cannot be assigned to a student-contact shift, and that decider is fail-closed. We do not model the per-state legal sufficiency of a background check and we do not claim to — that judgement stays with the district.
Messages, money, and automation — what is on and what is off
Three places a product like this usually overreaches. All three are off.
✓Reminders are opt-in, and today nothing is sent
A reminder is queued against the recipient’s own channel opt-in and suppressed without one. The infrastructure is in place; no comms provider is enabled, so nothing is actually delivered through this surface today. Consent can be withdrawn at any time, and withdrawing it stops the queue rather than merely hiding the message.
✓No live checkout, and no card data reaches us here
There is no checkout on this site. A booking fee is a computed line, reserved in the ledger and not charged; the payment seam exists but Stripe is not enabled. Pricing shown anywhere on this site is the planned launch tier, not a live price you can be billed at. We capture no payment card details on these pages.
✓Route optimization is arithmetic, not a model trained on you
The working-day dispatch route is solved by a deterministic heuristic running in our own process. An external optimal-solver seam is injectable but is not live and is not claimed as live. No model is trained on your scheduling data, and no third-party AI service is called from these surfaces.
✓These marketing pages set no cookie and run no client script
The page you are reading is a stateless server render. It sets no cookie, ships no client-side JavaScript, and calls no third-party analytics or advertising endpoint. That statement covers this marketing site; the product application behind a login is a separate surface with its own session, and we will not blur the two to make a nicer sentence.
Asking us about data
A person answers, and the answer is specific.
If you are a school, a district, or a family and you want to know what is held about a particular booking — or you want something corrected or removed — write to [email protected]. Say which surface it concerns (picture-day booking, conferences, admissions, master schedule, volunteer shifts, staff and substitute, crew dispatch, facilities) and we will answer about that surface rather than in generalities.
A school running Schedule.software under its own agreement is the controller of its own roster data; where the agreement and this page disagree, the agreement governs. If you are a family, your school is the right first stop — but if you would rather ask us directly, that address reaches a person.