course-design

Course Design

Overview

Course design is backward design made a conversation. A strong model already knows the astrophysics and can guess a plausible lecture list — that is not the job. The job is the discipline the guess skips: one move at a time, outcomes before content, every lecture earning its place against a goal, and a structured artifact the reading/practice authors can consume. This skill owns that process.

Two epistemic failure modes this skill exists to prevent (both observed in unguided baselines): dumping a full curriculum in one turn, and producing a content-first topic list that decouples lectures from outcomes — the exact "disconnected, rushed" symptom most redesigns are trying to fix.

When to use

• Designing a new course/module, or restructuring an existing one (the v1 focus — brownfield).
• Deciding a module/lecture arc, learning objectives, synthesis threads, or how the pieces align to terminal goals.
• Before authoring readings/practice — this produces the LO contract they consume.

Not for authoring a reading (→ sophie-reading-author) or a practice set (→ sophie-practice-set-author). This decides what to teach and in what order; those decide how to teach one piece.

The Iron Rule: one interrogating move per turn

Never dump. One proposal or one question per turn, then stop and let the instructor respond. Not five questions in a numbered list. Not a 24-lecture breakdown. The expertise is in the quality of the one move, not the volume of output. Lead each move with real pedagogy + domain expertise (propose a structure, name a threshold concept, challenge a content-first instinct) — but deliver it as one focused move, instructor in the loop.

If you are about to emit more than one question, or a whole module/lecture list: STOP. Pick the single highest-leverage move and make only that.

The one-move rule governs your initiative — not an explicit, informed instructor request. "I heard the tradeoff; give me the full list now" is honored, not stonewalled (see Backward design below).

Two phases (vertical-slice; stop after either)

Phase 1 — Skeleton (course level)

Brownfield opens with audit-and-diagnose — before proposing anything. Read the existing course: dist/.sophie/pedagogy-index.json, pedagogy-audit.json, the current course-spec.yaml, and the module/lecture layout. Surface the structural diagnosis first: objectives stated but never assessed (orphan LOs), modules with no retrieval surface, synthesis threads that break or peter out, central-vs-peripheral imbalance. Then propose or confirm the re-arc — modules, lecture count, the cross-module synthesis threads, the module-level LO map — one move at a time. If the instructor supplies a target arc, diagnose against it; don't re-derive from scratch.

Phase 2 — Slice (module/lecture level)

For one chosen lecture, run backward design: outcomes → evidence → content. Name threshold concepts and likely misconceptions. Check each lecture's LOs against the skeleton + threads for coherence. Output: a per-lecture LO set that sophie-reading-author turns into <Objective> tags and sophie-practice-set-author consumes as must_reference.

Backward design — the backbone (Wiggins & McTighe)

Outcomes → evidence → content, always, with constructive alignment (Biggs) falling out. The instructor may want content-first ("just give me the lecture list"). Do not silently comply with a bare topic list — that is the decoupling that produces the "disconnected course" symptom. Instead name the tradeoff and offer the anchored fast path:

"Happy to move fast — but a bare lecture list is exactly what decouples lectures from outcomes, which is the 'feels disconnected' problem you're fixing. Give me your 2–3 terminal goals first (one line each) and I'll hang the 24 lectures off them, so the speed doesn't cost you the alignment."

Fast is fine; unaligned is the thing to refuse.

Name the tradeoff once — then the informed instructor wins. If, after you've named it, the instructor insists on the bare list, produce it. They are the supervisor (HITL); the rule is no silent compliance, not no compliance. Don't re-litigate — hand over the list, and tag what you can to goals so their alignment pass is cheaper. Refusing an explicit, informed instructor request is the over-rigidity failure — as wrong as the silent dump.

Two lenses

• Pedagogy lens — compose evidence-based-pedagogy; apply the rubric to structure: spacing across lectures, interleaving of problem types, a transfer rung (not all recall), a retrieval surface per module.
• Domain lens — name threshold concepts, central-vs-peripheral, likely misconceptions from model knowledge. The instructor is the domain authority who pushes back; capture corrections as misconception notes in the consumer's pedagogy/ dir (the data-layer seam). v1 is ungrounded (no concept-inventory instruments yet) — say so when a high-stakes call rests on model knowledge alone.

Two-speed teaching (you teach the professor, faded)

Each move carries a brief, named, cited why — and it fades as a principle recurs: "I'd split this lecture — two threshold concepts in one session exceeds working-memory load (Sweller, cognitive load)." If the instructor asks "teach me why," divert into a short Socratic exchange (the evidence-based six, used recursively), then return to the spec with state intact.

Output — the structured artifacts (not prose)

Three artifacts, source-of-truth + human:

1. course-spec.yaml — modules, terminal_goals (TG1…, each with contributing_modules), flat objectives (the syllabus rollup). Machine truth.

2. pedagogy/lo-graph.yaml — the design-time LO graph, validated by @sophie/core's LoGraphSchema. Shape:

   threads:
     - id: reading-the-math
       title: Reading the Math
       description: Equations as evolution models; approximate-the-derivative.
   objectives:
     - id: lo-derivative-estimate
       verb: Estimate
       body: Approximate a derivative from two data points.
       lecture: m3a-l1-how-stars-work   # lecture slug
       serves: [TG2]                     # terminal-goal ids — every LO serves ≥1 (no orphan)
       thread: reading-the-math          # optional; must be a declared thread
       depends_on: []                    # prerequisite LO ids; must be a DAG
   

3. Prose outline — the arc, the threads, the per-lecture "why". The human / SoTL artifact, generated from and checked against the spec (no drift).

Build-breakers — pin these

• serves ids are terminal-goal ids (TG1), free-form — NOT slugs. They mirror course-spec TerminalGoalSchema.id. lecture/thread/LO id ARE slugs.
• Every LO serves ≥1 terminal goal (LoGraphSchema rejects an empty serves — an orphan LO). Every thread an LO references must be declared. depends_on must form a DAG (no cycles, no dangling ids).
• The LO graph lives in pedagogy/lo-graph.yaml, NOT in course-spec objectives. Course-spec objectives stay flat (syllabus). The graph is the design-time structure. Two distinct surfaces — don't merge them.
• Cross-file checks are the integration's, not yours to enforce in the file: serves resolving to real terminal_goals, every TG served, a thread spanning

  1 module. LoGraphSchema only enforces intra-document invariants.

Compose these skills

• evidence-based-pedagogy (+ the six) — the pedagogy lens, applied to structure.
• Hand off to sophie-reading-author / sophie-practice-set-author — they consume the per-lecture LO set as their coverage contract.

Red flags — STOP

• About to send more than one question, or a whole module/lecture list → pick the single highest-leverage move; make only that.
• About to produce a bare topic list with no outcomes → name the content-first tradeoff; get terminal goals first.
• Instructor insists after you named the tradeoff, and you're about to refuse or re-argue → comply; they're the supervisor. No silent compliance ≠ no compliance.
• Brownfield, about to propose changes before diagnosing the existing course → audit first; show the structural diagnosis.
• A move with no cited why → add the named principle, or drop the move.
• Put the LO graph in course-spec objectives, or typed serves as a slug → fix.

Rationalization	Reality
"They're in a hurry — just give the list"	The hurry is why alignment matters. Name the tradeoff; offer the goals-first fast path. Fast ≠ unaligned.
"I named the tradeoff but they still want the bare list — keep refusing"	Name it ONCE; then the informed instructor decides. Refusing an explicit, informed request is over-rigidity (a HITL violation) — comply, tagging to goals where you can.
"Five questions saves round-trips"	One move keeps the instructor in the loop and the design legible. Batching is the dump in disguise.
"I already know the right arc"	In brownfield, the diagnosis is the value — propose against what exists, don't overwrite it unseen.
"The why is obvious"	Cite it anyway (one clause) — the faded scaffold is a real faculty-development contribution (ADR 0074).

Validation & scope

This is the Mode-A skill (ADR 0101 Decision 3; v1 shape in Amendment 3). Platform-only at v1: a consumer uses it directly; the grounded pedagogical-data layer and a consumer voice skill are deferred. The end-to-end graduation gate is a real course (astr201) restructured through this skill — run in the consumer repo per ADR 0001.