Studio · Lead Designer

Course Design ends with an approved topic architecture — but a topic isn't a lesson yet. The Lead Designer is Studio's course engine: it divides the course's sources across the topics, plans the lessons, designs each one to a single Lesson Page Standard, and produces every piece a learner will meet, including what they see after a check.

The 30-second version

The Lead Designer works in three moves: plan (divide the sources, set the lesson calendar, plan each topic's lessons), design (shape each lesson to the Lesson Page Standard) and produce (write and check every block, from the Storyline to the worked example). Faculty start production with one button — "Produce this lesson", "Produce this subtopic" or "Produce the course" — and watch it on the production monitor. Every block passes code checks or is repaired; publishing refuses a lesson with a required piece missing.

For engineers — where it lives

The Lead Designer is the leadDesigner module, with long-running work on Temporal: one produce-lesson workflow per lesson, and conductors for a subtopic and for the course. Every block's outcome is a persisted record whose shape is a shared contract; Studio reads it and never re-derives it. Prompts come from the prompt registry and models from the Admin Center catalogue — none are hard-coded.

Plan

Planning turns an approved topic architecture and a set of sources into a lesson-by-lesson plan, with the whole course in view.

Lesson calendar→ Divide the sources→ Read each topic→ Plan its lessons

Step	What happens
Lesson calendar	One sitting is one lesson. The course's lesson quota is sittings × days × weeks, worked out by code and pre-filled from the syllabus's weeks until faculty set it. Changing the calendar changes the plan.
Divide the sources	The AI receives every section of every source and decides which topic owns each section, and how the lesson quota is shared between topics, with a reason for each topic's weight. Faculty see this on the division table and approve it. If the model's division fails its checks twice, code builds a safe one by document order.
Read each topic	The topic's sections are read into an inventory of teaching points, each tied to the exact passage it came from.
Plan its lessons	The teaching points become the topic's lessons, each with one or two parts. Points that do not fit are recorded with their reason, never silently dropped.

Three acts keep the plan honest. Fill this gap: where a topic owns no material, the AI searches for recent, reputable open sources (at most five, and none rather than a weak one), then writes a reading with one part per allotted lesson; faculty review, edit and approve it before it is placed under that topic. Place the new sources adds sources uploaded after the division without moving any lessons. Plan again re-reads and re-plans one topic that faculty are not happy with, or whose plan failed.

The Lesson Page Standard

Every lesson is designed to one standard, in a fixed order, so a learner always knows where they are. It is phone-first: every option is a full-width row big enough to tap, and nothing depends on hover.

Open→ Parts→ Pause→ Check→ Close→ Carry forward

Moment	What the learner meets
Open	A case picture and one choice: the learner commits to a first instinct before being taught.
Parts	One or two parts. Each has Watch (a short narrated video) or Read instead, and Try it, a small activity on the idea just taught.
Pauses	Short Pause moments — before the second part and before the check — that return the lesson's card with its key line and what to be careful of.
The check	The lesson's check, which reads how the learner thinks and gives one of five results. See Mastery & the Knowledge Check.
Close	The learner's opening choice returned, a sentence that settles it, and your card — the lesson's idea to keep — with the case picture's deciding line marked.
Carry forward	What this lesson hands to the next one.

A Storyline ties each lesson together: one written record for the Open, the Pauses, the close and the case picture, so the lesson reads as one story rather than a stack of blocks. Case pictures are drawn by code, not generated as images: a document, a screen, a sign, a thing or a pair, built from the case's own words, measured to fit at phone and desktop width, and varied so neighbouring lessons never look alike.

Design before production

Each lesson is designed before it is produced: its parts, its card, its anchor case, the brief for each Try it (including the tempting errors it should surface) and the brief for its check. Production fills the design; it does not change it.

Production

Faculty start production from the Production tab: Produce this lesson, Produce this subtopic or Produce the course, each with a Stop. A course runs its topics in parallel (two at a time by default) and each topic's lessons one at a time, in order. Stopping lets the block in flight finish; nothing produced is undone.

Each lesson runs a fixed production chain of thirteen blocks:

Block	What it produces
Registration	Binds the topic's tempting errors from the misconception registry to its lessons, with their learner-facing labels.
Card headers	A short header for each line of the lesson's card, when the design has none.
Storyline	The Open, the Pauses, the close and the case picture.
Video · Read instead	Per part: the narrated video, and the reading for learners who prefer it.
Try it	Per part: the activity.
Check	The lesson's check. Every remediation block below waits until the check is produced.
Mix-up message	For each tempting error the check can catch: what the answer assumed, why it doesn't hold here, and the idea from the card that sets it right.
Second way in	The part the check tested, explained another way.
Firm-up	One example to firm up a "Nearly there".
Variant pool	Fresh versions of the check, so a learner can try again on a new question.
Worked example	A walkthrough for "Not yet" and "Not sure".
Look again	The Revision item that brings back the learner's own earlier answer. Built by code, with no model call.

Every model-written block passes code checks — plain learner wording with no engine words, length budgets, the lesson's key terms kept exactly — and is repaired when it fails. Each block records one outcome:

Outcome	Meaning
produced	Passed its checks first time.
repaired	Passed after one or two repairs; the first attempt's faults are kept so faculty can see what was fixed.
safe_version	Still faulty after the repairs. Recorded with the faults that remain and flagged for faculty; never re-run on its own.

A block can also be held with a plain reason (for example, it needs a produced check) or wait for an approved prompt. The production monitor shows the course live as it is planned, designed and produced, lesson by lesson and block by block, and can restart a run, resuming only what did not finish.

For engineers — outcomes are recorded, never thrown

A model or check fault is a recorded outcome, not an exception; only infrastructure failures throw and are retried. A retry reads the record first, so a block that already ended is never produced (or paid for) twice. A safe_version is an outcome, not an error.

Publishing & review

Faculty review every lesson in Studio exactly as the learner will see it: flip to the lesson in a phone or desktop frame, and read each remediation piece on the result it serves — Solid, Nearly there, Not yet, Not sure, A mix-up. Only produced or repaired pieces are published, and publishing refuses a lesson that is missing any required piece, so learners never meet a broken page. From there the course goes to the final report, the owner's signature and the Dean's release (see Sign & Dean release).

Tempting errors & the registry

When the Lead Designer designs a lesson it names its tempting errors: the plausible wrong ideas a learner might bring to it. These join the course's shared misconception registry, where each entry carries a staff description, how an item can tempt it, and a plain learner-facing label of no more than fifteen words. Each entry is bound to the lesson whose check scores against it.

That binding is what lets a check say which mix-up a learner made, rather than only that the answer missed — and it is what the mix-up message, the second way in and Revision build on. Entries need approval before they are used: one that passes the automatic critique is approved by policy and recorded as such; anything else waits for faculty. Mix-ups that many real learners share are surfaced back to staff in Pulse, and the registry itself is governed in Compass.