Capture practical AI knowledge with a teach-back

Purpose and fit

Use this when a useful AI-assisted method depends on knowledge held by one person. Capture the reasoning, checks and exceptions that are easily lost when sharing only a prompt. A colleague teaches the method back and tries a safe example. Produce an instruction card for a defined audience, with explicit limits.

Before you start

Provide an existing authorised walkthrough, notes or anonymised worked example, plus the intended audience and known boundaries. A second dataset is not needed to draft a card. Use another existing safe example for a later teach-back if available; otherwise mark that attempt as pending rather than inventing evidence.

Expect a draft practice card and blank teach-back record. Its steps should trace to the walkthrough, distinguish required judgment from repeatable actions and expose missing prerequisites; a well-written card is not evidence that another person can execute it successfully.

Required inputs

• One narrow recurring task and an experienced practitioner willing to explain the method.
• A sanitised worked example, approved sources and tool/configuration details that materially affect the result.
• The intended learners, their starting knowledge and current authority boundaries.
• A named card owner and permitted storage location; another existing safe example may be used for a later teach-back, but is not required to draft the card.

Practical workflow

1. Ask the practitioner to perform or reconstruct one example. Capture the purpose, inputs and decisions in their sequence. Ask “How did you know?” at the important checks, including any manual work omitted from the initial explanation.
2. Draft a practice card with prerequisites, steps, expected output and evidence checks. Separate repeatable instructions from choices that require domain judgment. Link to authoritative sources rather than copying sensitive source content.
3. Give the card to a colleague without coaching them through it. Ask them to explain the task, limits and stop conditions in their own words before attempting the second example.
4. Observe the attempt in a safe environment. Record unclear wording, missing context and differences between expected and actual results. If the task is unsafe or permission is uncertain, stop the attempt and document the gap.
5. Revise the card with both colleagues. Include a small example of an acceptable result and a failure signal. Remove steps that only work because the original practitioner knows unstated background.
6. Have the practice owner approve the intended scope and storage location. Set a review trigger for tool, source or workflow changes. Add a route for readers to report a broken step or propose an improvement.

Expected output

A reusable practice card with a teach-back record. Copy these fields:

Card title/version: [ ]. Task and audience: [ ]. Use when: [ ]. Do not use when: [ ]. Prerequisites/permissions: [ ]. Approved inputs: [ ]. Tool/configuration: [ ]. Steps and reasoning: [ ]. Expected output/example: [ ]. Source checks: [ ]. Common failure signals: [ ]. Stop/help route: [ ]. Owner: [ ]. Last checked: [ ]. Review trigger: [ ]. Feedback location: [ ].

Teach-back record: Example attempted: [ ]. Learner explanation of limits: [ ]. Observed confusion: [ ]. Missing instruction: [ ]. Revision made: [ ]. Unresolved issue and owner: [ ]. Scope supported by this attempt: [ ].

Keep the practice card separate from personal learning notes. Readers need corrected instructions and limits, rather than identities from practice sessions.

Human checks

The practitioner confirms that the card preserves necessary judgment instead of disguising it as a mechanical step. The colleague checks readability and can correct the observation record. The process or data owner checks permissions where needed. Verify every shared link and example for audience access, and obtain any required approval before publishing the card.

Limitations

One successful teach-back demonstrates that the selected example was understandable under those conditions. It does not establish effectiveness across unfamiliar cases. A card can become stale, and copied prompts may behave differently after tool changes. Keep a visible owner and route for correction.

Data, model variability and your responsibility

Use relevant data that exists or that you provide, with accuracy and completeness sufficient for the task. Different AI models and versions may produce different results, and responses may vary between runs. You are responsible for checking and validating the output against your own requirements, source information and acceptance criteria before relying on it.