MTSYes

• 

  MTSYes Landing Page

• 

  Insights Page

Inspiration

Every school runs some form of multi-tiered systems of support (MTSS), the general-education process for helping a struggling student before anyone talks about a special-education referral. I have spent years on the district side of that process, and the same thing happens everywhere. The model is sound on paper and then falls apart in practice.

Most software for this makes it worse. It surfaces a wall of data, demands heavy training, and still cannot answer the one question a team has when reviewing interventions: did the plan we wrote down actually happen, and did it help? Teams end up documenting to look compliant instead of documenting to help a student. I built MTSYes to fix that, and to let a team show they supported the student before the referral, not just claim they did.

What it does

MTSYes connects the whole intervention loop in one inspectable workspace:

• A district operations overview: current work, data health, and delivery at a glance.
• A deterministic signal queue that flags students by explicit, configurable rules (a threshold crossed, a data source changed, evidence missing). Every status change is logged to an append-only audit trail, so nothing is a black box.
• Persistent student records that keep strengths, evidence, signals, and intervention history connected instead of scattered across tools.
• An intervention cycle board with target, strategy, provider, baseline, goal, schedule, review date, and decision rule, plus fast session logging that rolls up delivered minutes and fidelity automatically.
• Aggregate views on implementation, evidence quality, and recurring targets, each carrying its own methodology and causal guardrails.

MTSYes keeps the educator in the loop. It does not diagnose, determine eligibility or placement, assign tiers, or prescribe treatment. Rules surface records for review, the model organizes bounded evidence and drafts inspectable artifacts, and a team of educators approves every plan and records every decision. Every record in the demo is synthetic. No real student data was used.

How I built it

I built MTSYes during OpenAI Build Week with Codex and GPT-5.6. I reasoned out the MTSS model and the human-decision boundary in ChatGPT first, then had Codex implement it, refining pass by pass.

The stack:

• App Router UI running on the OpenAI Sites runtime.
• Drizzle schema and Cloudflare D1 migrations for durable, structured records.
• A bounded workspace API that the UI reads and writes through.
• Firebase auth, with a demo role switcher for reviewers.
• A deterministic calculation layer that keeps the signal and cycle math out of the model entirely.

That last part is the point: the numbers a team acts on are computed, not guessed. Delivered dosage and fidelity roll up from logged sessions,

$$\text{dosage} = \frac{\text{delivered minutes}}{\text{planned minutes}}, \qquad \text{fidelity} = \frac{#{\text{sessions delivered as designed}}}{#{\text{sessions delivered}}}$$

and a signal fires only when an explicit rule is met, for example when a metric $m_t$ stays below a configured threshold $\tau$ across $k$ consecutive checks:

$$m_t < \tau \quad \text{for all } t \in {T-k+1, \dots, T}.$$

The workflow with Codex was director and implementer: Codex generated, I reviewed for taste and correctness, and sent it back until it was right. The single biggest speedup was learning that when a written prompt produced a weak layout, handing Codex an image to reference got the result I wanted far faster than a slew of words.

Challenges I ran into

• Encoding the human-decision boundary in software. It is easy to say "AI doesn't make the decision." It is harder to build so that the deterministic layer, the bounded AI drafting, and the educator's approval stay cleanly separated and auditable at every step.
• Keeping signals explainable. Every flag has to trace back to a rule and a data change, not a model's opinion, which meant an append-only audit event for every consequential change.
• Coherent synthetic data. To demo realistically with zero FERPA risk, I needed a believable district: multiple schools, students, rules, evidence, and cycles that hang together. Generating a synthetic world that feels real is its own problem. What I ended with was a microscopic version; enough to demo without getting into the weeds with creating dummy data.
• Scope in a short window. Connecting the full loop end to end (signals, records, cycles, session logs, aggregates) in the Build Week window meant being intentional about what needs to be ready and cutting everything else.

Accomplishments that I'm proud of

• The whole loop works end to end in one inspectable workspace, deployed live on OpenAI Sites.
• The human-decision boundary held. The system surfaces and organizes, the educator makes decisions, and every state change is auditable.
• The signal and cycle math is deterministic, so teams can trust and inspect the numbers they act on.
• I shipped a coherent, fully-synthetic district with no real student data, which is the only responsible way to build a demo in this space.

What I learned

• A director-and-implementer loop with Codex is fast. Reason out the model and the boundaries first, then implement. And when a layout is weak, give the model a concrete visual reference instead of more text.
• The technical: App Router on the Sites runtime, Drizzle and D1, and how to design a deterministic calculation layer that keeps AI bounded rather than load-bearing.
• The current challenge in EdTech: districts buy for compliance and reporting, site staff adopt for time saved, and they are different people. A tool only works if it serves both. "Actionable" is not more dashboards. It is being able to show that the tool saves time and produces results.

What's next for MTSYes

• Real-data integrations with SIS, IEP, and assessment systems, so signals fire on live district data under proper privacy controls.
• Pilots with real teams, with FERPA-safe handling from day one.
• A richer intervention library and deeper aggregate and causal-guardrail views.
• Role-based flows for coordinators, teachers, and administrators, plus a live meeting mode for running the actual SST meeting inside the tool.

Built With

• 5.6
• codex
• sol