Case Study 03
Ontario Teacher Unit Planner
A hallucination-resistant AI lesson planning system, designed and directed without a line of code written
The Problem
Every AI lesson planning tool on the market generates Ontario curriculum expectations from general knowledge. That knowledge is wrong at the precision a teacher actually needs. Wrong expectation code, the right concept at the wrong grade, a standard from another province wearing Ontario's terminology. A teacher who catches the error mid-unit has already built two weeks of lessons on a foundation that doesn't exist.
The second problem is structural. Most AI planning tools generate one lesson at a time, with no connection between them. Lesson 1 doesn't know what Lesson 3 will cover. There's no diagnostic layer that adapts the sequence based on what students actually know coming in. The output is content delivery wearing the costume of a unit plan.
The third problem is that no available tool is built specifically for Ontario. The provincial curriculum has its own structure, its own terminology, and its own assessment frameworks grounded in the Growing Success policy document. Tools that claim provincial support typically provide it as a thin wrapper over generic content.
The System
A full-stack web application with user accounts, a curriculum database, and a two-stage planning workflow. All 3,717 Ontario Ministry of Education curriculum expectations across all 10 subjects (Grades 1 through 8, with French programs starting at Grade 4) are loaded as verified structured data. No curriculum content is ever generated by AI.
Stage 01
Unit Roadmap and Diagnostic
The teacher selects curriculum expectations from the verified Ministry database, either by browsing directly or by describing an activity and having the AI map it to matching expectations. The app also surfaces AI-generated cross-curricular suggestions based on the teacher's selection, recommending expectations from other subjects that fit naturally alongside the primary ones. The app produces a complete unit roadmap: learning goals, a lesson sequence, formative checkpoints, and a diagnostic assessment. The teacher reviews the roadmap, makes adjustments, and administers the diagnostic to their class before anything else is generated.
Stage 02A
Skeleton Review
Diagnostic results feed back into the system. The app generates compact lesson skeletons (roughly 400 to 600 tokens each) for every lesson in the unit. The teacher reviews all skeletons before any full generation begins. Lessons can be resequenced, combined, or redirected cheaply at this stage. Only when the teacher approves the outline does full expansion begin.
Stage 02B
On-Demand Expansion
Full lesson plans are generated one at a time, when the teacher opens them. Within each lesson, sections are divided into core (generated on expansion) and deferred (generated only when the teacher opens them). If a teacher never opens a deferred section, it's never generated. If a unit is abandoned mid-way, only the skeleton generation cost was incurred.
Context trimming on this stage reduced input tokens from 14,750 to 4,832 per call (67% reduction) by replacing the full Stage 1 JSON with a filtered object containing only what each lesson expansion actually needs.
The app also includes a dependency-aware revision cascade (a change to one section surfaces affected sections for teacher confirmation), a curriculum coverage tracker with four depth levels tied to the Growing Success framework, Bloom's taxonomy and Webb's DOK built into every generation prompt, teacher style and class profile as inputs, export to PDF, DOCX, and Google Docs, an asset generation framework (7 asset types, library page, and generation UX built), and an owner-only admin analytics dashboard with friction tracking across 30 mapped user journey points. Fourteen active AI workflows. Thirteen Supabase tables.
For an AI implementation role, the signal here isn't the feature list. It's the discipline that kept a 40+ module project coherent, on budget, and on spec across 46 sessions.
Key Architectural Decision
The curriculum database
Curriculum expectations are pulled from a verified structured database before any AI call happens. The AI never decides what a curriculum expectation says. It only decides how to teach toward expectations the teacher has already selected from verified data. No amount of prompt engineering produces what a database does.
Every competitor tool generates curriculum content from an AI model's general knowledge. That knowledge is imprecise at the level Ontario teachers need. Exact expectation code, exact wording from the Ministry document, the distinction between an overall expectation and a specific one, the correct strand for a given grade. The decision here was to solve the problem structurally. Not better prompts. A database.
The development meta-system
AI sessions are stateless. Each session starts blank. A complex software project accumulates far more state than any single session can hold: full product specification, all previous decisions, the current module's interface contracts, what the last session verified, what it deferred. Without a deliberate system to manage that accumulation, sessions lose coherence. Decisions get re-litigated. Bugs come from a session that didn't know a constraint established three modules earlier.
The solution was a development meta-system, designed before a single module was built. Seven components:
- 33-module plan. produced upfront by AI before a single module was built. Every module declares its start state, end state, deliverables, interface contracts, and verification steps.
- One module per session. each AI session targets one module with a clear start and end state. The session can't begin the next module until verification passes on the current one.
- Living to-do file. read at the start of every session and updated at the end. Any new module, design decision, or change is written back so the next session starts with full context.
- Log rotation. when a log file grows large enough to become expensive context, the system spawns the next numbered file. The current log plus the to-do file is sufficient to re-orient at the start of any session.
- CLAUDE.md. carries persistent session instructions that load automatically into every session. Project-level rules that no session can drift from.
- Verification steps per module. the session doesn't end until they pass.
- Cost and model audits. embedded in the workflow as a first-class concern. Four workflows were migrated from the most expensive model to Sonnet after a formal audit found no quality justification for the premium. A further downgrade to a smaller model was tested and reverted.
This protocol ran without context collapse across 40+ modules and 46 sessions. The app is a demonstration of what the methodology can produce. The meta-system is a demonstration of how to sustain complex AI-assisted work over time without losing the thread.
The So What
The work that breaks most AI-assisted software projects isn't the AI. It's session management. Context collapse, design drift, decisions re-litigated three modules later because no session had access to what an earlier one established. This project solved that problem structurally, before a single module was built. The same system that produced the app is what any complex AI implementation needs. Bounded sessions, interface contracts, a living source of truth, and cost audits embedded from the start.
The proof isn't in the feature list. It's in the logs. Three log files and a to-do document record a consistent, uninterrupted development cycle across 30+ modules. Brief the AI on the module. Plan. Execute. Verify. Log. Advance. Session after session, the same rhythm, applied to a problem complex enough that most people would assume it requires a development team.
Current State
Phases 1 through 6 are complete (40+ modules). The app works end-to-end. A real teacher can sign up, generate a unit plan, review skeletons, expand lessons, revise sections, export documents, and track curriculum coverage.
Phase 7 (IEP modifications, ESL/ELL accommodations, report card comments) has not started. Phase 8 asset generation has its infrastructure in place: 7 asset type schemas, a library page, and the generation UX are built. Individual asset generators (exit tickets, worksheets, quizzes, tests) are next. Deployment to a public URL is the next step before Phase 7.
Without writing a line of code, he designed and directed the development of a full-stack AI-powered web application. Verified curriculum database, multi-phase adaptive planning workflow, dependency-aware revision system, coverage tracker, export pipeline, and admin analytics dashboard. The same modular session protocol ran consistently across 40+ modules and 46 sessions. It maintained zero context collapse throughout and produced a working demo a real teacher can use today.