Automated Content Generation

An automated content generator is fit for teaching use when every item it returns cites the syllabus topic and the difficulty you named. It does not invent learning objectives. If the source module is missing, the output stays empty. You still own what gets published to students.

Start with two inputs that already exist: the module or unit on the syllabus, and one learning objective that already belongs to that module. If you cannot name both, do not generate. A request such as "intermediate, Week 6, sampling distributions" is usable. A request such as "something that would help them" is not.

A knowledge graph from syllabus can hold the allowed topic list and difficulty labels. Treat those labels as constraints. The model should not add a third objective, raise or lower difficulty on its own, or fill a gap by writing content for a week you did not attach.

When the module identifier is blank, or the notes for that week are not in the prompt, empty output is the correct quality signal. A fluent paragraph that cannot cite the module is a failed item, even if a student would find it readable.

Ask for three product types only, at the difficulty you set: worked examples, practice problems, and alternative explanations of the same idea. Do not ask the same run to write a lecture, a rubric, and a midterm. Those are different jobs.

A worked example should show the steps the notes already teach, in the same order, using quantities that appear in the module. A practice problem should be solvable with those steps and those quantities. An alternative explanation should restate the same objective in different wording or a different representation. It should not introduce a new objective, a new formula, or a shortcut the notes have not reached.

An instructor teaching introductory statistics opens the Week 6 module "Sampling distributions." The syllabus already lists the objective: construct a sampling distribution of the sample mean for a stated population and sample size. They request intermediate difficulty: one worked example, three practice problems, and one alternative explanation for students who confuse the sampling distribution with the population distribution. The lecture notes use only the population mean, the population standard deviation, and the sample size. They have not yet introduced a normal-table shortcut; that sits in Week 7.

The generator must stay inside Week 6. If a practice item quietly uses that Week 7 shortcut, the item is wrong even if the arithmetic is clean. The instructor discards that item. The remaining items still have to name Week 6 and intermediate difficulty in their metadata so a later reviewer can see what was asked for.

This is generation on instructor demand, not a live tutor. An intelligent tutoring system can later reuse the same worked example as a scaffold during practice. An adaptive learning path engine can later decide which students see which explanation. Neither system should create new objectives while it routes content.

Quality here is citation and restraint, not volume. Each generated item should name the module, the objective ID or the verbatim objective text from the syllabus, and the difficulty label you requested. If any of those three cannot be bound to source material, return nothing for that item.

Do not invent a formula that is not in the notes. That failure is easy to miss on a skim. A model trained on a wider statistics corpus will insert a continuity correction, a z-procedure, or a software command the module never taught. Those insertions look like help. Students then practice a method the course has not authorized.

Do not invent a learning objective to justify a clever item. If the syllabus does not already say students should compare two sampling distributions, the generator does not get to add that comparison because it would make a nicer problem set. Write a worse problem that matches the objective, or write nothing.

Empty output is also the right response when you attached the wrong week, when the notes failed to load, or when the objective string does not match any objective on the module. Retry with the correct source. Do not accept a best-effort draft that guesses.

Take the module and the objective. Generate the examples, problems, and explanations at the stated difficulty. You review them. Only then does anything move into the LMS.

Review is not a courtesy pass. Read each item against the notes. Check that every quantity, term, and method appears in the module. Check that the difficulty label still fits after generation: an introductory item that requires a Week 7 method is mislabeled. Check that the alternative explanation does not smuggle a second objective. Discard or edit anything that fails.

Publishing unreviewed items is the failure mode that turns a drafting tool into a course-integrity problem. A plausible wrong formula, a loaded context, or a problem the notes cannot solve will reach students as soon as you paste the batch into a module and publish. Campus LMS products such as Canvas, Blackboard, Moodle, and Anthology treat that paste like any other instructor file. They will not know the items were model-generated. They will not run your pedagogical checks. Treat the LMS as a distribution channel, not a reviewer.

After you accept an item, you can attach formative feedback generation so a student who misses a practice problem gets a comment tied to the same objective. That feedback still needs the same source binding. It should not introduce methods the module does not contain.

Treat generated practice as practice. Do not drop the same batch into a graded exam, a high-stakes quiz, or an item bank you will sample for the midterm without a separate assessment workflow.

Practice items exist so students can rehearse the objective at a known difficulty. Exams exist to measure it under controlled conditions, with item security, coverage rules, and often a different review chain. Mixing the two produces two problems. Students who completed the practice set have already seen the stems. Items that were never reviewed for exam quality, including ambiguity, multiple keys, and clueing, get scored as if they were. If you need generated items for a test, use a dedicated adaptive assessment generation process, with exam-level review, and keep those stems out of the published practice folder.

The same boundary applies in reverse. Do not use the generator as a silent author of the course. You remain the publisher. The model drafts. You accept, edit, or reject. Students should meet materials you would sign, not a feed of whatever the last prompt produced.

When the pipeline is working, you can request a new difficulty on the same module, get a new set that still cites that module, and still throw away anything that does not. That loop is the point: generation on instructor demand, items bound to the source, empty output when the source is missing, and faculty ownership of the publish step.