Guide

Getting your source material ready

Almost everything that makes a generated course good or bad is decided before generation runs. Here is what actually moves the needle.

8 min read · Updated September 2026

The rule that matters most

A grounded generator can only be as correct as the documents behind it. It will not invent a policy you forgot to include, and it will not quietly correct one that is out of date — it will faithfully teach your team the wrong thing, with a citation proving you told it to.

So the single highest-value hour you can spend is not on the brief. It is on deciding which documents are actually current.

What to include

Include the things a well-briefed colleague would hand a new hire: the handbook, the runbook, the policy doc, the page in the wiki everyone links to. Prefer documents that were written to be read by a person over ones generated for a system.

  • Handbooks and policy documents, even long ones — length is not a problem, staleness is
  • Process runbooks and checklists, which produce the most directly testable lessons
  • The wiki pages people actually link to in chat, rather than the ones that merely exist
  • Meeting notes or transcripts where a decision was made and never written up properly elsewhere

What to leave out

Every document you add becomes something the Author can cite, which means a bad document is not neutral — it is a liability with a footnote.

  • Anything superseded. If two documents disagree, the Verifier will flag the contradiction, but it cannot know which one is current
  • Aspirational drafts. A process document describing how you wish things worked will be taught as how things work
  • Slide decks that are mostly images. There is little text to cite, and what there is tends to be fragmentary
  • Personal data you do not need in the course. If a document is only relevant because of one paragraph, paste that paragraph instead

Formatting barely matters, structure does

You do not need to clean up formatting, fix typos, or convert anything. The Ingestor handles messy PDFs and half-finished Markdown without complaint.

What does help is structure the parser can see: real headings rather than bold text pretending to be headings, lists that are lists, and tables that are tables. A document with a clear hierarchy produces sharper chunks, and sharper chunks produce citations that point at a paragraph instead of a page.

How much is enough

There is no minimum, but there is a floor below which you should not expect a course. A single two-page memo contains a lesson, not a curriculum, and the Architect will say so rather than padding it out to look substantial.

As a rough guide: one solid handbook chapter produces a module. A full handbook produces a course. A memo produces a lesson you should probably just send as an email.

Write the brief as an outcome

The brief is not a summary of the documents — the crew has already read those. It is the thing the documents cannot tell it: what someone should be able to do afterwards.

"Cover the refund policy" produces a tour of a document. "A new support hire should be able to handle a refund request end to end without asking anyone" produces a course, because now there is a test for whether each lesson earns its place.

Plan for the second version

Sources are immutable once ingested, which is what lets the Curator diff them later. When your handbook changes, you add the new version rather than editing the old one, and CourseSaga shows you exactly which lessons were built on the part that moved.

This works much better if your documents live somewhere with a stable address. A page in the wiki will be re-checkable forever; a PDF that somebody emailed you in March will not.

Next

Writing learning objectives that hold up

Once the material is right, the objectives decide the shape of everything downstream.

Read the guide