What Should an AI Learner Show Before Teaching a Teammate?

Most AI teaching starts too late. Someone gets a good result, records a screen share, and calls the workflow teachable.

When I taught product managers to move from writing specs to building and shipping, the recurring gap was not enthusiasm. It was a clear definition of done. That is a bounded teaching observation, not a measured study, but it points to the right pre-teaching test: can another person do the task and explain the boundary without you standing beside them? F-pms context

What should the learner show?

The learner should show a versioned transfer packet and an uncoached teach-back result. A working demo is only the learner's evidence that they can perform the workflow. It says little about whether the workflow can travel.

Here is the result from the small fixture behind this guide.

Fixture	Independent reviewer	Required checks	Result
TT-01 v1.0, synthetic project-update drafting	Blind, uncoached desk review	Reproduction, boundary, verification, failure detection, escalation	5/5 passed

The reviewer reproduced a three-bullet update, rejected a polished but unsupported candidate, preserved an unresolved decision, and named the human owner. This does not prove team-wide transfer. It shows that the packet made the intended checks executable in one low-risk task.

The rule is simple: teach only after the packet survives an independent reconstruction. If the reviewer needs your hints, the learner has demonstrated personal fluency, not teachable capability.

What belongs in the transfer packet?

The packet must make the learner's invisible assumptions visible. It should be short enough to use and specific enough to prevent a new teammate from filling gaps with guesswork.

Blank packet, ready to copy

Version and scope

• Fixture ID and version:
• Task name and role:
• Review date:
• What this exercise does not cover:

Task contract

• Baseline task:
• Intended outcome:
• What counts as done:
• Human decision owner:

Inputs and boundaries

• Allowed inputs:
• Disallowed inputs:
• Privacy boundary:
• Policy or tool boundary:

AI-assisted run

• What the tool may do:
• What the tool may not do:
• Procedure or prompt:
• Expected output shape:

Verification

• What source evidence must be checked:
• Which fields must never be invented:
• How corrections are recorded:
• What makes the output a draft rather than a decision:

Failure and recovery

• Known failed or rejected case:
• Stop rule:
• Escalation route:
• What the reviewer must say before continuing:

Teach-back record

• Reviewer type:
• Was live coaching used? Yes or no:
• Reproduction: Pass or fail, with note:
• Boundary recognition: Pass or fail, with note:
• Verification: Pass or fail, with note:
• Known-failure detection: Pass or fail, with note:
• Escalation and ownership: Pass or fail, with note:
• Sample and generalization limits:

This structure follows a practical interpretation of the competency progression in UNESCO's framework. The learner first acquires a safe task model, deepens it by applying verification and ethical boundaries, then creates a teachable artifact. UNESCO defines its framework for teachers, so this is a transfer of its progression and human-centred, ethical, practical, and professional-learning dimensions, not a claim that the packet is an official UNESCO assessment. (UNESCO)

The U.S. Department of Labor's AI Literacy Framework points in the same direction for workforce learning: use experiential learning, embed practice in occupational tasks, evaluate outputs, prepare enabling roles, and create continued-learning paths. (DOL TEN 07-25)

How do you run the teach-back without coaching?

Give the reviewer the blank packet, a new case from the same low-risk task family, and the evaluation sheet. Do not give the completed example until scoring is finished. Do not answer leading questions during the run.

1. Choose a reversible task. Use drafting, classification, extraction, or summarisation where a human can inspect the output before it leaves the workspace. Do not start with hiring, medical, legal, financial, access-control, or external-communication decisions.
2. Write the boundary before the prompt. State what data may enter the tool, what the tool may produce, what it may never decide, and who owns the final action.
3. Include a known failure. Use a case where a fluent output invents a deadline, hides uncertainty, treats a draft as a decision, or ignores a missing field. A success-only packet tests imitation.
4. Run one new case. The reviewer follows the packet and produces the output without live help. Record the raw wording, not only a score.
5. Score the five checks. Reproduction, boundary recognition, verification, known-failure detection, and escalation must each pass.
6. Decide what happens next. Teach if all five pass and the task remains low risk. Revise the packet if the reviewer can perform the task but misses a boundary or verification step. Stop if the reviewer cannot tell when to escalate or if the task has hidden high-impact decisions.

This is a small test, but it is the right shape. A task-oriented AI-literacy study argues that contextualised practical skills are more useful to assess for job use than abstract technical knowledge alone. Its result is not evidence that this exact packet works everywhere, but it supports testing the work rather than testing vocabulary. (Bogart et al.)

What did the worked fixture reveal?

The fixture used a safe task: turn a synthetic status note into a three-bullet project update draft. The learner's baseline was a manual update. AI could condense and draft. It could not send the update, edit a tracker, assign work, or decide whether a policy or import rule should change.

Input note

• Beacon weekly export ran successfully on 2026-08-21.
• Two rows are missing an owner field.
• Priya will inspect the missing-owner rows in the next reporting cycle.
• No decision has been made about changing the import rule.

The rejected AI-assisted draft

• Beacon's weekly export is complete and ready for handoff.
• Priya will resolve the two missing owners by Friday.
• The import rule should be changed to prevent recurrence.

The reviewer rejected it for three different reasons:

• “Complete and ready for handoff” concealed the two missing owner fields.
• “By Friday” invented a deadline.
• “The import rule should be changed” turned an undecided issue into a recommendation.

The corrected draft

• Beacon's weekly export ran successfully on 2026-08-21, but two rows still lack an owner.
• Priya will inspect those rows in the next reporting cycle.
• No decision has been made about changing the import rule.

The important artifact is not the polished wording. It is the correction trail. The reviewer could point from each claim to the source note, preserve uncertainty, and route the unresolved rule question to the project owner. The learner's task was to make that reasoning portable.

Microsoft's learning objectives make the same practical requirements explicit: choose suitable tasks, identify where oversight is required or AI use is inappropriate, verify outputs, address privacy and transparency, preserve accountability, collect evidence from practice, and maintain reflection as contexts change. (Microsoft Learn)

How should you score the handoff?

Use a five-row pass/fail rubric. Do not award a pass for a plausible answer if the reviewer cannot show the check behind it.

Criterion	Pass condition	Automatic fail
Reproduction	Reviewer completes the bounded task from the packet and produces the required output shape.	Learner must narrate missing steps or take over.
Boundary recognition	Reviewer names allowed and disallowed inputs, prohibited actions, and the human decision owner.	Reviewer treats the tool as authorised to decide, send, or change a system.
Verification	Reviewer traces important claims to source evidence and records corrections.	Reviewer accepts fluent wording without checking source lines, dates, owners, or uncertainty.
Known-failure detection	Reviewer rejects or repairs the included failed case for the stated reason.	Reviewer accepts invented certainty, a hidden missing field, or an unsupported commitment.
Escalation and ownership	Reviewer stops at the stated trigger and names the correct human or policy owner.	Reviewer guesses, continues, or assigns ownership to the AI tool.

The handoff passes only when all five rows pass. One failure is useful. It tells you what to repair before the workflow becomes a team habit.

Keep the raw notes. A score without the reviewer’s words hides whether they understood the boundary or merely guessed correctly. That matters because workplace learning is social. Research with 19 knowledge workers found that colleague sharing can support learning, while hiding AI use can reduce sharing and transparency. The teach-back makes the reasoning visible enough to inspect. (Xia et al.)

When should the learner stop before teaching?

Stop when the task contains a decision that the packet cannot keep human-owned, when the input boundary is unclear, or when the reviewer cannot detect the known failure. A passing reproduction is not permission to expand the task.

Use a stricter gate for work involving:

• personal, confidential, regulated, or customer data;
• employment, health, legal, financial, safety, access, or eligibility decisions;
• external messages, system writes, approvals, or irreversible actions;
• policies that vary by team, region, or current version;
• outputs that cannot be checked against source evidence.

For these tasks, keep the packet exercise as preparation only. Add the relevant policy owner, approval route, data review, and failure rehearsal before anyone teaches the workflow to a teammate. Microsoft explicitly separates tasks where AI may support work from tasks requiring human oversight or where AI use is not appropriate. (Microsoft Learn)

The principal exception is a learner who can reproduce the task but cannot explain the decision boundary. That learner may be useful as a supervised operator. They are not ready to teach.

What does this test prove, and what does it not prove?

It proves that one independent reviewer could follow TT-01 v1.0 without live coaching and pass the five checks on one synthetic task. It gives the learner a concrete revision target. It does not prove that the packet works for another role, a different tool, sensitive data, a changed policy, a larger sample, or a high-impact decision.

Version the packet when the task, tool, policy, source format, or escalation owner changes. Rerun the teach-back when any of those changes materially. Continued learning is part of the capability, not an optional follow-up. DOL's framework describes AI literacy as a path that should progress with job-specific tools and responsibilities, while UNESCO includes AI for professional learning in its competency dimensions. (DOL TEN 07-25; UNESCO)

If you are building a broader capability program, place this gate inside the AI capability-building guide. For the next step, compare the packet with workplace evidence that AI tutoring transferred capability, then use the AI workflow handoff score when the artifact is moving toward operational ownership.

My recommendation is to delay the teaching session until the packet passes. A teammate who can reproduce a happy path but cannot reject a known failure has learned the demonstration. A teammate who can reproduce, verify, stop, and escalate has learned enough to begin a bounded transfer.