# Harbor Home support recovery

**Case packet version:** 2026.08.31-practice-3

This is a fictional, sanitized training case. All people, accounts, products, contacts, and records are fabricated; no real personal or confidential data is present, and no legal, safety, or warranty outcome is promised.

## Case brief · CB01

Harbor Home Systems is a fictional seller of connected thermostats. A firmware update was released to 6,200 active devices on Monday. By Wednesday, support had received 184 contacts: 91 about repeated login prompts, 47 about schedules resetting, 18 about an unfamiliar error code, and 28 unrelated questions. The public service promise says customers receive a meaningful first response within four business hours, but the queue median is 7.2 hours and 36 cases have waited longer than 12 hours. The knowledge base tells agents to reset the device, yet engineering's internal notice says repeated resets can erase diagnostic logs needed for investigation. Identity verification is inconsistent: some agents request a full date of birth for low-risk preference changes, while others make account-email changes after confirming only a device nickname. One customer says a cold home creates an urgent safety concern for an elderly parent, but the agent cannot verify conditions or diagnose health risk. A team lead drafted a blanket promise that all schedules will be restored today; engineering has only reproduced the issue on one device model and has no recovery estimate. Case notes frequently say fixed or angry customer without recording observed behavior, approved steps, result, owner, or next action. Quality reviews sample only complaints and average privacy failures into the overall score. The operations manager wants agents to close every case after sending the reset article to reduce backlog. Learners must design a truthful service response, proportionate verification, disciplined diagnosis, reliable notes, de-escalation and escalation, and a quality-coaching loop. The exercise requires urgent safety concerns to be routed through approved emergency and specialist procedures without the learner diagnosing, guaranteeing restoration, or requesting unnecessary sensitive data.

## Case record

- **F01 · confirmed:** Firmware was released to 6,200 active devices on Monday.
- **F02 · confirmed:** Support received 184 contacts across four recorded issue categories by Wednesday.
- **F03 · confirmed:** The median first response is 7.2 hours against a four-business-hour target.
- **F04 · confirmed:** Thirty-six open cases have waited longer than twelve hours.
- **F05 · conflicting:** The public reset article conflicts with engineering's instruction to preserve diagnostic logs.
- **F06 · confirmed:** Some agents request full birth dates for low-risk preference changes.
- **F07 · confirmed:** Other agents change account email after verifying only a device nickname.
- **F08 · provisional:** One customer reports an urgent cold-home concern involving an elderly parent.
- **F09 · confirmed:** Engineering reproduced schedule reset on one model and has no recovery estimate.
- **F10 · confirmed:** A team lead drafted an unsupported same-day restoration promise.
- **F11 · confirmed:** Case notes often omit observations, attempted steps, result, owner, and next action.
- **F12 · confirmed:** Quality sampling covers only complaints and averages privacy failures into total scores.

## Module assignments and operating guides

### Module 1 — Reset the service promise

**Task mode:** bounded-case-starter

Write a response standard that acknowledges delays and distinguishes response, update, and resolution commitments.

**Deliverable:** A service-promise card draft and three learner-proposed message examples pending authorized review.

**Provided inputs**

- **M01-I01 · case-fact · F01:** Firmware was released to 6,200 active devices on Monday.
- **M01-I02 · case-fact · F03:** The median first response is 7.2 hours against a four-business-hour target.
- **M01-I03 · case-fact · F04:** Thirty-six open cases have waited longer than twelve hours.
- **M01-I04 · case-fact · F09:** Engineering reproduced schedule reset on one model and has no recovery estimate.
- **M01-I05 · case-fact · F10:** A team lead drafted an unsupported same-day restoration promise.
- **M01-B01 · case-brief · CB01:** Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
- **M01-S01 · assignment-scope · F01, F03, F04, F09, F10:** Build a starter version of “A service-promise card draft and three learner-proposed message examples pending authorized review.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

**Completion boundary**

Complete a bounded starter and gap analysis using only CB01, F01, F03, F04, F09, F10, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

**Workbook plan:** M01-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F01, F03, F04, F09, and F10 are available; distinguish the four-business-hour response target from the unsupplied recovery estimate.
- [ ] STOP. If the response target is missing or recovery timing conflicts with F09/F10, record that gap and route it to the authorized engineering/service owner; do not claim approved wording, diagnosis, or restoration execution.

### Operating procedure

1. Capture the release scale and queue facts with their source IDs and confidence.
2. Define first response, progress update, and resolution as three different events.
3. Compare the 7.2-hour median and 36 aged cases with the four-business-hour response target; do not convert the target into a resolution promise.
4. Draft a cadence rule as a learner proposal and identify the service owner for approval.
5. Block the unsupported same-day restoration language and record recovery timing as not supplied.
6. Check that every statement cites F01, F03, F04, F09, or F10 and that no message is represented as sent.

### Field-by-field guidance — M01-A01

| Field | What high-quality completion requires |
|---|---|
| Promise type | Name one commitment category: first response, update cadence, or resolution boundary. |
| Supported definition or commitment | State only a bounded definition supported by the cited service facts; label any proposed cadence as a learner proposal. |
| Evidence and source ID | Cite each material observation as both module input ID and normalized fact ID. |
| Boundary or prohibited promise | State what the commitment does not mean and identify unsupported recovery or universal promises. |
| Owner | Name the authorized operating or specialist role; do not invent a person. |
| Approval status | Use Pending or Not supplied unless the packet explicitly provides an approval. |
| Gap or decision needed | Name the exact wording, cadence, ownership, or escalation decision still required. |
| Status | Use a truthful workflow state such as Draft — review pending, Open — not supplied, or Blocked. |

### Completed supported example — M01-A01

**Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work.

| Promise type | Supported definition or commitment | Evidence and source ID | Boundary or prohibited promise | Owner | Approval status | Gap or decision needed | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| First response and update cadence | Median first response is 7.2 hours against a four-business-hour target, and 36 open cases have waited more than twelve hours. | M01-I02 (F03); M01-I03 (F04) | First response is not resolution; no recovery date or universal restoration promise is supported. | Customer-service manager | Pending | Approve a proposed update cadence and escalation threshold for delayed cases. | Draft — review pending |

### Completed known-gap example — M01-A01

**Reference only.** This row demonstrates how to preserve missing evidence without inventing a result.

| Promise type | Supported definition or commitment | Evidence and source ID | Boundary or prohibited promise | Owner | Approval status | Gap or decision needed | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Resolution boundary | Engineering reproduced schedule reset on one model and has no recovery estimate. | M01-I04 (F09); M01-I05 (F10) | The drafted same-day restoration promise is unsupported and must not be used. | Qualified engineering reviewer and customer-service manager | Not supplied | Approved holding language and the release gate for any future recovery estimate are not supplied. | Blocked — approval not supplied |

### Supporting artifact build sequence

1. **M01-A02 · Learner-proposed message examples** — Produce a bounded, reviewable learner-proposed message examples from cited packet evidence while exposing unsupported fields and required approvals. Build 3 rows from M01-I04, M01-I05 and address M01-EC02, M01-EC03. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”

### Completed supporting-artifact examples

No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**.

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop any draft that promises same-day restoration, diagnosis, or universal recovery. |
| **Go** | Proceed to review when response/update/resolution are distinct and every claim is cited. |
| **Escalate** | Escalate recovery timing and technical wording to the qualified engineering/service owner. |

### Completion test

- [ ] All three promise types have operational definitions.
- [ ] F03/F04 performance facts and F09/F10 limitations are visible.
- [ ] Owner approval and sending status remain pending.

### Artifact map

- **M01-A01 · Service-promise card:** Produce a bounded, reviewable service-promise card from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 3. Criteria: M01-EC01, M01-EC04. Scoped inputs: M01-I01, M01-I02, M01-I03, M01-I04, M01-I05.
- **M01-A02 · Learner-proposed message examples:** Produce a bounded, reviewable learner-proposed message examples from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 3. Criteria: M01-EC02, M01-EC03. Scoped inputs: M01-I04, M01-I05.

### Evidence criteria

- **M01-EC01:** Defines meaningful first response, update cadence, ownership, and the difference between response and resolution
- **M01-EC02:** Avoids unsupported recovery dates and universal promises
- **M01-EC03:** Uses respectful plain language while labeling all three examples as unapproved training drafts
- **M01-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them

### Module 2 — Tier verification

**Task mode:** bounded-case-starter

Match verification strength and data collection to the risk of each requested action.

**Deliverable:** A verification decision table for six common request types.

**Provided inputs**

- **M02-I01 · case-fact · F06:** Some agents request full birth dates for low-risk preference changes.
- **M02-I02 · case-fact · F07:** Other agents change account email after verifying only a device nickname.
- **M02-I03 · case-fact · F08:** One customer reports an urgent cold-home concern involving an elderly parent.
- **M02-B01 · case-brief · CB01:** Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
- **M02-S01 · assignment-scope · F06, F07, F08:** Build a starter version of “A verification decision table for six common request types.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

**Completion boundary**

Complete a bounded starter and gap analysis using only CB01, F06, F07, F08, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

**Workbook plan:** M02-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F06–F08 are available and that no approved verification policy, birth-date rule, takeover procedure, or safety script is supplied.
- [ ] STOP. If the approved verification policy, takeover procedure, or safety script is missing or conflicts with F06–F08, record that blocker for the authorized verification-policy owner or designated safety specialist; do not claim approval or execute any identity, access, money, or safety change.

### Operating procedure

1. List six request classes as learner-proposed categories, including preference and account-email changes.
2. Assign impact and identity risk before choosing data collection.
3. Use F06 to reject excessive full-birth-date collection for low-risk preferences.
4. Use F07 to require stronger approved verification for account-email changes.
5. Add explicit failure, suspected-takeover, urgent/accessibility, and specialist-escalation paths.
6. Check that methods are marked proposed and no verification is represented as completed.

### Field-by-field guidance — M02-A01

| Field | What high-quality completion requires |
|---|---|
| Request type | Name the customer action and include its cited module input/fact ID when it is packet-supported. |
| Impact | Describe the bounded privacy, account, accessibility, or safety consequence supported by the cited fact. |
| Minimum data | List only information necessary for the action; label an unsupplied data rule as a learner proposal. |
| Approved verification | Record the approved method or Not supplied; never convert a learner proposal into policy. |
| Failure path | Define the proposed stop, retry, or takeover-escalation route without claiming execution. |
| Accessibility/safety escalation | State the reasonable-access or urgent-safety route and preserve the authorized-review boundary. |
| Owner | Name the role authorized to approve verification and escalation rules. |
| Status | Use Draft — policy review pending, Open — not supplied, or Blocked. |

### Completed supported example — M02-A01

**Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work.

| Request type | Impact | Minimum data | Approved verification | Failure path | Accessibility/safety escalation | Owner | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Low-risk preference change — M02-I01 (F06) | Some agents request full birth dates; the packet does not establish that this data is necessary. | Learner proposal — collect only the minimum approved attribute needed for the preference change. | Not supplied | Learner proposal — stop the change and route unresolved verification to an authorized owner. | Offer an approved accessible verification alternative; method not supplied. | Customer-service manager and privacy reviewer | Draft — policy review pending |

### Completed known-gap example — M02-A01

**Reference only.** This row demonstrates how to preserve missing evidence without inventing a result.

| Request type | Impact | Minimum data | Approved verification | Failure path | Accessibility/safety escalation | Owner | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Account-email change — M02-I02 (F07) | Changing account identity after only a device nickname creates an account-takeover risk. | Not supplied | A stronger approved identity check is required, but its method is not supplied. | Learner proposal — stop the change and escalate suspected takeover. | Accessible alternative and urgent-escalation procedure are not supplied. | Identity/security owner | Blocked — approved method not supplied |

### Supporting artifact build sequence

This module has no separate supporting artifact; complete the principal artifact and its decision record.

### Completed supporting-artifact examples

No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**.

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop when the requested action can change identity, access, money, or safety and approved verification is absent or fails. |
| **Go** | Proceed only for the lowest-risk action after the approved minimum verification succeeds. |
| **Escalate** | Escalate takeover signals, accessibility barriers, and urgent safety context to the designated specialist. |

### Completion test

- [ ] All six request types have risk, minimum-data, failure, and escalation rules.
- [ ] No row claims a verification result.
- [ ] F06–F08 are cited where used.

### Artifact map

- **M02-A01 · Six-request verification decision table:** Produce a bounded, reviewable six-request verification decision table from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 6. Criteria: M02-EC01, M02-EC02, M02-EC03, M02-EC04. Scoped inputs: M02-I01, M02-I02, M02-I03.

### Evidence criteria

- **M02-EC01:** Uses the minimum information needed for each action
- **M02-EC02:** Requires stronger approved verification for account-identity changes
- **M02-EC03:** Includes failure, suspected takeover, and accessibility escalation paths
- **M02-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them

### Module 3 — Diagnose without guessing

**Task mode:** bounded-case-starter

Create a question and observation flow that preserves diagnostic evidence and separates symptom from cause.

**Deliverable:** An issue-triage tree plus a bounded triage-record starter using the aggregate unfamiliar-error category, the schedule-reset evidence, and the urgent cold-home report; record-level error text, device details, and timestamps remain not supplied.

**Provided inputs**

- **M03-I01 · case-fact · F02:** Support received 184 contacts across four recorded issue categories by Wednesday.
- **M03-I02 · case-fact · F05:** The public reset article conflicts with engineering's instruction to preserve diagnostic logs.
- **M03-I03 · case-fact · F08:** One customer reports an urgent cold-home concern involving an elderly parent.
- **M03-I04 · case-fact · F09:** Engineering reproduced schedule reset on one model and has no recovery estimate.
- **M03-B01 · case-brief · CB01:** Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
- **M03-S01 · assignment-scope · F02, F05, F08, F09:** Build a starter version of “An issue-triage tree plus a bounded triage-record starter using the aggregate unfamiliar-error category, the schedule-reset evidence, and the urgent cold-home report; record-level error text, device details, and timestamps remain not supplied.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

**Completion boundary**

Complete a bounded starter and gap analysis using only CB01, F02, F05, F08, F09, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

**Workbook plan:** M03-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F02, F05, F08, and F09 are present; record that model, version, timestamps, error text, prior actions, and approved safety language are absent.
- [ ] STOP. If the device details, error record, prior actions, or approved safety language are missing or conflict with F02/F05/F08/F09, route the gap to the qualified service/engineering owner; do not claim diagnostic approval or execute a reset, repair, or safety instruction.

### Operating procedure

1. Start with observable symptom and urgency, not a diagnosis.
2. Capture device model, version, time, customer-observed symptom, and prior action as required fields.
3. Use F05 to stop reset guidance when evidence preservation applies.
4. Separate customer report F08 from engineering finding F09 and aggregate contact fact F02.
5. Route urgent safety language and technical diagnosis to qualified owners.
6. Quality-check every branch for a source ID, open question, owner, and truthful pending status.

### Field-by-field guidance — M03-A01

| Field | What high-quality completion requires |
|---|---|
| Element | Name the process node, asset, state, or transition. Module use: Use the tree to preserve diagnostic evidence and separate report, observation, and engineering conclusion. |
| From or trigger | State the observable event that activates the path. Module use: Use the tree to preserve diagnostic evidence and separate report, observation, and engineering conclusion. |
| To or outcome | State the proposed next state without implying execution. Module use: Use the tree to preserve diagnostic evidence and separate report, observation, and engineering conclusion. |
| Evidence and source ID | Pair the observation with its exact supplied source ID. Module use: Use the tree to preserve diagnostic evidence and separate report, observation, and engineering conclusion. |
| Owner | Name the authorized operating or specialist role. Module use: Use the tree to preserve diagnostic evidence and separate report, observation, and engineering conclusion. |
| Open question | Record the unanswered question that prevents a final decision. Module use: Use the tree to preserve diagnostic evidence and separate report, observation, and engineering conclusion. |
| Status | Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the tree to preserve diagnostic evidence and separate report, observation, and engineering conclusion. |

### Completed supported example — M03-A01

**Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work.

| Element | From or trigger | To or outcome | Evidence and source ID | Owner | Open question | Status |
| --- | --- | --- | --- | --- | --- | --- |
| TRIAGE-01 | Customer reports schedule reset | Preserve logs; request model, version, time, symptom, and prior-action fields before diagnosis. | F05, F09 | Qualified support and engineering reviewer | Record-level values and approved diagnostic action are not supplied. | Draft — review pending |

### Completed known-gap example — M03-A01

**Reference only.** This row demonstrates how to preserve missing evidence without inventing a result.

| Element | From or trigger | To or outcome | Evidence and source ID | Owner | Open question | Status |
| --- | --- | --- | --- | --- | --- | --- |
| TRIAGE-02 | Urgent cold-home report | Pause diagnosis and route for authorized immediate-safety wording. | F08 | Qualified safety/service owner | Temperature, device state, timestamps, and approved safety language are not supplied. | Open — escalation required |

### Supporting artifact build sequence

1. **M03-A02 · Bounded triage-record starter** — Produce a bounded, reviewable bounded triage-record starter from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M03-I02 and address M03-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
2. **M03-A03 · Triage evidence-gap register** — Produce a bounded, reviewable triage evidence-gap register from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M03-I03 and address M03-EC03. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”

### Completed supporting-artifact examples

No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**.

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop reset or diagnostic guidance when logs may be lost, facts are incomplete, or safety is implicated. |
| **Go** | Continue bounded questioning when observations can be captured without altering evidence. |
| **Escalate** | Escalate safety, unknown device state, and conflicting guidance to qualified service/engineering owners. |

### Completion test

- [ ] Every branch distinguishes report, observation, and conclusion.
- [ ] Required diagnostic fields and preservation stop are explicit.
- [ ] No error code, diagnosis, or safety instruction is invented.

### Artifact map

- **M03-A01 · Issue-triage decision tree:** Produce a bounded, reviewable issue-triage decision tree from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 5. Criteria: M03-EC01. Scoped inputs: M03-I01, M03-I04, M03-I02, M03-I03.
- **M03-A02 · Bounded triage-record starter:** Produce a bounded, reviewable bounded triage-record starter from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M03-EC02. Scoped inputs: M03-I02.
- **M03-A03 · Triage evidence-gap register:** Produce a bounded, reviewable triage evidence-gap register from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M03-EC03. Scoped inputs: M03-I03.

### Evidence criteria

- **M03-EC01:** Provides fields for device model, version, time, observable symptom, and prior action while marking each unavailable record-level value not supplied
- **M03-EC02:** Stops the reset instruction when evidence-preservation rules apply
- **M03-EC03:** Separates the customer report, packet-level observation, and engineering conclusion without inventing an error code or diagnosis

### Module 4 — Repair notes and knowledge

**Task mode:** bounded-case-starter

Rewrite weak notes and version the conflicting article through the approved knowledge process.

**Deliverable:** A case-note quality audit, one corrected starter note using F05, F09, and F11, a blank note template, and a knowledge-base change record.

**Provided inputs**

- **M04-I01 · case-fact · F05:** The public reset article conflicts with engineering's instruction to preserve diagnostic logs.
- **M04-I02 · case-fact · F09:** Engineering reproduced schedule reset on one model and has no recovery estimate.
- **M04-I03 · case-fact · F11:** Case notes often omit observations, attempted steps, result, owner, and next action.
- **M04-B01 · case-brief · CB01:** Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
- **M04-S01 · assignment-scope · F05, F09, F11:** Build a starter version of “A case-note quality audit, one corrected starter note using F05, F09, and F11, a blank note template, and a knowledge-base change record.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

**Completion boundary**

Complete a bounded starter and gap analysis using only CB01, F05, F09, F11, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

**Workbook plan:** M04-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F05, F09, and F11; obtain no live note, approved article, effective version, or approval result.
- [ ] STOP. If the live note, article authority, effective version, or approval result is missing or conflicts with F05/F09/F11, route it to the authorized engineering and knowledge owners; do not claim article approval or execute publication, reuse, or containment.

### Operating procedure

1. Turn the five missing note elements in F11 into separate observable checks.
2. Evaluate observation, attempted steps, result, owner, and next action independently.
3. Use F05 to flag the conflicting reset article and evidence-preservation requirement.
4. Use F09 only as an engineering finding with no recovery estimate.
5. Route article authority/effective-version decisions to engineering and the knowledge owner.
6. Confirm audit results describe packet evidence, not a reviewed live note.

### Field-by-field guidance — M04-A01

| Field | What high-quality completion requires |
|---|---|
| Check ID | Use a stable identifier for the quality or control check. Module use: Use the audit to test note completeness and route the conflicting knowledge article for controlled repair. |
| Control or check | State one observable check in verb-first form. Module use: Use the audit to test note completeness and route the conflicting knowledge article for controlled repair. |
| Evidence required | Name the record or observation needed to pass the check. Module use: Use the audit to test note completeness and route the conflicting knowledge article for controlled repair. |
| Source input ID | Cite the exact Fxx or module input ID supporting the entry. Module use: Use the audit to test note completeness and route the conflicting knowledge article for controlled repair. |
| Owner | Name the authorized operating or specialist role. Module use: Use the audit to test note completeness and route the conflicting knowledge article for controlled repair. |
| Result | Record pending unless the packet explicitly supplies an observed result. Module use: Use the audit to test note completeness and route the conflicting knowledge article for controlled repair. |
| Exception or gap | Describe the missing or conflicting evidence and its consequence. Module use: Use the audit to test note completeness and route the conflicting knowledge article for controlled repair. |
| Status | Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the audit to test note completeness and route the conflicting knowledge article for controlled repair. |

### Completed supported example — M04-A01

**Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work.

| Check ID | Control or check | Evidence required | Source input ID | Owner | Result | Exception or gap | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| NOTE-OBS | Check that observable symptoms are recorded. | F11 states case notes often omit observations. | F11 | Service quality reviewer | Aggregate issue supplied in F11; row-level result pending. | Individual note sample not supplied. | Draft audit — review pending |

### Completed known-gap example — M04-A01

**Reference only.** This row demonstrates how to preserve missing evidence without inventing a result.

| Check ID | Control or check | Evidence required | Source input ID | Owner | Result | Exception or gap | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| KB-AUTH | Check reset guidance against engineering preservation instruction. | F05 identifies a conflict. | F05 | Knowledge owner and engineering reviewer | Pending | Approved replacement wording, version, and effective date not supplied. | Open — publication blocked |

### Supporting artifact build sequence

1. **M04-A02 · Corrected starter note** — Produce a bounded, reviewable corrected starter note from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M04-I02 and address M04-EC01. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
2. **M04-A03 · Blank case-note template** — Produce a bounded, reviewable blank case-note template from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M04-I02 and address M04-EC03. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
3. **M04-A04 · Knowledge-base change record** — Produce a bounded, reviewable knowledge-base change record from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M04-I01 and address M04-EC02, M04-EC04. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”

### Completed supporting-artifact examples

No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**.

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop publishing or reusing reset guidance while engineering authority and effective version are unresolved. |
| **Go** | Proceed to reviewer inspection when all five note checks and source IDs are present. |
| **Escalate** | Escalate content authority and obsolete-article containment to engineering and the knowledge owner. |

### Completion test

- [ ] Five note-quality checks are separately inspectable.
- [ ] F05/F09/F11 roles are not conflated.
- [ ] No individual note audit or article approval is claimed.

### Artifact map

- **M04-A01 · Case-note quality audit:** Produce a bounded, reviewable case-note quality audit from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 5. Criteria: M04-EC01. Scoped inputs: M04-I03, M04-I01.
- **M04-A02 · Corrected starter note:** Produce a bounded, reviewable corrected starter note from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M04-EC01. Scoped inputs: M04-I02.
- **M04-A03 · Blank case-note template:** Produce a bounded, reviewable blank case-note template from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M04-EC03. Scoped inputs: M04-I02.
- **M04-A04 · Knowledge-base change record:** Produce a bounded, reviewable knowledge-base change record from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M04-EC02, M04-EC04. Scoped inputs: M04-I01.

### Evidence criteria

- **M04-EC01:** The worked starter note captures only supplied facts, approved-step gaps, observed outcome, owner gap, and next-action gap
- **M04-EC02:** Links the proposed article change to engineering authority and a future effective version without claiming approval
- **M04-EC03:** Defines how obsolete reset guidance would be contained while authorized review remains pending
- **M04-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them

### Module 5 — Escalate risk and emotion

**Task mode:** bounded-case-starter

Respond to the urgent cold-home report without diagnosing or making an unverified safety promise.

**Deliverable:** A de-escalation script draft, urgent-escalation record starter, and manager decision request with approved emergency wording marked not supplied.

**Provided inputs**

- **M05-I01 · case-fact · F08:** One customer reports an urgent cold-home concern involving an elderly parent.
- **M05-I02 · case-fact · F09:** Engineering reproduced schedule reset on one model and has no recovery estimate.
- **M05-I03 · case-fact · F10:** A team lead drafted an unsupported same-day restoration promise.
- **M05-B01 · case-brief · CB01:** Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
- **M05-S01 · assignment-scope · F08, F09, F10:** Build a starter version of “A de-escalation script draft, urgent-escalation record starter, and manager decision request with approved emergency wording marked not supplied.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

**Completion boundary**

Complete a bounded starter and gap analysis using only CB01, F08, F09, F10, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

**Workbook plan:** M05-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F08–F10; acknowledge that actual conditions, diagnosis, immediate safety wording, recovery estimate, and completed escalation are not supplied.
- [ ] STOP. If actual conditions, diagnosis, immediate safety wording, or recovery timing are missing or conflict with F08–F10, route the draft to the qualified safety/engineering reviewer; do not claim approval, sending, completed escalation, diagnosis, or restoration execution.

### Operating procedure

1. Open with respectful acknowledgment of the reported urgency.
2. Restate only the customer report in F08 and do not confirm the underlying condition.
3. Add a visible placeholder for authorized immediate-safety wording.
4. Use F09 to avoid a recovery estimate and F10 to prohibit the same-day promise.
5. Name the qualified escalation route and decision requested without claiming handoff.
6. Review for diagnosis, safety instruction, promise, or completion language before approval.

### Field-by-field guidance — M05-A01

| Field | What high-quality completion requires |
|---|---|
| Draft ID | Use a stable training-draft identifier. Module use: Use the draft to de-escalate emotion while preserving uncertainty and specialist authority. |
| Audience and purpose | Name the intended audience and the bounded communication purpose. Module use: Use the draft to de-escalate emotion while preserving uncertainty and specialist authority. |
| Supported facts | Include only cited case facts and preserve their confidence. Module use: Use the draft to de-escalate emotion while preserving uncertainty and specialist authority. |
| Proposed wording | Write reviewable draft language; do not imply it was sent or approved. Module use: Use the draft to de-escalate emotion while preserving uncertainty and specialist authority. |
| Prohibited or unsupported claim | Name claims, promises, diagnoses, or results the evidence cannot support. Module use: Use the draft to de-escalate emotion while preserving uncertainty and specialist authority. |
| Reviewer | Name the qualified review role and leave approval pending. Module use: Use the draft to de-escalate emotion while preserving uncertainty and specialist authority. |
| Status | Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the draft to de-escalate emotion while preserving uncertainty and specialist authority. |

### Completed supported example — M05-A01

**Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work.

| Draft ID | Audience and purpose | Supported facts | Proposed wording | Prohibited or unsupported claim | Reviewer | Status |
| --- | --- | --- | --- | --- | --- | --- |
| MSG-URGENT-01 | Customer holding response for urgent cold-home report | Customer reports an urgent cold-home concern involving an elderly parent (F08); engineering has no recovery estimate (F09). | We understand the urgency. We are routing this for qualified review; approved immediate-safety wording is not supplied in this exercise. | Diagnosis, same-day restoration, and unsupplied safety instruction. | Service manager and qualified specialist | Unapproved training draft |

### Completed known-gap example — M05-A01

**Reference only.** This row demonstrates how to preserve missing evidence without inventing a result.

| Draft ID | Audience and purpose | Supported facts | Proposed wording | Prohibited or unsupported claim | Reviewer | Status |
| --- | --- | --- | --- | --- | --- | --- |
| MSG-RECOVERY-02 | Recovery-time update | No recovery estimate is supplied (F09). | Recovery timing remains pending qualified review. | Same-day restoration promise in F10. | Engineering/service owner | Open — not supplied |

### Supporting artifact build sequence

1. **M05-A02 · Urgent-escalation record** — Produce a bounded, reviewable urgent-escalation record from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M05-I02 and address M05-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
2. **M05-A03 · Manager decision request** — Produce a bounded, reviewable manager decision request from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M05-I03 and address M05-EC03. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”

### Completed supporting-artifact examples

No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**.

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop if the wording diagnoses, gives unsupplied safety instructions, or promises restoration. |
| **Go** | Proceed to human review when concern, facts, uncertainty, and escalation are explicit. |
| **Escalate** | Escalate urgent safety wording and recovery timing to qualified specialists. |

### Completion test

- [ ] Draft contains acknowledgment, fact boundary, owner route, and decision request.
- [ ] F08–F10 limitations are explicit.
- [ ] Sent/approved/escalated status remains false or pending.

### Artifact map

- **M05-A01 · De-escalation script draft:** Produce a bounded, reviewable de-escalation script draft from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M05-EC01, M05-EC04. Scoped inputs: M05-I01, M05-I02, M05-I03.
- **M05-A02 · Urgent-escalation record:** Produce a bounded, reviewable urgent-escalation record from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M05-EC02. Scoped inputs: M05-I02.
- **M05-A03 · Manager decision request:** Produce a bounded, reviewable manager decision request from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M05-EC03. Scoped inputs: M05-I03.

### Evidence criteria

- **M05-EC01:** Acknowledges concern without confirming unknown conditions
- **M05-EC02:** Requests and leaves a placeholder for authorized immediate safety direction while routing to qualified escalation; it does not diagnose or issue unsupplied instructions
- **M05-EC03:** States supplied facts, uncertainty, urgency, owner field, and decision needed without claiming an escalation occurred
- **M05-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them

### Module 6 — Build quality feedback

**Task mode:** bounded-case-starter

Replace complaint-only scoring and average-based critical-failure treatment with a defensible review system.

**Deliverable:** A sampling plan, scorecard, calibration exercise, and coaching log.

**Provided inputs**

- **M06-I01 · case-fact · F01:** Firmware was released to 6,200 active devices on Monday.
- **M06-I02 · case-fact · F02:** Support received 184 contacts across four recorded issue categories by Wednesday.
- **M06-I03 · case-fact · F03:** The median first response is 7.2 hours against a four-business-hour target.
- **M06-I04 · case-fact · F04:** Thirty-six open cases have waited longer than twelve hours.
- **M06-I05 · case-fact · F11:** Case notes often omit observations, attempted steps, result, owner, and next action.
- **M06-I06 · case-fact · F12:** Quality sampling covers only complaints and averages privacy failures into total scores.
- **M06-B01 · case-brief · CB01:** Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
- **M06-S01 · assignment-scope · F01, F02, F03, F04, F11, F12:** Build a starter version of “A sampling plan, scorecard, calibration exercise, and coaching log.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

**Completion boundary**

Complete a bounded starter and gap analysis using only CB01, F01, F02, F03, F04, F11, F12, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

**Workbook plan:** M06-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F01–F04, F11, and F12; record that contact-level population, approved sample size, critical-failure rule, reviewers, and results are absent.
- [ ] STOP. If the population access, sample size, critical-failure rule, or reviewer assignment is missing or conflicts with F01–F04/F11/F12, route the plan to the authorized quality-program reviewer; do not claim sampling approval, review execution, or quality results.

### Operating procedure

1. Define the review population and four issue categories from F02.
2. Create a representative sampling stratum plus targeted review for privacy, security, safety, and honesty risk.
3. Use F12 to separate critical failures from average scoring.
4. Define provisional sample size, cadence, and escalation threshold for authorized approval.
5. Connect findings to coaching, knowledge repair, retest, and trend review.
6. Check that no sample selection, review result, or coaching action is represented as completed.

### Field-by-field guidance — M06-A01

| Field | What high-quality completion requires |
|---|---|
| Step or milestone | Name one ordered action or decision checkpoint. Module use: Use the plan to replace complaint-only sampling with representative and risk-targeted review. |
| Trigger or date | Use a supplied trigger; write date not supplied when absent. Module use: Use the plan to replace complaint-only sampling with representative and risk-targeted review. |
| Evidence and source ID | Pair the observation with its exact supplied source ID. Module use: Use the plan to replace complaint-only sampling with representative and risk-targeted review. |
| Owner | Name the authorized operating or specialist role. Module use: Use the plan to replace complaint-only sampling with representative and risk-targeted review. |
| Gate or threshold | State a measurable provisional gate and who must approve it. Module use: Use the plan to replace complaint-only sampling with representative and risk-targeted review. |
| Dependency or gap | Name the evidence, owner, or prerequisite that blocks progression. Module use: Use the plan to replace complaint-only sampling with representative and risk-targeted review. |
| Status | Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the plan to replace complaint-only sampling with representative and risk-targeted review. |

### Completed supported example — M06-A01

**Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work.

| Step or milestone | Trigger or date | Evidence and source ID | Owner | Gate or threshold | Dependency or gap | Status |
| --- | --- | --- | --- | --- | --- | --- |
| SAMPLE-01 | Before weekly quality review | F02: 184 contacts across four categories; F12: sampling is complaint-only and averages privacy failures. | Quality owner | Learner proposal: representative category sample plus 100% review of defined critical-risk cases. | Contact-level sampling frame and approved threshold not supplied. | Draft — approval pending |

### Completed known-gap example — M06-A01

**Reference only.** This row demonstrates how to preserve missing evidence without inventing a result.

| Step or milestone | Trigger or date | Evidence and source ID | Owner | Gate or threshold | Dependency or gap | Status |
| --- | --- | --- | --- | --- | --- | --- |
| SAMPLE-02 | Before selecting records | F11 reports common note omissions. | Service QA reviewer | Gate: sampling frame and access authorization must be approved. | Record list, reviewers, and privacy handling are not supplied. | Blocked — not supplied |

### Supporting artifact build sequence

1. **M06-A02 · Service quality scorecard** — Produce a bounded, reviewable service quality scorecard from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M06-I02, M06-I06 and address M06-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
2. **M06-A03 · Calibration exercise** — Produce a bounded, reviewable calibration exercise from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M06-I03 and address M06-EC03. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
3. **M06-A04 · Coaching log** — Produce a bounded, reviewable coaching log from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M06-I04 and address M06-EC03, M06-EC04. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”

### Completed supporting-artifact examples

No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**.

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop selection or review when access, sampling frame, or critical-failure definitions are not approved. |
| **Go** | Proceed to design review when representative and targeted strata, cadence, and owner are defined. |
| **Escalate** | Escalate any privacy, security, safety, or honesty critical failure outside average scoring. |

### Completion test

- [ ] Population, strata, cadence, owner, and provisional gate are present.
- [ ] Critical failures are separate from average score.
- [ ] Execution and results remain pending.

### Artifact map

- **M06-A01 · Quality sampling plan:** Produce a bounded, reviewable quality sampling plan from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 6. Criteria: M06-EC01. Scoped inputs: M06-I01, M06-I05, M06-I02, M06-I06.
- **M06-A02 · Service quality scorecard:** Produce a bounded, reviewable service quality scorecard from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M06-EC02. Scoped inputs: M06-I02, M06-I06.
- **M06-A03 · Calibration exercise:** Produce a bounded, reviewable calibration exercise from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M06-EC03. Scoped inputs: M06-I03.
- **M06-A04 · Coaching log:** Produce a bounded, reviewable coaching log from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M06-EC03, M06-EC04. Scoped inputs: M06-I04.

### Evidence criteria

- **M06-EC01:** Uses representative sampling plus targeted risk review
- **M06-EC02:** Defines privacy, security, safety, and honesty critical failures separately
- **M06-EC03:** Connects findings to coaching, knowledge repair, retest, and trend monitoring
- **M06-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them

## Ambiguities to preserve

### The customer describes an urgent safety concern, but the agent cannot verify conditions or determine medical or building risk.

**Judgment required:** Choose immediate approved safety direction and escalation while preserving empathy and avoiding diagnosis.

**Do not assume:** Do not dismiss the concern, confirm a medical danger, or promise device restoration.

### Closing cases after sending an article may improve backlog metrics while leaving issues unresolved and destroying diagnostic evidence.

**Judgment required:** Define closure and pending-investigation states that reflect customer outcome and ownership.

**Do not assume:** Do not optimize queue counts by relabeling unresolved work as complete.

## Debrief guide

There is no single universal script for every customer. Strong service uses verified facts, proportionate controls, honest commitments, accessible choices, and qualified escalation.

### Module 1

A service target can be measurable without promising a resolution outside the team's control. The strongest messages explain ownership, next update, and what remains unknown.

**Strong evidence may include**

- Defined response and update standard
- Claim-reviewed message examples

### Module 2

Verification should rise with action risk and avoid unnecessary collection. A device nickname may support troubleshooting context but cannot authorize a material account change.

**Strong evidence may include**

- Action-to-risk table
- Approved alternative and failure paths

### Module 3

Diagnosis begins with observable facts and preserves evidence. A learner may choose different questions, but the flow must not convert correlation or customer blame into cause.

**Strong evidence may include**

- Fact-separated triage record
- Evidence-preservation stop condition

### Module 4

Notes should let the next agent continue safely without rereading everything. Knowledge changes require source authority, versioning, distribution, and removal of obsolete guidance.

**Strong evidence may include**

- Actionable structured notes
- Approved knowledge change trail

### Module 5

Empathy and urgency can coexist with clear limits. The agent should route safety concerns using approved guidance and give specialists a concise, factual decision request.

**Strong evidence may include**

- Risk-aware escalation packet
- No-diagnosis and no-guarantee language

### Module 6

Complaint cases reveal risk but are not representative of all work. Critical failures should not disappear inside an average, and calibration should test reviewer agreement.

**Strong evidence may include**

- Representative sampling logic
- Critical-failure and calibration record

## Specialist escalation boundaries

### Reported immediate safety, health, freezing, fire, electrical, or vulnerable-person concern

**Route to:** Approved emergency or safety pathway, qualified technical responder, and local emergency services when the policy directs

**Learner boundary:** The agent does not diagnose conditions or substitute for emergency or technical professionals.

### Warranty, privacy, account takeover, identity, product-liability, or legally binding resolution

**Route to:** Authorized warranty, privacy, security, legal, or product-safety owner

**Learner boundary:** The learner records and routes facts but cannot promise coverage or make a legal determination.

## Use of the self-review rubric

Use the accompanying rubric to inspect the work, identify revisions, and prepare questions. It is formative guidance only—not a grade, verified completion, credential assessment, professional approval, or substitute for a qualified reviewer.