Course Design Standards

Quality rules for the structural design of a course outline. Applied in the content planning stage (Steps 3, 4b, 5) and used to audit and refine the outline before section-level content generation.

Terminology: "course" vs "training"

Inside the system, the learning material produced by this design is called a course. All internal identifiers, schema fields, prompt variables, and workflow names use course (e.g. course_title, course_outline, course_consistency). This is the stable, code-level name and should not be renamed in the data model or pipeline.

For the end user — the learner — this same material is surfaced as a training. All learner-facing text (trainer bios, intros, outcomes, video scripts, UI copy) refers to it as a training, not a course.

This document describes the design that currently produces trainings. Other designs may be introduced later that produce different learning materials (e.g. guided paths, microlearning sequences, assessments). When that happens, the internal "course" abstraction may stay the same while the learner-facing label differs per design.

Course architecture

Structure defaults

Module 1, Topic 1 — fixed

"Welcome to the training" is always Topic 1.1 and contains exactly two sections:

The normal course flow begins at Topic 1.2, with section 1.2.1 being What_to_expect.

Module bookends

The course flow uses structural anchors — not as separate topics, but as sections inside the topic flow:

• Open: What_to_expect (always video format)
• Close of every non-last module: Key_takeaways
• Final course close only: Learning_Outcomes followed by Reference_List

Topic-closing anchors

Except for the fixed "Welcome to the training" topic at 1.1, every topic must end with the correct structural closing section:

• Any non-final topic inside a module: Whats_Next
• Final topic of a non-last module: Key_takeaways
• Final topic of the whole course: Learning_Outcomes, then Reference_List

Whats_Next and Key_takeaways are mutually exclusive within a topic. The final topic of the whole course must not end with Key_takeaways; it uses the course-ending pair Learning_Outcomes + Reference_List instead. Whats_Next is text-only and must never use a video format.

Fragmentation rule

Never create a module or topic without a clear learning outcome and pedagogical sense. Attach "hanging" sections to the previous topic. Combine similar ideas into one section. Use 7 sections only when the topic genuinely needs the extra split for clarity, pacing, or pedagogy. Treat 8 or more sections as a rare exception that needs a strong instructional reason.

Concept handling

• Introduce concepts as early in the course as possible.
• Use only officially established frameworks and concepts with their generally accepted names.
• Do not introduce pseudo-frameworks, relabeled versions of known concepts, or other unauthorized labels just to make the course sound unique. If a concept or framework is valid, name it by its official widely recognized term.
• If a concept is covered only partially, explicitly tell the learner what is omitted and why, and where they can learn the rest.

  Example: covering 3 of Cialdini's 7 principles → include a brief overview of all 7 and explain why only 3 are in scope.

• Always enrich core concepts with: origin (who, when, why), supporting research, known limitations.
• Maintain consistency across the full course: concepts mentioned early must be present in later examples and summaries.
• Use logical connectors ("what's next") between topics to signal transitions. In the outline, this is implemented through Whats_Next as the final section of each non-final topic except the fixed welcome topic.

Content balance

• Distribute cognitive load evenly within each module.
• Mix interactive sections with knowledge delivery — do not cluster all assessments at the end.
• Avoid text-heavy sections. Always pair explanations with images or video.
• Treat pure Text as a limited fallback, not the default explanatory format.
• Use pure Text mainly for structural or supporting sections such as Whats_Next, Key_takeaways, or Reference_List, and only in rare cases for teaching material when richer image/video formats are not a better fit.
• Whats_Next is the explicit text-only exception: always keep it in a pure text format and never plan it as video.
• Do not plan more than 2 pure Text sections within one topic.
• For explanatory sections, prefer TextWithPhoto, TextWithIllustration, TextWithPortrait, TextWithDiagram, VideoPresentation, or VideoTalkingHead when those formats fit the material.
• Avoid repeating the same section type within a topic.
• Do not add interactivity to non-interactive sections.

Narrative character

The entire course is built around one main narrative character whose story threads through all examples and cases. Supporting characters may appear but are never the primary lens. All blueprints must specify the character's situation explicitly so independent section authors can maintain consistency.

Video and assessment quotas

Course ending

The last topic must contain:

1. Learning_Outcomes — reflecting the stated Learning Objectives
2. Reference_List — list of sources or further materials

Learning_Outcomes is always a video section.

Platform constraints

Permanent technical limitations that affect content planning:

Assessment format guide

Selecting the wrong format for an assessment breaks the learning intent. Match format to both Bloom's level and the type of assessment.

Self-assessments

Self-assessments measure reflection, not correctness. The learner interprets their own experience, preference, or readiness.

❌ Never use ChoiceQuestions for self-assessments. ❌ Never use exact categorization, matching, ordering, or corrective-feedback Artifacts for self-assessments.

• If the learner must place items into the correct conceptual bucket, it is a knowledge assessment.

Knowledge assessments by Bloom's level

General assessment principles

• All assessments must be equally relevant, appropriately challenging, and clearly worded.
• Avoid ambiguous or double-meaning tasks. Each question must have one clear intent and outcome.
• Match format to both Bloom's level and the learning context — consider what action you want the learner to take, not just what level they are at.
• Keep Artifact blueprints pedagogical at the outline stage: specify what should be checked and how, but leave concrete template selection to the later artifact-design step.
• At the outline stage, define learner action and validation intent, not screen behavior or UI mechanics such as drag-and-drop, sliders, buckets, or template names.

Related

• Outline pipeline — design rules applied in Steps 3, 4b, and 5
• Section types — full list of available types and their placement rules
• Section formats — format constraints and usage rules
• Naming conventions — title and naming rules applied throughout the outline