ABA, therapy, occupational therapy and the rest compete for the same patients, the same clinicians and the same rooms. This engine schedules them as one problem — respecting credentials, school hours, room capacity and what the payer actually authorized — and tells you plainly when something is not possible.
Preview build — synthetic scheduling data, no real patient information, and access is protected by Supabase Auth and database roles.
John can reach 30 hours this week — an extra 3h across 2 appointments. No arrangement can do better.
Every figure in the product is computed by the scheduling engine — nothing on these screens is decoration.
Double-booked patient or clinician, lapsed certification, school hours, room at capacity, over the authorization, not enough time to drive between clinics. Seventeen rules, each returning a reason rather than a refusal.
Ranked openings across every eligible clinician, weighted by who the patient already sees, where they prefer to be seen, and whether the slot leaves a useless gap in the day.
“Get this patient as close to 30 hours as possible without losing therapy or OT.” It reports what is reachable, proposes the appointments, and says whether a better arrangement could exist.
Not “no solution”. Instead: only 3h of authorization remain, 3h are held by protected appointments, and there are only 8h where the patient is free and a clinician is available.
Three more clinicians adds roster hours — but only the hours that land where patients are free and authorization remains count as care delivered. The simulation reports both.
What the payer will fund and what the patient clinically needs are different numbers, held by different people. The system refuses to let one quietly become the other.
The constraint engine decides what is legal and what is best. AI is only ever an interface.
“Get John to 30 hours of ABA without moving his OT.” The assistant turns the sentence into a structured scheduling request — and shows you exactly what it understood.
Candidates are generated, every hard rule is applied, and the result is bracketed: what is reachable, and whether a better arrangement could exist.
Options are offered with their trade-offs — more hours against fewer changes. Approving locks, revalidates against live data, commits atomically and writes an audit entry.
AI never decides the schedule. It cannot invent availability, judge whether a schedule is legal, book anything, or override an authorization or a credential. Those belong to the engine, and always will.
Ask about a patient’s hours, spare capacity, or what another hire would buy you — from wherever you are, without leaving the screen you were working on. The assistant sits in the bottom-left corner of every page.
No language model is connected in this build. A fixed-phrase parser recognises the question and the engine answers it. That boundary is the architecture the specification asks for — a model, when one is added, replaces the parser and nothing else.
Seven roles, each holding the operations that genuinely belong to it. A scheduler cannot change what a patient clinically needs; the person entering authorizations cannot either. That separation is deliberate.
Books and moves appointments; runs Fill Service
17 permissions · whole practice
Owns clinical requirements; approves reductions in care
18 permissions · own caseload
Sees their own week; requests time off
6 permissions · own schedule
Owns payer authorizations and renewals
2 permissions · whole practice
Capacity, utilization and hiring simulations
8 permissions · whole practice
Service configuration, rooms and user accounts
5 permissions · whole practice
Read-only audit oversight
1 permission · whole practice
This role model is a proposal for Baker Street to confirm — the handoff specification requires role-based access but never says what the roles are.
This build runs entirely on invented data, and it says so on every screen. Five things have to be in place before that changes — listed here rather than buried, because a preview that hides its gaps gets mistaken for a finished product.
Twenty patients, twenty-one clinicians, three clinics, and one question the engine answers exactly: can this patient reach thirty hours without losing anything they need?
Explore the demo