Ask any teacher who's tried an AI lesson generator what worries them, and you'll get some version of the same answer: it's fast, but can you trust what comes out the other end? A wrong date in a history lesson, a math problem with an unsolvable answer key, a worksheet that still has "TODO: add example here" sitting in the middle of paragraph three, AI-generated content fails in specific, predictable ways, and "just generate it and hope" isn't a real strategy for anything that reaches a classroom.
We don't think the answer is a vague promise of "AI quality control." At teloriva, it's a specific pipeline, with specific checkpoints, that does specific things, and it's worth walking through exactly what it does and doesn't catch.
The trust problem with AI-generated educational content
Generative models are good at producing plausible-sounding text and structure. They are not reliably good at knowing when they've produced something wrong, a broken JSON structure the rendering system can't parse, a quiz with no correct answer among the options, a reading level three grades too advanced for the stated audience, or literal leftover scaffolding text that should never have shipped. None of these failure modes require malice or a "bad model", they're the ordinary cost of generation at scale, and the only real fix is to check for them systematically, every time, before a human ever has to notice manually.
The four-checkpoint human-approval pipeline
Every AI-generated course in the platform moves through a staged pipeline with an explicit human checkpoint at each stage: configure → structure → lesson content → lesson sections → ready → applied. This isn't a single "generate course" button that produces a fait accompli. Each of the three generation stages, structure, lesson content, and lesson sections, gets its own record that stores both the raw AI output and a human-edited version, plus an explicit approved flag with a timestamp. Nothing moves to the next stage without that approval. Nothing writes into a live, student-facing course until the final "ready" stage has been explicitly applied.
Concretely, that looks like:
- Configure, a teacher or content creator sets the topic, module/lesson/section counts (clamped to a sane 1–20 range), source material fidelity, lesson balance, quality tier, and which TTS/image providers to use.
- Structure, the AI proposes a course outline. A human reviews and approves it before anything else generates.
- Lesson content, full lesson content generates in batches, resumable via content fingerprinting so a partial failure doesn't mean starting over. A human reviews and approves.
- Lesson sections, the interactive components (quizzes, activities, media) get assembled per lesson. A human reviews and approves.
- Ready → Applied, only after all of that is a course actually written into the live, student-facing platform.
This is the part worth being explicit about: at no point does content skip a review gate because "the AI seemed confident." Every stage is a genuine checkpoint, not a rubber stamp screen you click past.
Schema validation and the one-repair-retry mechanism
Underneath the human approval gates sits a mechanical layer that catches structural problems before a person even looks at the content. Every AI generation call, course structure, lesson content, lesson sections, and, in the live classroom system, individual lesson stages and their narration, gets validated against a strict JSON Schema the moment it comes back from the model. If the AI's output doesn't match the expected shape (missing a required field, wrong data type, an interactive component that doesn't conform to its own component's schema), the system doesn't just fail silently or hand a broken object to a teacher.
Instead, it builds a targeted repair prompt describing exactly what went wrong and calls the model exactly one more time, at a lower temperature, to fix the specific problem. That's it, one repair attempt, not an open-ended retry loop hoping something eventually sticks. If the repair also fails validation, the system stops and raises a structured error rather than pretending everything is fine. In the classroom-generation system specifically, that failure surfaces to the teacher-facing Studio UI as a clean, structured error message, never a raw stack trace, never a silently broken lesson that only fails once you're standing in front of the class trying to run it.
This same schema-validate-then-repair-once pattern is used in two places independently: the Content Studio's course pipeline, and the classroom system's AI lesson-plan generators. It's not a one-off script, it's a reused mechanism because the underlying problem (LLM output not matching an expected structure) is the same problem in both places.
Soft quality checks, and what they are not
Beyond structural validation, there are two heuristic quality passes worth naming honestly:
- Reading-level banding. Generated content is scored with a Flesch-Kincaid-style readability measure and checked against the target audience tier. This catches content that's obviously mismatched to grade level, not a guarantee of pedagogically perfect phrasing, but a real, automated signal.
- Placeholder-text detection. A regex-based scan flags AI output that still contains literal stub markers like
TODO:orFIXME, the kind of leftover scaffolding a model occasionally leaves behind mid-generation. It's a blunt, mechanical check, and that's exactly why it's reliable: it doesn't need to understand the content to catch this specific failure mode.
What this validation is not: it is not deep semantic fact-checking. It does not verify that every historical date is correct, that every claim in a generated science passage is accurate, or that a word problem's numbers are pedagogically ideal. Structural validation confirms the content is shaped correctly and renderable; the heuristic checks catch specific, well-defined quality problems. The actual defense against subtler factual or pedagogical errors is the human-approval checkpoint at every stage of the pipeline described above. We think that's the honest way to describe it, a shape-and-heuristic layer that catches an enormous share of AI generation failures mechanically, paired with a human who still has to say yes before anything reaches a student.
The same pattern, reused in the live classroom system
It's worth noting this isn't a Content-Studio-only concern. The classroom Auto-Teach system generates its own AI content, full lesson plans, individual stage payloads, and narration, and it goes through the identical schema-validate-then-one-repair-retry mechanism, checked against both the overall lesson schema and each individual teacher component's own schema (since a "worked example" stage and a "class poll" stage have very different shapes). A course-generation pipeline and a live-classroom-lesson pipeline built by the same team, sharing the same validation discipline, is a small detail, but it's the kind of detail that tells you whether "AI quality control" is a marketing phrase or an actual engineering habit.
Why this matters more than "our AI is really good"
Every AI education product will tell you their model is good. Very few will tell you exactly what mechanically stops a bad generation from reaching a real classroom, and what that mechanism does and doesn't catch. We'd rather be specific: structural schema validation with one targeted repair attempt, two well-defined heuristic checks, and a genuine human-approval gate at every stage before anything goes live. That's not a promise that AI-generated content is perfect. It's a description of exactly what stands between a model's output and your students, so you can decide for yourself whether that's enough.
See the full pipeline in action in teloriva's AI Content Studio. Explore AI Content Studio →
Curious how this same discipline shows up in what the classroom system does and doesn't record from a live lesson? See Class-Level Evidence vs. Surveillance.
Meta title: Validating AI-Generated Lesson Content Before Class | teloriva Meta description: What mechanically stops bad AI generation from reaching a classroom: schema validation, one repair retry, heuristic checks, and human approval at every stage.