LIGHT HOPE · Scheduling authority service
A session is covered only when someone says yes.
m633 is the coverage-truth layer for a learning center’s shared calendar. It turns Google Calendar into an honest answer to one question: which sessions this week are actually covered — and which only look covered?
Built for Mathnasium of Lexington · scheduling backbone of the RUDO / LIGHT HOPE ecosystem.
The failure mode it exists to kill
“我以为周三周四有人 — I assumed Wednesday and Thursday were covered.”
— the sentence every center director has said once too often
Shared calendars record intentions, not commitments. A name typed next to a session tells you someone was pencilled in — it does not tell you they agreed to show up. The gap between the two is where no-coverage days come from.
m633 draws that line in code. An imported student – session – instructor pairing enters as PROPOSED, never CONFIRMED. Coverage reports it as awaiting confirmation, not covered — until the instructor explicitly accepts.
How it works
Four moves, one direction of authority. The engine reads the messy world, but only explicit confirmations flow back out.
Import, fail-closed
Center Google Calendars and ICS feeds are parsed by a config-driven classifier. Anything ambiguous does not guess — it fails closed into a human review queue.
GCAL / ICS → DEMANDPropose, don’t rank
Eligible instructors are matched on availability, location and modality — and returned unranked. The admin decides. The engine never auto-assigns (by design, Phase 1).
NO AI RANKINGConfirm, explicitly
Only an instructor’s explicit acceptance moves an assignment to CONFIRMED. Every transition lands in an append-only ledger the database itself refuses to rewrite.
APPEND-ONLY LEDGERReport & project
Coverage is derived, never stored. Confirmed sessions project one-way onto a coverage calendar and personal .ics feeds — proposals are never projected as fact.
ONE-WAY EXPORTAssignment lifecycle — only one state counts
Only CONFIRMED counts as covered. Everything else — including a proposal that looks perfectly plausible on the calendar — is reported as a gap that still needs a human yes.
Five invariants, enforced twice
Each rule is enforced in the in-memory engine and mirrored in Postgres — triggers, partial unique indexes, and views that assert the same truths.
Single source of truth
The assignment record is authoritative. Google event ids and iCal UIDs are projection keys, never authority. Export is strictly one-way.
Append-only ledger
Assignment history is never updated or deleted. A database trigger rejects mutation; in memory, rows are frozen with a single append path.
Fail-closed coverage
Coverage is derived, never stored. Only a CONFIRMED assignment counts, and at most one live assignment may exist per slot.
No AI ranking
Candidate sets come back unordered by merit. The admin decides; the engine never auto-assigns. Judgment stays human in Phase 1.
Modality always resolved
Every demand, availability and assignment resolves to a concrete location and modality — or fails closed into review. No silent defaults.
Receipts, not claims
Every number below is read from the repository’s own test suite and docs — nothing here is a marketing estimate.
99 green tests
The full vitest suite passes with nothing running — no database, no network. Four Postgres round-trip tests run opt-in against a live DB.
15 / 15 real titles parsed
Every real calendar title from the center’s 2026-06-23/24 week parses correctly — plus garbage inputs that must fail closed.
Depth-8 state flood-fill
A BFS traversal of every reachable assignment-state sequence up to depth 8, asserting all five invariants at every node.
300 -config oracle check
Eligibility matching is verified exhaustively against an independent brute-force oracle across 300 generated configurations.
Who it’s for
Center directors
See the real gaps
A daily rollup of which sessions are confirmed, which are merely proposed, and which are unfilled — so staffing decisions happen before the day arrives, not during it.
Instructors
Your yes is the record
A personal .ics feed of exactly what you have confirmed — nothing pencilled-in on your behalf. Accepting or declining is an explicit, logged act.
Operators & builders
A backbone, not an app
Inside the LIGHT HOPE ecosystem, m633 is the scheduling authority other services (RUDO) build on: a pure, deterministic core behind one clean calendar seam.
Access & deployment
m633 runs today as operational infrastructure for one real center — Mathnasium of Lexington — under LIGHT HOPE LLC. It is not a self-serve product, and this page will not pretend otherwise.
If you run a learning center that lives and dies by a shared calendar and you want coverage you can trust, the engine, its schema, and its test suite are the conversation starter. Deployment means: your calendars, a service account, and the same fail-closed rules.
This tool supports scheduling operations for education businesses; it is an operations tool, not educational or professional advice.
Get in touch
Interested in the coverage-truth approach?
Reach the LIGHT HOPE team through the x1000.ai ecosystem. There is no public pricing — engagements are scoped per center, and we would rather say so than print an invented number.
LIGHT HOPE ecosystem →Pricing: by conversation only — no published tiers yet. Anything you see quoted elsewhere for m633 is not from us.