A safety incident gets investigated, and the investigator does the one thing every learning professional dreads: she pulls the training record. The module taught a confined-space entry procedure, and one step was wrong. She does not ask whether AI was involved. She asks a colder question: "Show me the chain. Who wrote this step, who checked it, who approved it to go live, and where is that recorded." In a well-designed workflow there is an answer for every link: a draft from the AI, a verification by a named SME against the SOP, a sign-off with a date. In a badly designed one there is a shrug and a sentence that ends careers: "It came out of the tool, and I think someone looked at it." This lesson is about building the chain so that the answer is never a shrug.

A Handoff Is a Boundary Where Accountability Changes Hands

The previous lesson gave you the map: which steps are AI-ready, which are human-in-the-loop, and which are human-only gates. This lesson zooms into the seams between those steps, because that is where things actually go wrong. A handoff is the moment a piece of work passes from one party to another, from the AI to the designer, from the designer to the SME, from the SME back to the designer, and at every handoff accountability changes hands. The danger is that accountability can slip through the cracks at a handoff: the AI "did" the step, the designer assumed the SME would catch errors, the SME assumed the designer had already verified the facts, and a wrong claim sails through because everyone believed someone else owned it.

The cure is to make every handoff explicit. Explicit means three things are written down and not assumed: what is being handed off, who is now accountable for it, and what they must do before it can move forward. An SME, the subject-matter expert, is the person who owns the truth of a regulated or technical claim, the safety engineer who knows the real lockout procedure, the compliance lawyer who knows the real threshold, the clinician who knows the real protocol. When the AI drafts a claim in the SME's domain, the claim is not "done" until it crosses the boundary to that SME and back, with the crossing recorded. A handoff that is implicit, where the work just appears in someone's queue with no statement of what they own, is where the chain breaks.

Work does not fail at the steps. It fails at the seams between them, where each party quietly assumes someone else owns the verification. A handoff you did not design is a handoff where accountability falls through the floor.

The Four Handoffs in a Grounded Build

A typical AI-assisted module has four handoffs that matter, and naming them turns a vague "we collaborate with AI and the SME" into a designed pipeline. Walk them in order.

Handoff One: AI to Designer

The AI produces a grounded draft and hands it to the designer. The thing being handed off is a draft, not a fact, and the designer's first job is to remember that. What the designer owns at this boundary is triage: separating the claims that are load-bearing and regulated from the prose that is merely connective tissue. She marks every sentence that asserts a threshold, a procedure, a legal requirement, a dosage, or any fact a learner will act on, because those are the sentences that have to cross the next boundary to a SME. The failure mode here is treating the fluent draft as finished and skipping the triage, which leaves regulated claims hiding inside ordinary-looking paragraphs.

Handoff Two: Designer to SME

The designer hands the flagged claims to the SME. This is the most important handoff in the whole build, and the most commonly botched. The mistake is handing the SME the entire forty-screen module and saying "can you review this," which buries the three claims that matter under thirty-seven screens of prose the SME will skim. The disciplined handoff hands the SME a short, specific list: here are the eleven claims in your domain, here is the source each one was drafted from, please confirm each against the approved source or correct it. The SME is not proofreading a course. The SME is verifying a finite set of claims against a source of truth, which is a job a busy expert can actually do well in the time they have.

Handoff Three: SME to Designer

The SME hands the verified claims back, with corrections and an approval. The designer's job at this boundary is to fold the corrections in faithfully and, critically, to not let the AI "improve" the wording afterward in a way that re-breaks the verified claim. A verified claim is now frozen language; if it gets regenerated, paraphrased, or "tightened" by the AI after the SME signed it, the verification no longer applies to what actually ships. This is a subtle and common failure: the SME approves version A, the designer runs one more AI polish pass for tone, and version B ships with a quietly altered threshold the SME never saw. The boundary discipline is that approved claims are locked.

Handoff Four: Designer to the Record

The final handoff is to the record itself: the sign-off log. The designer records, for each regulated claim, the source it traces to, the SME who verified it, and the date. This is the handoff that makes the previous three defensible, because a verification that happened but was never recorded is, to an auditor, a verification that did not happen. The record is not bureaucracy; it is the artifact that answers the investigator's question before she has to ask it twice.

RACI for Learning AI: Who Is Responsible, Accountable, Consulted, Informed

To design handoffs precisely, borrow a tool from project management called RACI, which assigns four roles to every task: Responsible (the party that does the work), Accountable (the single named person who answers for the outcome and signs off, of which there is exactly one per task), Consulted (parties whose input is required), and Informed (parties kept in the loop). The single most clarifying move in learning-AI design is to fill out a RACI and to refuse to ever list the AI in the Accountable column. The AI can be Responsible, it does the drafting, but it can never be Accountable, because Accountable means a person who answers to the auditor, and AI does not answer to anyone. The whole iron rule of the program is just a RACI constraint: AI may be Responsible, a human is always Accountable.

Here is a RACI for the core steps of a grounded compliance build. Read the Accountable column down the page and notice it is always a named human role, never the AI.

WCAG 2.2 AA, named in the table, is the Web Content Accessibility Guidelines at the AA conformance level, the accessibility standard learning content is held to. Notice that the AI appears only in the Responsible column and only on drafting tasks; it never once appears as Accountable. That single rule, AI is never Accountable, is the spine of every defensible learning-AI workflow. When someone proposes a process where "the AI approves the content" or "the tool signs off," they have put AI in the Accountable column, and that workflow is not defensible to anyone who later reads the record.

Logging the Crossing: The Claim Never Crosses Unsigned

The principle that ties the handoffs together is simple to state and easy to violate: a claim never crosses from draft to published without a named human approving it, and the crossing is logged. "Crossing from draft to published" is the boundary that matters, because draft is where AI lives and published is where learners live, and the gap between them is exactly one human sign-off. Logged means there is a durable record of who approved what, against which source, on which date.

The log entry for a single regulated claim is small but complete. It names the claim, the source line it traces to, the SME who verified it, the date and time, and ideally a version identifier so you can prove the approved version is the one that shipped. A useful test of a log entry: could an investigator who has never met your team reconstruct, from this entry alone, that a competent human verified this exact claim against an approved source before a learner saw it? If yes, the entry is sufficient. If it requires someone to remember a conversation or trust a vague "it was reviewed," the entry is theater, not evidence.

Why insist on logging the crossing rather than just trusting good people to do good work? Because the question always comes later, after the incident, after the SME has moved teams, after the designer has forgotten which version was final, and at that moment human memory is worthless and the log is everything. The log is how a verification that happened in March survives to be proven in November. It converts a private act of diligence into a public, durable fact, and a learning record is a public, durable thing by nature.

A Worked Example: Before and After

A pharmaceutical company is rebuilding its good-manufacturing-practice training, and one module covers a cleaning-validation procedure with specific time and temperature thresholds. Watch the handoffs in two versions.

Before (the handoffs left implicit). The designer prompts the AI to draft the module from the SOP, gets a clean draft, and emails the whole thing to the SME, a process engineer, with the note "can you take a look when you get a chance." The engineer is slammed, skims the forty screens, replies "looks good overall," and moves on. The designer takes "looks good overall" as approval, runs one final AI pass to tighten the prose for readability, and ships. In that final polish pass, the AI rephrased a sentence and changed a hold time from "minimum 30 minutes" to "approximately 30 minutes," a small wording shift with a real regulatory difference. Nobody noticed, because the SME approved a version that no longer existed by the time it shipped, and nothing was logged that would have caught the change. Eight months later an auditor flags the softened threshold, asks for the verification record, and finds an email that says "looks good overall" attached to a different version of the text. The chain is broken at every seam.

After (the handoffs designed). The designer takes the AI draft and triages it, flagging the four claims that carry regulatory weight, including the 30-minute hold time. She hands the engineer a one-page list: four claims, the SOP line each was drafted from, and a single ask, confirm or correct each against the SOP. The engineer, now facing four specific claims instead of forty screens, verifies them carefully in fifteen minutes, corrects one unrelated value, and confirms the hold time is exactly "minimum 30 minutes." The designer folds in the correction and locks the four verified claims as frozen language. She runs no further AI passes over the locked sentences; the readability polish is restricted to the connective prose only. Each verified claim goes into the sign-off log with the SOP line, the engineer's name, and the date. When the auditor arrives eight months later and asks for the cleaning-validation verification, the designer pulls one log entry: the claim, the SOP reference, the engineer who signed it on the verified version, and the date. The hold time on the shipped module is the verified one, because the verified version is the one that shipped, because the handoffs were designed so that no claim crossed to published without a logged human approval.

Same AI, same SME, same module. The difference is entirely in the seams: in the before, the handoffs were assumptions, and the chain broke silently; in the after, the handoffs were explicit, the AI never appeared as Accountable, and the crossing was logged. The auditor's question had a one-entry answer instead of a career-ending shrug.

Designing Handoffs That Do Not Rot

A handoff design only helps if the team actually follows it under deadline pressure, so the last job is to make the right handoff the easy handoff. Three principles keep a handoff design alive. First, make the SME's job small and specific: hand them a finite list of flagged claims with sources, never an entire module, because a SME asked to verify four claims will do it well and a SME asked to "review the course" will skim. The quality of your verification is mostly determined by how well you scoped the SME's handoff. Second, lock what is approved: build the habit that once a claim is signed, its language is frozen and no AI pass touches it, so a polish step can never silently re-break a verified fact. Third, log at the moment of crossing, not at the end of the project, because a log written from memory a week later is reconstruction, and reconstruction is exactly what the discipline exists to avoid.

The reward for this work is not bureaucratic comfort; it is speed with a spine. A team with designed handoffs can move fast precisely because it knows where the boundaries are and trusts that nothing crosses them unsigned. The undesigned team is either slow, because everyone re-checks everything in a fog of shared anxiety, or reckless, because nobody checks anything and the chain breaks in the dark. The designed handoff is how you get the AI's speed and the auditor's confidence at the same time, which is the entire promise of an AI-integrated learning function.

Key Takeaways

• Work does not fail at the steps; it fails at the seams between them, where each party assumes someone else owns the verification, so the handoffs are where you must focus your design.
• A handoff is a boundary where accountability changes hands, and it must be explicit: what is handed off, who is now accountable, and what they must do before it moves forward.
• A grounded build has four handoffs that matter: AI to designer (triage the claims), designer to SME (verify a finite list, not the whole module), SME to designer (fold in corrections and freeze the language), and designer to the record (log the sign-off).
• Use RACI to design the handoffs, and enforce one absolute rule: the AI may be Responsible for drafting but is never Accountable, because Accountable means a person who answers to an auditor and AI answers to no one.
• A claim never crosses from draft to published without a named human approving it, and the crossing is logged with the claim, the source, the approver, and the date.
• Verified claims are frozen language: once a SME signs a claim, no AI polish pass may touch it, because regenerated wording silently re-breaks the verification the SME gave.
• A verification that happened but was never recorded is, to an auditor, a verification that did not happen; the log converts a private act of diligence into a durable, provable fact.
• Scope the SME handoff small and specific, lock what is approved, and log at the moment of crossing; this is how you get AI speed and auditor confidence at the same time.