Download the complete part-05 practice pack (ZIP). Extract it and preserve its folders. All organizations, records, and results in this teaching pack are fictional.
The examples are constructed teaching material. No real customer interaction, model evaluation, handoff, appointment change, correction, or refund occurred. Expected interpretations are review criteria; observed outputs and results stay blank until an authorized evaluation is performed.
1. Service scope and triage card
Service owner / approved scope / supported channels:
What the assistant can explain:
What requires identity and current-record checks:
What requires an authorized decision or action:
Current sources, owners, effective dates, and permitted audiences:
Verified human contact route, staffed hours, and backup:
Urgent issue route:
Outage or missing-source behavior:
| Request type | Answerable facts | Missing evidence | Proposed route | Required reviewer | Completion evidence |
|---|---|---|---|---|---|
Practice: Use practice/Service-Sources.md and practice/triage-cases.csv. SVC-401 permits an answer about the fee but supplies no Friday availability. SVC-402 requests a refund without approval. The remaining cases address private records, untrusted instructions, human contact, and ambiguous troubleshooting. Do not replace missing contact details with invented ones.
2. Answer review card
Case and source interaction:
Customer questions:
Supported answer with exact source reference:
Missing facts or source conflict:
Proposed customer reply:
Necessary clarifying question or human route:
Checks: Correct identity where needed; current sources; material conditions retained; no unsupported promises; accessible next step
Reviewer, decision, and evidence:
What was actually sent or done, and evidence:
Practice: Compare the structured answer boundary with practice/svc-401-expected.json. An answer to the fee question must not mark the appointment confirmed or the full case resolved.
3. Handoff packet
Case ID and identity/access status:
Customer request and relevant original messages:
Facts and source versions:
Attempts already made and verified results:
Promises made or disputed:
Unresolved issue and impact:
Proposed owner and next action:
Routing evidence / accepted by / acceptance time:
Agreed next update / due time / backup:
Current state and resolution evidence:
Practice: practice/recovery-502-expected.json is prepared and awaiting review. Acceptance, correction sending, appointment confirmation, and remedy approval are not supplied. practice/handoff-states.csv defines proposed state meanings, not live application behavior.
4. Recovery and incident review
Incident, discovery time, and responsible owner:
What happened, with source evidence:
Was the wrong information sent, or caught in draft?
Known affected customers, records, or actions:
Potential impact requiring investigation:
Containment or pause needed:
Correction draft and facts to recheck before sending:
Requested remedy / authorized decision / execution evidence:
| Cause hypothesis | Supporting evidence | Conflicting evidence | Next distinguishing check | Finding after check |
|---|---|---|---|---|
Customer recovery complete? Evidence:
System repair complete? Focused evaluation evidence:
Restart decision, owner, and evidence:
Practice: The two incidents in practice/recovery-cases.csv are different. REC-501 catches an obsolete price in an unsent draft. REC-502 assumes an erroneous message in a simulated scenario. It does not mean an earlier guide example actually sent a message. Use the conditional correction wording only after the stated record check in a real workflow.
5. Service quality scorecard
Cohort eligibility, opening dates, and full observation window:
Case-linking and duplicate rules:
Resolution evidence definition:
| Measure | Numerator | Denominator | Window | Result | Missing data or interpretation limit |
|---|---|---|---|---|---|
| Resolution | |||||
| First-contact resolution | |||||
| Resolution without transfer | |||||
| Customer recontact | |||||
| Satisfaction among respondents | |||||
| Survey response rate |
Severe failures requiring direct review:
Unresolved cases and next owners:
Labor, maintenance, tool, and other allocated costs:
Practice: practice/service-cohort.csv has twenty constructed cases with complete observation windows. Expected calculations are 85% resolution, 50% first-contact resolution, 60% resolution without transfer, and 15% recontact. Eight of ten survey responses are positive; ten of twenty delivered invitations receive responses. No metric establishes unattended automation performance.
6. Feedback-to-improvement brief
Decision to inform:
| Theme | Feedback IDs | Distinct case IDs | Observation | Cause hypothesis | Evidence to check | Proposed change and owner |
|---|---|---|---|---|---|---|
Serious isolated issues and contradictory evidence:
Pre-rollout evaluation:
Success definition, comparison limits, and review date:
Actual decision and result:
Practice: practice/feedback-excerpts.csv contains six excerpts from five fictional cases, separate from the metrics cohort. Fee-related comments occur in three excerpts from two cases. Do not count repeated comments as additional customers or treat F06's word “Great” as a confirmed positive rating.
7. Application checks that require a real environment
practice/application-checks.csv records proposed checks for identity/access, prompt injection with connected tools, handoff delivery and acceptance, duplicate prevention, outages, and accessible human contact. All execution fields are blank. Passing a written case does not prove an application control works.
When a later evaluation is authorized, use practice/observations.csv to retain the actual system, input version, result, reviewer, and date. Preserve material failures and the resulting decision.
Verify the constructed practice pack
From the extracted part-05/ directory:
python3 practice/verify_examples.py
The script uses only Python's standard library. It verifies fictional source references, expected states, cohort counts, feedback denominators, and cost arithmetic. Example-Verification.json records its execution. It does not run a model or perform any business action.