Course Builder

Course Builder — The Course Is a Contract

Outcomes promise what the learner can DO. Assessment is the proof. Modules are the build order. If the three don't line up, you have a content dump, not a course. You design them backward — outcomes first, assessment second, content last — and you emit a matrix that makes the alignment checkable.

This skill owns the skeleton: the measurable outcomes, the assessment that certifies each one, the module sequence that builds toward them, and the alignment matrix tying it all together. It does not own the teaching of any one concept.

The litmus. If the question is "what must the learner be able to DO, how do we prove it, and in what order do we build it?" → here. If it's "how do I make THIS concept click and stick?" → ../course-storytelling/SKILL.md.

Route elsewhere when: auditing a finished course for gaps, redundancy, anachronisms with a written report → ../review/SKILL.md; turning a designed module into slides/decks → ../presentations/SKILL.md (+ ../design/SKILL.md for the visual system); sales/landing copy and launch emails → ../marketing/SKILL.md (you design the learning contract, never the pitch); fact-checking or sourcing the subject matter → ../research-ops/SKILL.md (you structure what the user already knows); a repeatable internal procedure with steps but no outcomes/assessment → ../sop-builder/SKILL.md (an SOP tells someone the steps; a course changes what they can DO and proves it).

The grounding gate (read first — STOP if unmet)

You cannot design a course backward without knowing the destination. Do not write a single outcome until you have all three. Why: an outcome scoped for a senior engineer in a 90-minute workshop is wrong for a beginner in a 12-week cohort — same topic, different contract.

1. WHO — the learner and their current level (absolute beginner? practitioner? what can they already do?).
2. WHAT transformation — what must they be able to DO at the end that they cannot do now.
3. FORMAT + constraints — duration, modality (live cohort vs self-paced), group size, prerequisites, certification stakes.

If a 02-DOCS/wiki/teaching/ profile exists (the convention shared with ../course-storytelling/SKILL.md), read it first and reuse it. Otherwise interview in ONE batch — ask all three at once, do not dribble questions. Incomplete grounding = STOP and ask. Depth, the interview script, and scope right-sizing by format → references/grounding-and-scoping.md.

The build workflow (one backward pass)

Run it in order. Do not jump to modules. UbD has exactly three stages in order — desired results → acceptable evidence → learning experiences (Wiggins & McTighe, Understanding by Design). Content designed first is a dump with no destination, and "I already have these slides, build a course around them" inverts the contract: outcomes decide what content survives.

Stage 0  Grounding gate         WHO + WHAT transformation + FORMAT. Incomplete → STOP.
Stage 1  Outcomes               3–8 course-level outcomes. Measurable Bloom verb + ABCD.
                                Verb banlist enforced. Right-sized to format.
Stage 2  Assessment             For EACH outcome, the evidence that proves it.
                                Verb-match the outcome. Place formative + summative.
                                Check content validity (covers the breadth of outcomes).
Stage 3  Modules + sequence     One focus per module, prerequisite order. Each module
                                maps to >=1 outcome. No orphans, no unproven outcomes.
Stage 4  Alignment matrix       Emit outcome x module x assessment. The checkable artifact.
Stage 5  QA gate                Run scripts/verify.sh over the curriculum doc. Fix warnings
                                or justify them. Then hand modules to course-storytelling.

Stage 1 — Writing measurable outcomes

Pick the verb at the level the learner must actually operate. Recall ≠ build. The revised taxonomy (Anderson & Krathwohl, 2001) is six ascending levels of verbs, each supplying observable action verbs — a verb you can't observe, you can't assess.

Level         What the learner does          Sample verbs
Remember      recall facts                   list, define, name, label, recall
Understand    explain in own words           explain, summarize, classify, compare
Apply         use in a new situation         apply, use, implement, solve, run
Analyze       break apart, find relations    analyze, differentiate, debug, diagram
Evaluate      judge against criteria         evaluate, critique, justify, prioritize, review
Create        produce something new          design, build, compose, construct, ship

Banlist — never "understand", "know", "learn about", "appreciate", "be aware", "be familiar". They name a private mental state, not an observable behavior. Replace with what the learner does: list, explain, build, debug, evaluate, design.

Every outcome is ABCD-complete — a bare verb without a condition and a degree is not yet assessable ("write code" vs "given a failing test, write code that makes it pass"):

[Audience]   the learner
[Behavior]   <Bloom verb> + <object>
[Condition]  given <situation / tools / inputs>
[Degree]     <criterion that counts as success>

Bad → Good (the banlist verb is the tell):

Bad:  Students will understand REST APIs.
Good: Given a spec, the learner builds a REST endpoint that returns the correct
      status code for 3 named error cases (400, 404, 500).

Bad:  Learners will know SQL joins.
Good: Given two tables, the learner writes a query joining them that returns the
      expected rows for 2 of 2 test cases.

Bad:  Participants will appreciate good test design.
Good: Given a 20-line module, the learner writes 3 tests that cover the happy path
      and 2 edge cases, all passing.

Full per-level verb tables, the banlist, more worked ABCD examples, and course-level vs module-level granularity → references/outcomes-and-blooms.md.