A bank's compliance team needs the anti-money-laundering refresh rebuilt before a regulator visit, and the old version took six weeks. The new lead opens the build differently. Before a single word is generated, she loads the approved policy PDF, the two-page SOP, and the compliance officer's signed memo into the workspace, and she writes one instruction the model will obey on every screen: every claim cites the source line it came from, or the model refuses to write it. Four days later the module ships. When the regulator asks where the 10,000 dollar reporting threshold came from, she does not reach for the tool. She points at policy section 4.2, the exact line, traced from the first draft. That trace is the subject of this lesson, and it is Stage 1 of the pipeline this whole chapter builds.

Why Stage One Decides the Whole Build

This chapter assembles a single artifact end to end: the source-to-certified-course pipeline, the workflow that turns a verified source of truth into a complete, accessible, measured course in days instead of weeks, with a record a compliance officer, an accessibility auditor, and a CFO all accept. There are four stages. This lesson is Stage 1, and Stage 1 is the foundation every later stage stands on. Get it wrong and nothing downstream can be saved: an item bank validated against a fabricated fact is still wrong, an accessible video narrating an invented threshold is still a liability, and a sign-off log that signs off on ungrounded claims is a record of negligence, not diligence. Provenance has to be wired in at the first draft or it can never be retrofitted honestly.

Two terms anchor everything that follows, and both deserve a plain definition before we build. A source of truth is the human-approved material a claim is allowed to come from: the current policy, the signed SOP, the SME interview transcript, the product spec, the regulation as your legal team interprets it. Why you care: in a regulated course, a fact is not "true" because it is correct in the abstract; it is usable because it traces to a document your organization stands behind. Provenance is the record of where a claim came from, the chain from the sentence on screen 18 back to the line in the policy it was drawn from. Why you care: provenance is the difference between "we believe this is right" and "here is exactly where this came from and who approved it," and only the second sentence survives an audit.

The mistake that ruins most AI builds is treating provenance as a documentation task you do at the end, a citation pass after the content is written. By then it is too late. The model has already blended approved facts with training-data facts into fluent prose, and you cannot reliably tell which sentence came from your policy and which the model invented to make the paragraph flow. The only honest way to have provenance at the end is to demand it at the beginning, before the first sentence is generated.

You cannot bolt provenance onto a finished draft. Either every claim was grounded when it was written, or you are guessing which sentences to trust, and a guess is not an audit trail.

Grounded Generation Versus the Open Model

The technical heart of Stage 1 is the difference between an open model and a grounded one. An open model answers from its training data, the vast statistical memory it built from the public internet and books. Ask it for your AML reporting threshold and it will produce a number, fluently and confidently, drawn from the thousands of compliance documents it has seen. That number might be 10,000 dollars. It might be 5,000. It might be a figure from a different country's regulation entirely. The model has no way to tell you which, because it is not reading your policy; it is predicting plausible text. This is the failure mode called hallucination: fluent, confident output that is simply false, and in a compliance module a hallucinated threshold is not a typo, it is a wrong instruction shipped to everyone who takes the course.

Grounded generation, often called RAG (retrieval-augmented generation), changes the model's job. Instead of answering from memory, the model is forced to answer from a specific set of documents you provide: it retrieves the relevant passage from your policy, and it writes from that passage. Why you care: when the model is grounded, "where did the 10,000 dollar figure come from" has a real answer, a line in a real document, instead of a shrug dressed up as a number. Grounding does not make the model perfect; it can still retrieve the wrong passage or paraphrase a grounded fact into a subtle error. But it changes the question from "is this fact anywhere in the universe" to "does this fact match the line it claims to cite," and the second question is one a human can actually check in seconds.

The Three Ways to Ground a Build

You do not need an engineering team to ground a build. There are three practical approaches, in rising order of setup effort, and a learning professional can use all three without writing code.

The first is in-context grounding: you paste or attach the approved source directly into the conversation and instruct the model to draft only from it. This is the everyday workhorse. For a single module built from one policy and one SOP, attaching those two documents and writing "draft only from the attached sources, cite the section for every claim, and refuse to state any fact not present in them" is enough to ground the entire build. It costs nothing and works in any modern assistant.

The second is a retrieval system over a knowledge base: your policies, SOPs, and SME content are indexed, and the model pulls the relevant passages automatically for each request. This is what you reach for when the source material is too large to paste, when many courses draw from the same library, or when the content updates often enough that you want one maintained source rather than copies scattered across conversations. It is more setup, but it scales the same discipline across a function.

The third is a hybrid: retrieval finds the candidate passages, and you confirm the right ones before generation runs. This is the safest pattern for high-stakes regulated content, because a human verifies that the model is grounded on the correct, current source before a single claim is written. The choice among the three is a risk decision, not a technical one: the higher the stakes, the more you want a human confirming the source before the draft, not after. A microlearning nudge about a low-risk soft skill can be drafted with in-context grounding and a light check. A safety procedure a technician will follow at a live panel warrants the hybrid approach, because the cost of grounding on the wrong source is measured in injuries, not embarrassment. Match the rigor of the grounding to the consequence of being wrong, and do not let the convenience of in-context grounding tempt you into using it for content where a wrong claim ships harm.

Wiring the Source into the Build

Grounding is not just attaching a file. A source dumped into a model without discipline produces a draft that looks grounded and is not. Wiring the source in properly means four concrete moves, and each one is a control you can describe to an auditor.

Confirm the source is current and approved. The most common quiet failure in Stage 1 is grounding on the wrong version. The model will faithfully draft from last year's policy if that is what you gave it, and the draft will be confidently, traceably wrong. Before anything generates, confirm the date and the approval status of every source: this is the current policy, signed on this date, by this owner. A grounded build on a stale source is worse than an ungrounded one, because the wrongness comes wrapped in a citation that makes it look verified.

Instruct the model to cite or refuse. The single most important instruction in the whole stage is the refusal rule: for every claim, name the source and the section it came from, and if a fact is not present in the provided sources, do not write it, flag the gap instead. Why you care: without the refusal rule, the model fills gaps in your source material with training-data facts to keep the prose smooth, and those invented facts are exactly the ones that ship as regulated claims. The refusal rule turns a gap in your sources from a silent fabrication into a visible flag you can resolve.

Capture provenance as a structured field, not a footnote. Have the model emit, alongside each content block, the source and line it traces to. A storyboard row that reads "Screen 18: verify zero energy before applying lock | Source: SOP section 3.4, step 5" carries its own provenance. When this is structured from the first draft, the sign-off log in Stage 4 is something you assemble from existing fields, not a forensic reconstruction you attempt under deadline.

Separate the grounded claim from the generated scaffolding. Not every sentence in a module is a load-bearing claim. The narration that says "Let's look at how this applies on the floor" is scaffolding; it needs no source. The sentence that states the reporting threshold is a load-bearing claim; it needs a source and a human check. Part of wiring the source in is teaching the model, and yourself, to mark which is which, so verification effort lands on the claims that can hurt you and not on the connective tissue that cannot.

A Worked Example: The AML Refresh

Return to the anti-money-laundering refresh and watch two builds of the same module, the slow ungrounded one and the fast grounded one, side by side.

Before, the ungrounded sprint. Under deadline, the team pastes a rough outline into an AI assistant and asks it to "write a complete AML training module for frontline staff." In ninety seconds it returns twenty polished screens. Screen 6 states that suspicious activity reports must be filed for transactions over 5,000 dollars. The real threshold in the bank's policy is 10,000 dollars, and the model produced 5,000 from a different jurisdiction's rule it had seen in training. Nobody catches it, because the prose reads like authority and the deadline is real. The module ships. Sixty days later an internal audit pulls the course, finds the wrong threshold, and asks the question that has no good answer: where did this number come from and who approved it. The team cannot say, because the number never traced to anything. The remediation, pulling the course, correcting it, re-certifying every employee who took it, costs more than the six weeks the AI was supposed to save.

After, the grounded build. The same team starts Stage 1 properly. They confirm the current AML policy, signed three weeks ago, and the frontline SOP. They attach both and instruct the model: draft only from these sources, cite the policy section for every regulatory claim, and refuse to state any threshold, deadline, or obligation not present in the sources, flagging it as a gap instead. The model drafts twenty screens. For the reporting threshold it writes 10,000 dollars and tags it "Source: AML Policy section 4.2." On one screen about cross-border transfers, the model stops and flags: "The provided sources do not specify a threshold for cross-border reporting; this claim cannot be grounded." That flag is gold. It means the model did not invent a number to fill the gap; it surfaced a real hole in the source material, which the team takes to the compliance officer, who supplies the missing rule and the section it lives in. The draft that emerges is not only faster, it is auditable from the first version. Every regulatory claim already carries the line it came from. When the regulator later asks about the 10,000 dollar figure, the answer is one sentence and one document.

The two builds used the same tool and the same model. The difference was entirely in Stage 1: whether the source of truth was wired in before generation or hoped for after it. The ungrounded sprint was faster for ninety seconds and catastrophically slower across the lifecycle. The grounded build was the genuine four-days-instead-of-six-weeks win, because it was fast and defensible, which is the only kind of fast that counts in a regulated course.

An ungrounded draft is not a head start. It is a debt that comes due at the audit, with interest measured in re-certified employees.

What Grounding Does Not Do

Grounding is powerful, and it is not a substitute for human verification. This distinction matters, because a team that over-trusts grounding ships a new failure mode dressed as diligence. Three honest limits keep Stage 1 from becoming a false comfort.

First, a grounded model can still retrieve the wrong passage. If your knowledge base contains both the current policy and a superseded draft, the model might pull from the wrong one, and the citation will look perfectly legitimate while pointing at a dead source. The citation tells you where the model says the claim came from; a human still confirms that source is the right one. Second, a grounded model can paraphrase a correct source into a subtle error. The policy says "within five business days" and the draft says "within five days," dropping "business," which changes the deadline. The claim is grounded and still wrong, because grounding governs where the fact comes from, not whether the paraphrase preserved it exactly. Third, grounding does not validate that the source itself is correct. If the SOP you grounded on contains an error, the course faithfully reproduces it. Grounding moves the question from "did the model invent this" to "is the source right and did the draft preserve it," which is a far better question, but it is still a human's question to answer.

So the iron rule of the program lands precisely on Stage 1: AI assists, the human verifies, the human owns the decision, and "the AI wrote it" is never a defense. Grounding makes verification fast and possible by giving every claim a source to check against. It does not perform the verification. The learning professional still reads each load-bearing claim against the line it cites, confirms the source is current, and owns the decision that the claim is correct before it moves to the next stage. Stage 1 does not remove the human; it gives the human a fighting chance to do the job at AI speed instead of drowning in unsourced prose.

Key Takeaways

• Stage 1 of the source-to-certified-course pipeline wires the approved material into the build so every claim carries provenance from the first draft; get this wrong and no later stage can be saved.
• A source of truth is the human-approved material a claim is allowed to come from; provenance is the traceable chain from the sentence on screen back to the source line it was drawn from.
• Provenance cannot be bolted onto a finished draft honestly; demand it at the first generation or spend the audit guessing which sentences to trust.
• An open model answers from training-data memory and hallucinates confident wrong facts; grounded generation (RAG) forces the model to answer from your documents, turning "is this true anywhere" into the checkable "does this match the line it cites."
• Wire the source in with four moves: confirm it is current and approved, instruct cite-or-refuse, capture provenance as a structured field, and separate load-bearing claims from scaffolding.
• The cite-or-refuse rule converts a gap in your sources from a silent fabrication into a visible flag, which is exactly how the AML build surfaced a missing cross-border rule instead of inventing one.
• Grounding does not verify: a model can retrieve a stale passage, paraphrase a correct source into a subtle error, or faithfully reproduce a wrong source, so a human still checks each claim against its line.
• The iron rule lands on Stage 1: grounding makes verification fast and possible, but the human still verifies, owns the decision, and answers for it, because "the AI wrote it" is never a defense.