Teach the control handoff

Choose the time you have

Before the room

1. Open the Handbook and Lab on the exact classroom browser and network.
2. For a live demo, create a separate low-credit key you can revoke; never share the teacher key.
3. Run Save & test, step 1, the three-order preview and one full Eval; compare usage and charge with the Provider dashboard.
4. Prepare the scripted/no-key route and switch to it if the live canary fails.

The no-key route is a first-class lesson

Part 1 is scripted, offline and needs no key. In the Lab, step 2 is also local. Project the remaining model results or discuss a prepared run; do not troubleshoot private credentials in front of the class.

Tell learners what a click can spend

These are maximum logical calls and output caps, not a price promise. Live cost depends on model, cache, time window and current Provider pricing.

Eval concurrency is 4. Stop prevents new scheduling and attempts to abort in-flight work, but an in-flight request may still be billed. A sent request without returned usage has unknown cost, not zero cost.

Learner worksheet

1. Write one phrasing the current rules miss and the extra rule it would require.
2. Before Eval 1, predict the score and give one reason.
3. Record the baseline, one failed case and the likely source of failure.
4. Name one change, predict its effect, then run Eval 2.
5. Record one improvement and one regression; do not hide inconvenient cases.
6. Transfer to a domain you know: one model decision, one retained control, one failure input and one irreversible gate.

Project rubric

Score each criterion 0 absent, 1 partial or 2 evidenced. A different architecture can be excellent when the evidence and trade-off are defensible.

• Problem boundary: goal, non-goals and model authority.
• Failure input: concrete, realistic and reproducible.
• Minimal eval: cases, expected evidence and an inspectable scoring rule.
• Irreversible gate: code or a person intervenes before the action.
• Trust boundaries: Provider, tools, secrets and untrusted input.
• Reflection: failures, regressions, cost, trade-offs and the next test.

Accept evidence, not one approved answer

Secret-free console output, a small JSON or Markdown result, a code link, one failed-case trace or a local report card can all be valid. The rubric does not require a particular framework, Provider or prompt.

Keep pilot observation sheets local. Never put learner keys, prompts, raw Provider bodies, replies or identifiable work into this site, screenshots or CI logs.