Instructor guide

This course is for adults who have completed AI for Everyday Work and Prompting or can demonstrate its source-checking and manual-workflow skills. The lesson package teaches a supervised assistant and workflow design, with optional current-tool prototypes. It is not a production deployment guide or a claim that any vendor lab was executed by the course author.

Prepare the class

Read the source verification notes and current official tool pages before a live session. Decide which demonstration account, if any, is already permitted. Never make account creation, payment, API credentials or a privacy-setting change a condition of participation. The no-account route uses the same source packs, decisions and rubric with a different evidence label.

Distribute the learner reader, workbook, practice folder and visuals first. Release the solutions after each attempt, or tell self-paced learners to open only the matching section. The archive separates the solutions to reduce accidental answer exposure. All examples are synthetic; do not invite learners to substitute real workplace data in class.

The proposed schedule is eight sessions totalling 17.5 hours, or four longer workshops with breaks added. Spend the practice time on artifacts, partner review, test evidence and revision, not a slideshow of tool features. Account setup and quota waits are outside the time plan.

Session guidance

Module 1: ask each learner to name a concrete output and a forbidden inference. Listen for “reserved” being treated as a synonym for “eligible.” Require a named workflow owner before accepting the contract.

Module 2: demonstrate the same configuration in a clean conversation. Show an incorrect, fluent answer and inspect it field by field. Do not imply prompt wording can guarantee security. The output contract is an interface that still needs validation.

Module 3: put P1 and N0 side by side, then P2 and D2. Ask which source applies and why. Learners should use approval, scope and dates rather than upload order. Use the November change to motivate a manifest and regression tests.

Module 4: act out a repeated notification with two event cards for R101. Then show R104 revision 2. Distinguish delivery identity from business revision before introducing any duplicate formula. Check that learners do not turn null into zero or round 1.5.

Module 5: deliberately create overlapping staff/above-limit rules on paper. Have learners explain which branches would match. Show why an exact route value helps wiring but does not itself perform all the upstream validation. The optional Make lab must be described as a manually validated, no-code prototype.

Module 6: withhold the acknowledgment card after pretending to write Q109. Ask learners whether a timeout proves failure. Reveal the existing queue record only after they request a destination check. Use two learners to demonstrate the concurrency race; do not call a serial ledger exactly-once processing.

Module 7: show an apparently successful run with a wrong hard-coded request ID. Make learners inspect the intended effect. Have them calculate metrics from explicit record lists; retain holds in the denominator and distinguish exception review from review of every draft.

Module 8: assess a coherent bundle rather than isolated worksheets. Cross-check identifiers, source versions, route names and evidence labels across files. Require the policy-change cases and the post-restoration regression check. A learner may pass the design route without claiming a live prototype.

Feedback that improves the work

Use specific feedback: “Your record cites October policy for November; select P2 and rerun the webcam boundaries.” Avoid vague feedback such as “be safer.” Ask learners to preserve the failure, explain its cause, revise one relevant element and run a regression case. A contained model failure can be good evidence of a working review boundary, but it still belongs in the test log.

For novice learners, offer the labelled-text record instead of JSON. JSON in the event pack is a portable data format, not a programming requirement. The plain-text event cards give equivalent inputs. Learners may draw the workflow or use a local document; a specialised diagramming account is not needed.

Assess consistently

Use the category anchors in the solutions book. Do not award points for adding more tools, more AI calls or an attractive interface at the expense of correctness. Do not penalise a well-justified manual step simply because it is manual. Distinguish an unimplemented idea from tested evidence.

The mandatory gates override the numeric score. If one fails, identify the exact case, required correction and retest. A proposed course pass does not grant permission to deploy with real data. Before a real pilot, the organisation needs its own access, source ownership, approval, concurrency, logging, retention and monitoring decisions.

Accessibility and pacing

Every SVG has a text equivalent in the lesson. Text files reproduce the lesson content. Use readable zoom and permit paper traces. Explain jargon on first use: a bundle is grouped fields, idempotency protects against repeated effects, and reconciliation establishes an uncertain outcome. Give extra practice on revisions and unknown-write outcomes, which are often harder than writing a prompt.

Maintenance checklist

Before each cohort, recheck account eligibility and tool labels against official sources; update the dated tool notes; run a small synthetic demonstration if a live route is offered; confirm no real connectors or automatic schedules are enabled; validate the answer key after any policy/data change; and inspect all distributed files. Record any learner pilot findings separately from the author's content and rule-logic checks.
