Blueprint design
Blueprints are the planning contract between the outline pipeline and later content generation steps. They must be explicit enough for an isolated downstream author to generate the right content without reading neighboring sections, but they must stay at the correct abstraction level for the current stage.
Why this exists
Fraya uses blueprints in multiple stages:
- topic blueprints in the outline plan;
- section blueprints in outline design and refinement;
- section-stage generation prompts that turn a blueprint into a concrete asset.
Without a shared rule set, prompts tend to drift in two harmful directions:
- under-specified blueprints that omit scope boundaries, factual anchors, or the narrative character's situation, forcing downstream generators to guess;
- over-specified blueprints that jump ahead into downstream implementation detail such as final scripts, page-level layouts, exercise templates, or item-writing details that belong to a later production step.
Core rule
A blueprint must pre-define the pedagogically necessary variables for the current stage.
This means the blueprint should lock down the instructional contract:
- what the learner should understand, practice, or produce;
- what content is in scope and what is explicitly out of scope;
- which factual anchors, scenario facts, or labels are necessary to preserve meaning;
- what validation model applies when the section is an assessment.
This does not mean the blueprint should prescribe downstream implementation detail that belongs to later stages.
What section blueprints should include
For section blueprints in the outline pipeline, make sure the blueprint is self-contained for an independent author and explicitly states:
- the section's instructional purpose and scope boundaries;
- the concept, framework, or case focus for this section only;
- any pedagogically essential factual anchors:
- a specific statistic and source when the section depends on that exact claim;
- exact fictional facts when the learning point depends on those scenario facts;
- exact labels or parts when a diagram or framework would be ambiguous without them;
- the narrative character's situation when the section uses the course narrative;
- the expected learner action for an assessment and how correctness or interpretation should be judged at a high level.
What section blueprints should not include
At the outline stage, do not prescribe downstream implementation details such as:
- final shot lists, camera directions, or slide-by-slide timing for videos;
- final page composition or screen-layout instructions when they are not required to preserve the concept itself;
- final question stems, answer-option sets, distractor banks, or scoring paths;
- UI controls, interaction widgets, or concrete game mechanics for interactive sections;
- template names or mechanic families.
Assessments at outline stage
Assessment blueprints should define the pedagogical contract, not the finished assessment payload.
Question-based assessments
Specify:
- what knowledge, distinction, or reasoning should be checked;
- whether the task is reflection, recall, interpretation, application, critique, or creation;
- whether the answer is correct/incorrect, criteria-based, or interpretation-based.
Do not specify the final item bank, full answer options, distractors, or wording of each prompt unless a later stage explicitly requires it.
Artifact assessments
Specify:
- assessment type;
- cognitive action;
- content scope;
- validation intent.
Do not specify the final interaction mechanic, template, or game structure. Those are chosen later in the artifact-specific production step.
Related files
prompts/injections/blueprint_instructions.yamlprompts/course_structure/flow_course_structure_design.yamlprompts/course_structure/flow_course_structure_refine.yamldocs/structure/outline_pipeline.mddocs/artifact/artifacts.md