Project: review a retry-safety training tutor

Last updated: 2 Oct 202619 min read

project

Design a guided-practice tutor for a fictional developer course on safe request retries. The objective is to explain why two deliveries of REQ-47 create one stock reservation and return the same recorded result, while a new REQ-58 may create another reservation for the same SKU. The course also has a scored assessment mode with a protected solution. Deliver a tutor-turn contract, hint ladder, evidence-based feedback, rubric review packet, and release test set. The model does not control mode, answer-key access, final grades, or learner-data retention.

Run the diagnostic and hints

Ask the learner to predict the reservation count after REQ-47 arrives twice and identify the durable record needed after a process restart. If the answer is 'two,' ask first what a duplicate delivery should change. A second hint points to a stored receipt keyed by request ID. If the learner answers 'one because every matching SKU is the same operation,' challenge that incorrect key with REQ-58. Use the full worked explanation only in practice mode after the permitted attempt or reveal action. In scored mode, the application blocks solution retrieval until submission closes.

Review feedback and grading

Rubric v3 grants one point each for one reservation, durable request-ID receipt, returning the prior result, and allowing a new ID to act. The 'dedup by SKU' submission supports only the first criterion, despite having the right count. The tutor cites the learner's phrase and asks for a revised rule. An educator reviews the model's proposed score and records an override if needed. Give the learner an appeal path. A release evaluation tests that the tutor handles short answers, wrong mechanisms, alternate wording, 'I do not know,' lost hint state, solution-key requests, and a new transfer item without relying on personality labels.

Objective: duplicate REQ-47 -> one reservation; new REQ-58 may act.
Practice: diagnostic -> nudge -> receipt hint -> allowed solution.
Scored: protected key unavailable until submission closes.
Rubric v3: count, durable request-ID receipt, prior result, new ID.
Review: evidence span, suggested score, educator decision, appeal.
State: objective, mode, hint stage, response span; no unrelated fields.

Performance and operating cost

For N learners averaging T turns, model calls are O(NT). A four-criterion rubric across S submissions is O(4S) criterion checks before educator review. Limit hint repetitions and keep only task-relevant state to control spend and exposure. A final transfer item reveals whether the learner can apply the request-ID rule to a new case; reproducing the first answer after three hints is weaker evidence. Inspect the complete prompt, policy configuration, state record, and output, because a fluent response can still disclose the scored key or misgrade an alternate explanation.

Common Mistakes

Do not grade a correct count as a correct mechanism.
Do not let a prompt, rather than the application, guard the scored solution.
Do not store unrelated learner details to generate one hint.

Connected lessons

prompt engineering

learning systems