Optimization.software Reserve early access

Optimization.software · The school-operations optimization layer · 2026

You already have a schedule, a sub list, and a bus roster. Make them fit.

Building next term’s master schedule by hand means discovering a room double-booking after the fact. Finding a substitute for tomorrow means a calling tree with no credential check. Assigning a bus route means a paper sheet nobody can query. Optimization.software runs the same three jobs as deterministic, seeded solves you can re-run and audit: a conflict-minimized master schedule, a credential-gated ranked substitute list, and a bus assignment that owns its own data even with no routing vendor under it.

Nothing here is a black box. Every solve is structure-only and seed-reproducible — the same input and the same seed produce the same output, every time, which is what makes it something an operations director can actually audit instead of trust blindly.

Reserve early access The four engines
4real, wired optimization engines — master schedule, substitute coverage, transport assignment, staff scheduling
0engines that write or enroll on their own — every one is propose/review/commit or a human-triggered assignment
0substitute notifications actually sent today — broadcast and assignment notify are both honest-off (queued_not_sent / sent:false)
3routing-vendor credentials the transport gate checks for (Tyler Versatrans, Edulog, Transfinder) — none configured is the honest default

What is built, as a proportion — not a bare number

The honest fractions behind the four numbers above.

Why optimization.software exists

The booking product and the optimization product are different jobs.

Schedule.software answers “how does a family or a staff member book a slot on a calendar we own.” That is a different job from “how does the district build the master schedule itself, fill an absence with a qualified sub, and keep the bus assignment straight” — which is the operations-leader job this product answers. Where the two overlap on the same real engine (the master-schedule solver; the HR-capability gate that also protects staff scheduling), we reuse the engine, never re-implement it a second time under a different name.

Four engines, each traced below to the actual apps/api route or domain module it runs on — not a marketing verb invented for this page.

The master schedule — a deterministic, seeded, structure-only solve

Hand the engine every course section for a term — period, room, teacher, seat capacity — and it returns a conflict-minimized timetable proposal plus an explainable list of what it could not place and why. The same seed over the same sections reproduces the same placement every time: this is a deterministic structural solve, not a black box, and re-running it is how you audit it. It reasons over period clash, room double-booking, and teacher double-booking — structure only. It does not read a transcript: prerequisite and grade-eligibility gating is not wired, and this page does not claim it is. The build is advisory end to end — propose, review, commit. Nothing is written or enrolled by the solve itself; a human reviews the proposal and the unplaced report before anything touches a real roster. A what-if surface takes the same term, layers a drop/add tweak on top, re-solves, and diffs the result against the committed schedule — so you can model “what happens if we add a fourth section of Algebra I” before you commit to it, on the same engine, not a separate simulation.

Built · module-dark (advisory only; structure-only; no eligibility gating)

POST /v1/schools/:schoolId/scheduling/auto-schedule · /what-if

Substitute coverage — credential-gated, ranked, and honestly not-yet-sent

An absence is approved, and the coverage engine builds the eligible-candidate set from active staff credentials only — an expired credential never reaches the matcher, so the returned list is never an unqualified list. The eligible set is ranked by a seed keyed to the absence itself: deterministic and auditable, not a live queue that reorders itself between two people looking at it. A finder route can automate the search end to end and broadcast to the ranked list — and today, with no real notification channel wired in, every entry in that broadcast is reported queued_not_sent. We do not say a substitute was texted or called when nothing was texted or called. Assignment re-asserts the credential gate at the moment of commit: a substitute who is not in the eligible set the server just computed cannot be assigned, full stop, even if a client tries to force it — the check runs again on the write, not only on the read. The substitute's own notification of the assignment is the same honest story: recorded, sent:false, until a real channel is provisioned. Every one of these three routes is gated behind a server-resolved HR capability, not a client-supplied role claim — a front-office rep view is hard-denied; only staff-admin or sub-coordinator identities, resolved on the server, can reach the eligible set at all.

Built · ranking & gating live; broadcast/notify honest-off (not sent)

POST /v1/schools/:schoolId/absences/:absenceId/match · /find · /assign

Bus & route assignment — the data is ours; the live map is partner-gated

The assignment — which student rides which route, on which stop, on which bus, with which duty flags, plus the parent-request inbox that changes it — is data we own outright. A school runs the bus list, the boarding sheet, and the request inbox with zero routing-partner integration; that layer is fully functional on its own. What we do not build ourselves is the route OPTIMIZATION underneath a live map: turn-by-turn geometry, stop sequencing, an ETA per stop, or a live GPS position. That is a routing-vendor capability (the Tyler Versatrans / Edulog / Transfinder class of system), and we gate it, cleanly, on whether a district has actually provisioned that vendor's credential. No credential configured – the honest default – and the gate reports partner_not_configured: the assignment stands, and no route geometry, ETA, or bus position is fetched or invented. Credential configured, and the same gate flips to configured and the live overlays turn on for that route. There is no third state where we quietly fake one of these three things to look finished; a district without a routing vendor sees the honest gap, not a placeholder map. A student's transport duty basis (McKinney-Vento, foster care) is tracked on the same assignment record and, where the basis requires it, routes through a counsel-gated review before a transition is applied — the assignment engine does not let a status change past that gate on its own.

Built · assignment data owned & functional; live geometry/ETA/GPS honest-off without a partner key

transport-assignment.ts · transport-routing-partner.ts (routingPartnerGate)

Staff scheduling — HR-capability gated, server-resolved identity

Staff and substitute scheduling sits behind the same HR-capability gate as the coverage engine above: the scheduling identity used to decide who can see or touch a shift is resolved from the server-side context, never trusted from a client-supplied claim. The gate runs on the server on every call, not as a feature flag a request can disable by omitting a header. This surface is staff-coupled and never reads the student census: it has no path into a roster of students, only staff and the absences/assignments tied to them.

Built · module-dark (HR-gated; staff-coupled; never touches the student census)

staffSchedulingGate · sub-scheduling-access.ts

How a district actually starts using this

Five concrete steps, not a demo script.

  1. Connect the roster you already have. Course sections, staff, credentials, and transport assignments come from the school's existing data — nothing here asks a district to re-enter a census.
  2. Enable the module. Master schedule and substitute coverage are module-dark by default; a school turns on sis_scheduling (and the HR-scheduling capability for the coverage/staff surfaces) when it is ready, not before.
  3. Run the solve, seeded. Auto-schedule takes an optional seed; the same seed over the same sections gives the same proposal, so a registrar can re-run it and compare rather than wonder if the engine changed its mind.
  4. Review the unplaced report, not just the placed one. Every section the solve could not place comes with a reason (period clash, full room, teacher conflict) — the honest half of the output, not hidden behind the happy path.
  5. Commit manually. Nothing above writes a real schedule, assigns a real substitute, or fetches a real bus position by itself. A person reviews and commits, every time — that is the propose/review/commit shape every engine on this page follows.

What “optimization” means on this page, specifically

Deterministic and seeded — not “AI,” not a live optimal solver.

Say what these engines actually are, so the word “optimization” in the domain name never implies more than what runs: a heuristic structural solve for the master schedule (period/room/teacher conflict minimization, nothing about eligibility), and a seed-keyed deterministic ranking for substitute candidates. Neither is a machine-learning model, neither claims mathematical optimality, and neither runs unsupervised — every one produces a proposal a person reviews.

The seed is the audit trail: give the same input and the same seed back to either engine and you get the same output. That reproducibility is the actual guarantee — not a claim that the answer is provably the best possible one.

How this compares to running it by hand

Six real jobs, honestly scored — including the ones we mark partial.

Manual operations vs. optimization.software
JobWithout thisWith optimization.software
Building next term's scheduleA registrar hand-places sections in a spreadsheet, discovers a room clash after the factSeeded solve proposes a conflict-minimized timetable and names every unplaced section with a reason
Modeling a change before committingRe-build the whole schedule by hand to see what one added section breaksWhat-if re-solves the same term with the tweak and diffs it against what's committed
Finding a substitute for tomorrowA calling tree, or a shared spreadsheet of names with no credential checkCredential-gated eligible set, ranked deterministically; broadcast is queued, not sent through a real channel today
Assigning a substitute so it can't be wrongWhoever answers the phone first, credential unchecked at the moment of assignmentThe credential gate is re-asserted on the write, not only on the read; an unqualified assignment is hard-denied
Bus route data, day to dayA paper route sheet and a separate spreadsheet of duty flags and parent requestsOne assignment record: student, route, stop, bus, duty flags, and the parent-request inbox, owned outright
Live bus position / ETA on a mapNo routing vendor integrated — nothing on a mapOff by default (partner_not_configured), honestly reported; turns on the moment a routing-vendor credential is provisioned

Room-by-room, not averaged

The honest status of every named engine.

Each line below names ONE engine and ONE status — never a rolled-up “the platform is X% done” number, because that number would hide which specific piece is module-dark, which piece is honest-off, and which piece writes nothing on its own.

  • Master schedule build: Built · module-dark (advisory only; structure-only; no eligibility gating) — POST /v1/schools/:schoolId/scheduling/auto-schedule · /what-if
  • Substitute coverage: Built · ranking & gating live; broadcast/notify honest-off (not sent) — POST /v1/schools/:schoolId/absences/:absenceId/match · /find · /assign
  • Transport assignment: Built · assignment data owned & functional; live geometry/ETA/GPS honest-off without a partner key — transport-assignment.ts · transport-routing-partner.ts (routingPartnerGate)
  • Staff & substitute scheduling: Built · module-dark (HR-gated; staff-coupled; never touches the student census) — staffSchedulingGate · sub-scheduling-access.ts

Money, honestly

No live checkout. No card charged today.

There is no cart, no card field, no live price anywhere on optimization.software. Reserving early access is a conversation — mailto:[email protected] — not a live checkout. Nothing here is billed until we turn a real, disclosed price on.

Who this is for

Registrars, HR schedulers, and transportation directors — not the front office.

  • Registrars / scheduling admins get a re-runnable master-schedule proposal and a what-if surface to model a change before committing to it.
  • HR / sub-coordinators get a credential-gated, ranked substitute list and an assignment path that cannot be forced around the credential check.
  • Transportation directors get one owned assignment record for every student/route/stop/bus pairing, with an honest, named path to live routing once a vendor credential is provisioned — not a promise that a map will simply appear.
  • Front-office / rep-level staff are explicitly hard-denied from the coverage and staff-scheduling routes — this is an operations-leadership tool, not a front-desk one, and the server enforces that, not a UI convention.

What this page does not claim

Said plainly, in one place.

  • The master-schedule solve does not know a prerequisite or a grade-eligibility rule. It reasons over period/room/teacher structure only.
  • No solve on this page enrolls a student, assigns a substitute, or commits a bus assignment on its own — every one stops at a proposal a person reviews.
  • No substitute is texted, emailed, or called through this surface today. The broadcast and assignment-notify steps are honest-off (queued_not_sent / sent:false).
  • No route geometry, ETA, or live bus position is fetched or shown without a provisioned routing-vendor credential. Without one, the honest status is partner_not_configured.
  • No AI, no machine-learning model, and no claim of mathematical optimality — every solve is a deterministic, seeded heuristic.
  • No live checkout, no price charged today, no adoption metrics, no named customers.

FAQ

Common questions.

Is this “AI”?

No. Every solve on this page is a deterministic, seeded heuristic: structure-only conflict minimization for the master schedule, seed-keyed ranking for substitute candidates. Re-run the same seed over the same input and you get the same output. There is no model making a judgment call and no claim of an “optimal AI solver, live” anywhere on this site.

Does the master schedule enroll students automatically?

No. It is advisory only: propose a conflict-minimized timetable, review it, and commit manually. The solve itself never writes a roster and never enrolls anyone.

Does the schedule solve know about prerequisites or grade eligibility?

No, and we do not claim it does. It reasons over period, room, and teacher structure only. There is no transcript feed wired into this engine.

If a substitute is found, are they actually texted or called?

Not today. The finder's broadcast to the ranked list and the assignment's notification to the chosen substitute are both recorded honest-off — queued_not_sent and sent:false. A real notification channel is future work, and this page does not claim it exists yet.

Can an unqualified substitute get assigned by accident?

The credential-gated eligible set drops expired credentials before matching ever runs, and the same gate is re-checked at the moment of assignment — a substitute not in the server's current eligible set cannot be assigned, even if a client tries to force it.

We don't have a routing-vendor contract. Does the transport piece still work?

Yes, for the data layer: the assignment (student, route, stop, bus, duty flags, parent requests) is ours and fully functional with zero partner integration. What is off is the live overlay — route geometry, turn sequencing, ETA, and live GPS position — which requires a Tyler Versatrans, Edulog, or Transfinder credential. Without one, the gate reports partner_not_configured, honestly, rather than showing a fake map.

Who can see or change a staff schedule?

Access is resolved server-side from a real HR capability, not from anything a client request claims about itself. A front-office rep-level view is hard-denied from the coverage and staff-scheduling routes.

Does this touch student data?

The master-schedule solve touches section structure (period/room/teacher/seat counts), not student identity directly; roster-facing output is consent-aware and strips a suppressed student's name at the route. Substitute coverage and staff scheduling are staff-coupled and do not read the student census at all.

What does it cost, and can we buy it today?

Nothing is charged through this page. There is no cart, no card field, no live price anywhere on optimization.software. Reserving early access is a conversation (mailto:[email protected]), not a checkout.

How is this different from schedule.software?

Schedule.software is the booking front door — the calendar substrate families and staff use to book a slot (picture day, conferences, admissions, rooms, field dispatch). Optimization.software is the layer that fills in the moving parts once a school already has a schedule to optimize: building the master schedule itself, filling an absence, and assigning a bus route. Different job, same underlying deterministic engines where they overlap (the master-schedule solver and the staff/substitute gates), never re-implemented twice.

Reserve early access.

Tell us which engine your district needs first — master schedule, substitute coverage, or transport assignment — and whether a routing-vendor credential is already provisioned. No card, no price charged today.

[email protected]