The Infinite Textbook: Inside the Content Engine v0

Every personalized learning path is a promise the platform has to keep. Point a learner at "become a data engineer" or "get better at negotiation," and the path planner lays down a sequence of skills to master. But a sequence of skill names is not a course. Someone - or something - has to actually teach each one: write the chapter, draw the diagram, set the flashcards, mark the quiz. And it has to do that for a skill it may never have seen before, at the right difficulty, tuned to the person reading it.

No team of human authors can keep that promise at the speed and breadth a personalized path demands. So the content engine does. Give it a skill, a format, and a difficulty band, and it produces a complete, structured, source-grounded, quality-checked piece of teaching material - on demand, and then remembers it so the next learner never waits.

That's the whole idea. The interesting part is everything the engine does to make sure what it produces is good, true, safe, personal, and affordable - because a machine that writes lessons at scale is only useful if you can trust every one of them.

Four ways to learn one skill

The engine doesn't just generate walls of text. Each skill can be rendered in whichever format teaches it best - and the learner can summon more practice on demand. Every format is objectives-first: it states what you should be able to do, then everything downstream (a wrong quiz answer, a shaky flashcard) maps back to a specific objective, which is exactly the granularity the platform's adaptation loop needs.

Alongside the chapter sits a contextual tutor - a chat grounded in exactly what you're reading. The inline "ask" prompts in a lesson flow through it, and their answers are now saved and reused like any other content, so a good answer is written once and served instantly forever after.

One request, seven moves

When a learner opens a step, the platform calls a single function - get_or_generate - and everything below happens behind it, without ever blocking the reader. The order matters, because most of the engine's cleverness is about not generating when it doesn't have to.

1. Reuse before you write. Look for an existing rendering that already passed quality checks and isn't stale. If one exists, serve it instantly. Generation is the expensive step, so the fastest lesson is the one you don't regenerate.
2. Take a number. On a miss, grab a short-lived lock for this skill so two simultaneous requests - a learner opening the step while a prefetch warms it - can't both generate the same thing, or both crown a canonical version.
3. Gather real sources. For a chapter, search the open web, have the model shortlist the genuinely useful results, and fetch each URL to confirm it's live. Only reachable pages survive, and their text becomes grounding. This research is gathered once per skill and shared across every learner.
4. Write it. Hand the model a format-specific brief and a strict output schema, and it returns structured content. The engine then pins the routing fields, replaces any model-recalled links with the verified ones, and drops visuals it can't stand behind.
5. Put it through the gate. Nothing reaches a learner un-inspected. A layered evaluator checks structure, re-solves quiz keys, and asks a strict model-judge about grounding, teaching quality, and safety. It is fail-closed: silence or error means "don't ship."
6. Write it down for good. A passing version is saved as an immutable record with its full lineage - model, prompt version, cost, tokens, the graph it was built against - and only then does it become the canonical version the path serves.
7. If the gate says no, try once more. A failed draft regenerates a single time - usually dropping the web references, since off-topic links are the most common reason a draft fails. Beyond that, the learner keeps a manual "retry" control rather than the engine looping forever.

Underneath all of it, a per-learner budget guard watches spend. If a learner hits their daily cap, the loop never hard-fails - it serves whatever good content already exists, or returns a gentle "still preparing," and moves on.

Where the facts come from

A model asked to write about a skill from memory will happily invent a citation. The engine refuses to let it. Before a chapter is written, a research pass searches the web, lets the model curate the best hits (favoring official docs and short, focused videos over marketing pages), and then fetches every chosen URL to prove it exists. Unreachable links are silently dropped - never faked. The verified pages' text is fed to the writer as grounding, and the lesson's reference list is set from that same vetted set, so the model can lean on real sources but can't smuggle in URLs of its own.

The same discipline governs pictures. An original diagram - Mermaid the engine authored from the sources, like the one above - is kept as its own artwork. An outside image survives only if it links back to a source the engine actually fetched, so the platform never surfaces an illustration it can't credit.

Written for one learner, from day zero

Most content platforms author a generic lesson and personalize the wrapper around it. This engine inverts that. There is no generic base lesson waiting to be adapted - when it can, the engine generates the rendering directly from the skill plus a compact picture of who's asking.

That picture - the learner's context - is assembled from their own signals and becomes an instruction to the writer: draw examples from the domain of their goal, build on what they already know, add scaffolding where they're shaky - and never announce that it's doing so.

The elegant part is how it stays affordable. Personalization threatens reuse - if every rendering is unique, nothing is ever shared and cost explodes. So the engine separates the expensive, universal part from the cheap, personal part. The research substrate - the verified sources about a skill - is the same for everyone, gathered once and reused. Only the final rendering is personal, and even those are bucketed into coarse "context clusters" so learners on the same footing can still share a lesson. Personal where it counts; shared where it can be.

Nothing ships unless it's good

Quality isn't a review someone does later; it's a gate every version must pass to serve at all. The evaluator runs cheap deterministic checks first, then a model-judge for the things only judgment can catch - and it fails closed, so an error or a timeout is treated as a failure, never waved through.

A hard failure quarantines the version. A soft failure - or an unavailable judge - routes it to a human review queue instead of the learner, where a reviewer can approve or reject. Every version lands in one of three states, and the verdict, the judge model, and the exact rubric version are all recorded so the decision is reproducible:

• `passed` → serves to learners
• `needs_review` → held for a human
• `failed` → quarantined, never served

That answer-key re-solve is worth dwelling on: it catches the mislabeled "correct" answer - a classic and dangerous failure mode where a generated quiz confidently marks the wrong option right. The engine simply re-solves each item itself and refuses to trust a key it disagrees with.

Every lesson leaves a paper trail

Because content is generated, it has to be governable. The engine treats each skill/format/difficulty as a stable logical unit, under which every rendering is an immutable, append-only version - nothing is edited in place. Identical regenerations dedupe by content hash and quietly no-op. A version that never passed the gate is kept anyway, for analysis, but is never served.

On top of that, the whole lifecycle emits a typed event stream - content_generation_requested, content_resources_gathered, content_generated, content_eval_passed, content_eval_failed, content_activated, content_reused, content_budget_blocked - so the engine's behavior is a thing you can watch, not guess at.

The north star

An infinite, personal curriculum: for any skill in any domain, a lesson written and checked in the moment, tuned to the learner in front of it - as good as a great tutor's custom-made material, at close to zero marginal cost through reuse. So a learning path is never blocked waiting for a human to write the next chapter.

v0 is the foundation. It proves the loop - generate, ground, gate, personalize, remember - end to end, and it does so domain-agnostically: the subject may be engineering, design, law, cooking, or music, and the engine never assumes the learner is an engineer.

What it can't do yet

A v0 that oversells itself is worse than one that names its edges. Here's where the current engine stops - the known gaps that map the road from "it works" to "it's world-class."

None of these are surprises; they're the plan. v0's job was to make the loop real, safe, and observable - and that part is done.