# Redwood Assist governed intake workflow

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

This is a fictional, sanitized AI-governance training case. All records are fabricated, and the exercise provides no legal, privacy, employment, medical, financial, security, or model-performance guarantee.

## Case brief · CB01

Redwood Assist is a fictional services company considering an AI workflow to summarize new client intake and draft a routing recommendation. The current form receives about 420 submissions each month. It includes name, business email, phone, company, project description, budget range, requested timing, and an optional attachment. In a sample of 60 fabricated records, seven attachments contain government identifiers, four contain medical details unrelated to the service, nine include third-party personal information, and 16 lack enough context for reliable routing. The proposed model vendor offers a standard account with model-improvement use enabled by default and a 30-day content retention statement. No security, privacy, contract, data-location, deletion, or subprocessors review has been completed. A pilot prompt tells the model to identify serious founders and reject low-quality leads. The output labels applicants high, medium, or low potential, but neither potential nor serious is defined. In a 40-record test, the model routes 31 correctly according to one manager, while a second manager disagrees on 11 of those decisions. Two Spanish-language submissions are summarized with missing budget conditions. The team proposes automatically rejecting low-rated applicants and sending their attachment to a funding partner. There is no consent for partner disclosure, no human-review standard, no protected exception path, and no versioned evaluation set. Leadership wants the automation live next week to save eight hours of staff time. Learners must classify risk, constrain instructions and sources, establish data boundaries, design meaningful human review, build an evaluation set, and control exceptions and changes. The exercise cannot establish vendor suitability, lawful processing, fairness, or permission to automate decisions.

## Case record

- **F01 · confirmed:** The intake workflow receives about 420 submissions per month.
- **F02 · confirmed:** Seven of sixty fabricated attachments contain government identifiers.
- **F03 · confirmed:** Four contain unrelated medical details and nine contain third-party personal information.
- **F04 · confirmed:** Sixteen sampled records lack enough context for reliable routing.
- **F05 · confirmed:** Vendor model-improvement use is enabled by default and content retention is stated as thirty days.
- **F06 · unknown:** Security, privacy, contract, data location, deletion, and subprocessors have not been reviewed.
- **F07 · confirmed:** The prompt uses undefined labels serious founders and low-quality leads.
- **F08 · conflicting:** Managers disagree on eleven of thirty-one supposedly correct routing decisions.
- **F09 · confirmed:** Two Spanish-language summaries omit budget conditions.
- **F10 · provisional:** The team proposes automatic rejection using the low-potential label.
- **F11 · confirmed:** No consent supports sending attachments to the proposed funding partner.
- **F12 · provisional:** Leadership estimates eight staff hours could be saved each month.

## Module assignments and operating guides

### Module 1 — Classify the workflow

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

Define the task, affected people, harm paths, reversibility, prohibited uses, and approval boundary.

**Deliverable:** An AI use-case and risk card with an initial proceed, redesign, or stop recommendation.

**Provided inputs**

- **M01-I01 · case-fact · F01:** The intake workflow receives about 420 submissions per month.
- **M01-I02 · case-fact · F02:** Seven of sixty fabricated attachments contain government identifiers.
- **M01-I03 · case-fact · F03:** Four contain unrelated medical details and nine contain third-party personal information.
- **M01-I04 · case-fact · F04:** Sixteen sampled records lack enough context for reliable routing.
- **M01-I05 · case-fact · F07:** The prompt uses undefined labels serious founders and low-quality leads.
- **M01-I06 · case-fact · F10:** The team proposes automatic rejection using the low-potential label.
- **M01-I07 · case-fact · F11:** No consent supports sending attachments to the proposed funding partner.
- **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, F02, F03, F04, F07, F10, F11:** Build a starter version of “An AI use-case and risk card with an initial proceed, redesign, or stop recommendation.” 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, F07, F10, 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:** M01-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F01-F04, F07, F10, and F11; record that no approved taxonomy, lawful sharing basis, human-review standard, error tolerance, or production authorization is supplied.
- [ ] STOP. If the taxonomy, lawful sharing basis, human-review standard, error tolerance, or production authority is missing or conflicts with F01–F04/F07/F10/F11, route the use case to authorized privacy, legal, security, and accountable-process reviewers; do not claim approval or execute external sharing, automatic rejection, or deployment.

### Operating procedure

1. Capture monthly volume, missing-context, sensitive-data, undefined-label, rejection, and consent facts with exact source IDs.
2. Separate extraction, summarization, routing assistance, and consequential rejection into distinct proposed uses.
3. Classify information and decision impact before considering automation.
4. Apply a reversible-assistance test: keep missing-context and sensitive-data cases under qualified human control.
5. Compare assist, redesign, and stop options without treating estimated time savings as validation.
6. Route privacy, legal, security, and operational decisions to named roles and leave authorization pending.
7. Final-QC every statement for cited evidence, defined labels, prohibited external sharing, and truthful status.

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

| Field | What high-quality completion requires |
|---|---|
| Use-case ID | Assign a stable training ID to one bounded AI use. |
| Use purpose | Describe the intended assistance, routing, rejection, or disclosure purpose without claiming deployment. |
| Information class | Classify supplied content types and identify sensitive data using cited evidence. |
| Decision impact | State whether the use is assistive or consequential and whether it is reversible. |
| Human-review boundary | Define where a competent authorized human must decide, abstain, or stop. |
| Prohibited action | Name an action the workflow must not take with missing authority or controls. |
| Required approvals | List accountable operational and specialist roles; leave approvals pending. |
| Evidence source IDs | Cite exact module input and fact IDs for every material risk statement. |
| Evidence status | Use Confirmed, Provisional, Conflicting, Unknown, or Not supplied as supported. |

### 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.

| Use-case ID | Use purpose | Information class | Decision impact | Human-review boundary | Prohibited action | Required approvals | Evidence source IDs | Evidence status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| AI-RISK-01 | Proposed automatic rejection using an undefined low-potential label. | Attachments may contain government identifiers; other sensitive-data classes require separate review. | Consequential and difficult to reverse for an applicant. | Restrict to assistive triage until labels, evidence, and meaningful review are approved. | No automatic rejection or uncontrolled processing of identifiers. | Accountable workflow owner plus privacy, legal, security, and qualified human-review owners. | M01-I02 (F02); M01-I05 (F07); M01-I06 (F10) | Confirmed proposal and observed sample conditions; approvals pending |

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

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

| Use-case ID | Use purpose | Information class | Decision impact | Human-review boundary | Prohibited action | Required approvals | Evidence source IDs | Evidence status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| AI-RISK-02 | Proposed attachment transfer to a funding partner. | Submission attachments; minimum necessary fields are not supplied. | External disclosure with privacy and control consequences. | Qualified privacy/legal review must precede any transfer. | Do not send attachments without an approved purpose and authority. | Privacy/legal and accountable process owner — not supplied | M01-I07 (F11) | Blocked — consent or other authorized basis not supplied |

### Supporting artifact build sequence

1. **M01-A02 · Proceed-redesign-stop decision record** — Produce a bounded, reviewable proceed-redesign-stop decision record from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M01-I02, 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 external sharing or automatic rejection when consent, classification, defined labels, security review, or meaningful human control is absent. |
| **Go** | Proceed only to a bounded offline design review with fabricated or sanitized inputs and traceable controls. |
| **Escalate** | Escalate consequential decisions, sensitive data, vendor terms, and disclosure questions to privacy, legal, security, and the accountable process owner. |

### Completion test

- [ ] Every proposed use has purpose, information class, impact, human boundary, and cited source.
- [ ] Assist, redesign, and stop rationales are explicit.
- [ ] No deployment, approval, or efficiency result is implied.

### Artifact map

- **M01-A01 · AI use-case and risk card:** Produce a bounded, reviewable ai use-case and risk card from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M01-EC01, M01-EC04. Scoped inputs: M01-I01, M01-I03, M01-I04, M01-I06, M01-I07, M01-I02, M01-I05.
- **M01-A02 · Proceed-redesign-stop decision record:** Produce a bounded, reviewable proceed-redesign-stop decision record from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M01-EC02, M01-EC03. Scoped inputs: M01-I02, M01-I05.

### Evidence criteria

- **M01-EC01:** Separates summarization from consequential rejection and partner disclosure
- **M01-EC02:** Identifies sensitive, multilingual, fairness, privacy, and reversibility risks
- **M01-EC03:** Names the authorized decision owner and required specialist reviews
- **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 — Constrain instructions

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

Replace subjective labels with an evidence-grounded extraction and routing specification.

**Deliverable:** A versioned instruction, source schema, output schema, and unsupported-output rule.

**Provided inputs**

- **M02-I01 · case-fact · F04:** Sixteen sampled records lack enough context for reliable routing.
- **M02-I02 · case-fact · F07:** The prompt uses undefined labels serious founders and low-quality leads.
- **M02-I03 · case-fact · F08:** Managers disagree on eleven of thirty-one supposedly correct routing decisions.
- **M02-I04 · case-fact · F09:** Two Spanish-language summaries omit budget conditions.
- **M02-I05 · case-fact · F10:** The team proposes automatic rejection using the low-potential label.
- **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 · F04, F07, F08, F09, F10:** Build a starter version of “A versioned instruction, source schema, output schema, and unsupported-output rule.” 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, F04, F07, 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:** M02-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F04, F07-F10; record that the source schema, approved route taxonomy, abstention wording, multilingual fidelity test, and change approval are not supplied.
- [ ] STOP. If the source schema, route taxonomy, abstention wording, or multilingual-fidelity test is missing or conflicts with F04/F07–F10, route the instruction to the authorized domain and bilingual reviewers; do not claim change approval or execute deployment or automatic rejection.

### Operating procedure

1. Version the instruction and name its bounded classification-and-summary purpose.
2. Define required source fields before describing any output.
3. Replace serious founders and low-quality leads with observable, reviewable values or mark them prohibited.
4. Write an abstain-and-escalate branch for missing routing context.
5. Require every budget condition to be preserved in summaries and route disagreements to adjudication.
6. Prohibit automatic rejection and unsupported inference in the output rules.
7. Run final QC for version, source-to-output traceability, reviewer boundary, exception path, and pending approval.

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

| Field | What high-quality completion requires |
|---|---|
| Section or field | Name the reusable template field. Module use: Use the instruction to constrain inputs, outputs, abstention, and human review without treating prompt text as a production control. |
| Purpose | Explain the decision or control served by the field. Module use: Use the instruction to constrain inputs, outputs, abstention, and human review without treating prompt text as a production control. |
| Supported entry | Show the packet-supported starter value. Module use: Use the instruction to constrain inputs, outputs, abstention, and human review without treating prompt text as a production control. |
| Source input ID | Cite the exact Fxx or module input ID supporting the entry. Module use: Use the instruction to constrain inputs, outputs, abstention, and human review without treating prompt text as a production control. |
| Gap or learner proposal | Write “not supplied” for missing evidence; label any designed rule as a learner proposal. Module use: Use the instruction to constrain inputs, outputs, abstention, and human review without treating prompt text as a production control. |
| Owner or reviewer | Name an authorized role, never an invented person or completed approval. Module use: Use the instruction to constrain inputs, outputs, abstention, and human review without treating prompt text as a production control. |
| Status | Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the instruction to constrain inputs, outputs, abstention, and human review without treating prompt text as a production control. |

### 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.

| Section or field | Purpose | Supported entry | Source input ID | Gap or learner proposal | Owner or reviewer | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Decision boundary | Prevent an unsupported consequential outcome. | When required routing context is missing, output NEEDS_REVIEW with the missing fields; never reject automatically. | F04, F10 | Approved required-field list and routing taxonomy are not supplied. | AI workflow owner and legal/privacy reviewer | Draft - review pending |

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

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

| Section or field | Purpose | Supported entry | Source input ID | Gap or learner proposal | Owner or reviewer | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Multilingual condition preservation | Prevent omission of material terms. | Two Spanish-language summaries omitted budget conditions. | F09 | Approved translation/fidelity reference and reviewer are not supplied. | Bilingual domain reviewer | Blocked - reference needed |

### Supporting artifact build sequence

1. **M02-A02 · Source schema** — Produce a bounded, reviewable source schema from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M02-I02 and address M02-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. **M02-A03 · Output schema** — Produce a bounded, reviewable output schema from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M02-I02 and address M02-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. **M02-A04 · Unsupported-output rule** — Produce a bounded, reviewable unsupported-output rule from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M02-I01, M02-I04 and address M02-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

#### M02-A02 · Source schema

**Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work.

**Criterion demonstrated:** M02-EC02

**Why this row is included:** The canonical M02-A02 route maps M02-EC02. The row makes UNKNOWN behavior and source-field citation mandatory while preserving the supplied evidence that context and labels are unreliable.

| Term or field | Definition | Allowed values or rule | Evidence source | Owner | Change trigger | Status |
| --- | --- | --- | --- | --- | --- | --- |
| routing_context_status | Records whether the supplied source fields contain enough evidence for a routing recommendation; absence must remain UNKNOWN and route to human review. | SUPPORTED, CONFLICTING, or UNKNOWN. Cite the supporting input IDs. UNKNOWN or CONFLICTING must never trigger automatic rejection. | M02-I01 (F04), M02-I02 (F07), and M02-I03 (F08) | AI workflow owner with an authorized domain reviewer | Revise only after an approved required-field dictionary, label definition, or adjudication rule is supplied. | Learner-proposed schema — required-field dictionary and approval not supplied |

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop when the instruction uses undefined labels, permits rejection, omits required terms, or lacks an abstention path. |
| **Go** | Proceed to offline review when schemas, prohibited outputs, missing-data behavior, and human handoff are explicit. |
| **Escalate** | Escalate label disputes and multilingual material-condition failures to the accountable domain and bilingual reviewers. |

### Completion test

- [ ] Instruction purpose, version, source schema, output schema, and abstention path are aligned.
- [ ] Undefined labels and automatic rejection are prohibited.
- [ ] No instruction is represented as deployed or approved.

### Artifact map

- **M02-A01 · Versioned instruction:** Produce a bounded, reviewable versioned instruction from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 9. Criteria: M02-EC01. Scoped inputs: M02-I03, M02-I05, M02-I01, M02-I02, M02-I04.
- **M02-A02 · Source schema:** Produce a bounded, reviewable source schema from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M02-EC02. Scoped inputs: M02-I02.
- **M02-A03 · Output schema:** Produce a bounded, reviewable output schema from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M02-EC03. Scoped inputs: M02-I02.
- **M02-A04 · Unsupported-output rule:** Produce a bounded, reviewable unsupported-output rule from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M02-EC04. Scoped inputs: M02-I01, M02-I04.

### Evidence criteria

- **M02-EC01:** Uses observable intake fields and approved routing criteria
- **M02-EC02:** Requires unknown when evidence is absent and citations to source fields
- **M02-EC03:** Prohibits personality, seriousness, worthiness, or investment-quality judgments
- **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 — Set data boundaries

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

Design minimization, redaction, attachment handling, vendor review, retention, access, and disclosure controls.

**Deliverable:** A data-flow map, prohibited-data table, and vendor-review question set.

**Provided inputs**

- **M03-I01 · case-fact · F02:** Seven of sixty fabricated attachments contain government identifiers.
- **M03-I02 · case-fact · F03:** Four contain unrelated medical details and nine contain third-party personal information.
- **M03-I03 · case-fact · F05:** Vendor model-improvement use is enabled by default and content retention is stated as thirty days.
- **M03-I04 · case-fact · F06:** Security, privacy, contract, data location, deletion, and subprocessors have not been reviewed.
- **M03-I05 · case-fact · F11:** No consent supports sending attachments to the proposed funding partner.
- **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, F03, F05, F06, F11:** Build a starter version of “A data-flow map, prohibited-data table, and vendor-review question set.” 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, F03, F05, F06, 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:** M03-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F02, F03, F05, F06, and F11; record that vendor contract, data-location, deletion, subprocessors, lawful basis, and approved architecture are absent.
- [ ] STOP. If the vendor contract, data location, deletion control, subprocessor record, lawful basis, or architecture is missing or conflicts with F02/F03/F05/F06/F11, route the flow to authorized privacy, security, legal, and procurement reviewers; do not claim architecture approval or execute transmission, retention, or partner sharing.

### Operating procedure

1. Inventory each attachment-data class and its source before drawing a flow.
2. Map intake, preprocessing, vendor transmission, retention, model-improvement use, human review, partner handoff, deletion, and exception nodes.
3. Put a classification and minimization gate before vendor access.
4. Use F05/F06 to mark vendor retention and improvement use as unresolved control points.
5. Use F11 to block partner transfer where consent or another approved basis is absent.
6. Assign owners and review questions to privacy, security, legal, and operations.
7. Final-QC every edge for purpose, evidence ID, retention/deletion state, owner, and no implied approval.

### 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 map to expose where sensitive attachments could move, persist, train a model, or reach a partner before controls are approved. |
| From or trigger | State the observable event that activates the path. Module use: Use the map to expose where sensitive attachments could move, persist, train a model, or reach a partner before controls are approved. |
| To or outcome | State the proposed next state without implying execution. Module use: Use the map to expose where sensitive attachments could move, persist, train a model, or reach a partner before controls are approved. |
| Evidence and source ID | Pair the observation with its exact supplied source ID. Module use: Use the map to expose where sensitive attachments could move, persist, train a model, or reach a partner before controls are approved. |
| Owner | Name the authorized operating or specialist role. Module use: Use the map to expose where sensitive attachments could move, persist, train a model, or reach a partner before controls are approved. |
| Open question | Record the unanswered question that prevents a final decision. Module use: Use the map to expose where sensitive attachments could move, persist, train a model, or reach a partner before controls are approved. |
| Status | Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the map to expose where sensitive attachments could move, persist, train a model, or reach a partner before controls are approved. |

### 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 |
| --- | --- | --- | --- | --- | --- | --- |
| Vendor-transmission gate | Attachment intake | Quarantine or approved vendor-processing path only after classification/minimization review. | F02, F03, F05 | AI workflow owner with privacy/security reviewers | Vendor purpose, contract, data location, deletion, subprocessors, and model-improvement controls are not supplied. | Blocked - vendor 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 |
| --- | --- | --- | --- | --- | --- | --- |
| Funding-partner handoff | Generated summary or attachment | No transfer until an approved purpose and consent or other lawful basis is documented. | F11 | Privacy/legal owner | Approved disclosure basis and minimum-data specification are not supplied. | Blocked |

### Supporting artifact build sequence

1. **M03-A02 · Prohibited-data table** — Produce a bounded, reviewable prohibited-data table from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M03-I05 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 · Vendor-review question set** — Produce a bounded, reviewable vendor-review question set from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M03-I03, M03-I04 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

#### M03-A03 · Vendor-review question set

**Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work.

**Criterion demonstrated:** M03-EC03

**Why this row is included:** The canonical M03-A03 route maps M03-EC03. This row turns the supplied review gap into a complete, auditable question-and-evidence gate without inventing a contract conclusion or approval.

| Check ID | Control or check | Evidence required | Source input ID | Owner | Result | Exception or gap | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| VR-01 | Obtain authorized review of contract terms, security controls, retention, deletion, subprocessors, data location, and model-improvement use before sending attachments to the vendor. | Executed contract and data-processing terms; security review record; retention and deletion schedule; subprocessor list; data-location statement; model-improvement setting decision; and authorized reviewer disposition. | M03-I03 (F05) and M03-I04 (F06) | Authorized legal, privacy, security, and procurement reviewers | Not supplied — no vendor review result or approval is claimed. | Model-improvement use is enabled by default and retention is stated as 30 days, while the required contract, security, privacy, deletion, data-location, and subprocessor reviews are not supplied. | Blocked — authorized vendor review pending |

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop transmission, model-improvement use, retention, or partner sharing when purpose, authority, minimization, contract, and deletion controls are unresolved. |
| **Go** | Proceed only to an architecture review using sanitized representations. |
| **Escalate** | Escalate vendor and partner flows to privacy, security, legal, procurement, and the accountable process owner. |

### Completion test

- [ ] Collection-to-deletion and partner-transfer paths are visible.
- [ ] Sensitive classes, unresolved vendor controls, and consent gap are cited.
- [ ] No live transfer or deletion result is claimed.

### Artifact map

- **M03-A01 · AI data-flow map:** Produce a bounded, reviewable ai data-flow map from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 10. Criteria: M03-EC01, M03-EC04. Scoped inputs: M03-I01, M03-I02, M03-I03, M03-I04, M03-I05.
- **M03-A02 · Prohibited-data table:** Produce a bounded, reviewable prohibited-data table from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M03-EC02. Scoped inputs: M03-I05.
- **M03-A03 · Vendor-review question set:** Produce a bounded, reviewable vendor-review question set from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M03-EC03. Scoped inputs: M03-I03, M03-I04.

### Evidence criteria

- **M03-EC01:** Blocks or removes unnecessary government, medical, and third-party data
- **M03-EC02:** Separates approved intake use from partner disclosure
- **M03-EC03:** Requires authorized review of contract, security, retention, deletion, and subprocessors
- **M03-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them

### Module 4 — Make review meaningful

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

Define reviewer competence, evidence, authority, workload, and reject or escalate controls.

**Deliverable:** A human-review standard and two review-record starters: one for missing routing context and one for a Spanish-language condition omission, with unavailable source text and model output marked not supplied.

**Provided inputs**

- **M04-I01 · case-fact · F02:** Seven of sixty fabricated attachments contain government identifiers.
- **M04-I02 · case-fact · F03:** Four contain unrelated medical details and nine contain third-party personal information.
- **M04-I03 · case-fact · F04:** Sixteen sampled records lack enough context for reliable routing.
- **M04-I04 · case-fact · F08:** Managers disagree on eleven of thirty-one supposedly correct routing decisions.
- **M04-I05 · case-fact · F09:** Two Spanish-language summaries omit budget conditions.
- **M04-I06 · case-fact · F10:** The team proposes automatic rejection using the low-potential label.
- **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 · F02, F03, F04, F08, F09, F10:** Build a starter version of “A human-review standard and two review-record starters: one for missing routing context and one for a Spanish-language condition omission, with unavailable source text and model output 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, F02, F03, F04, 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:** M04-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F02-F04 and F08-F10; record that approved routing labels, reviewer qualifications, sampling method, adjudication protocol, service level, and override log are absent.
- [ ] STOP. If routing labels, reviewer qualifications, sampling, adjudication, service level, or override evidence is missing or conflicts with F02–F04/F08–F10, route the control to the accountable process owner and authorized human-review lead; do not claim review approval or execute routing, override, or production decisions.

### Operating procedure

1. Define which outcomes always require review: sensitive data, missing context, disputed labels, multilingual material terms, and proposed rejection.
2. Specify the evidence the reviewer sees and what must remain masked or minimized.
3. Define accept, correct, abstain, escalate, and reject-output actions without allowing silent override.
4. Use F08 to require independent adjudication when reviewers disagree.
5. Use F09 to require bilingual review of material-condition preservation.
6. Set escalation and pause rules for critical failures and repeated disagreement.
7. Final-QC for reviewer competence, traceability, conflict handling, appeal path, and pending authorization.

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

| Field | What high-quality completion requires |
|---|---|
| Trigger | Name an evidence-backed condition that requires human review and cite its input/fact ID. |
| Required reviewer competence | State the role capability needed; leave individual assignment or qualification evidence pending. |
| Evidence presented | List only the supplied records needed for review, with exact source IDs. |
| Allowed action | Define the bounded action a reviewer may take; do not imply approval or execution. |
| Rationale record | Specify the minimum decision rationale and source links to record. |
| Adjudication | State the independent disagreement-resolution path or Not supplied. |
| Appeal | State the proposed appeal/reconsideration path or Not supplied. |
| Escalation | Name the accountable or specialist route for unresolved risk. |
| Status | Use Draft, Pending adjudication, Blocked, or another truthful state. |

### 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.

| Trigger | Required reviewer competence | Evidence presented | Allowed action | Rationale record | Adjudication | Appeal | Escalation | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Managers disagree on 11 of 31 supposedly correct routing decisions — M04-I04 (F08). | Authorized reviewer trained on the approved routing taxonomy; competence record not supplied. | The disputed labeled records and manager decisions; record-level packet not supplied. | Adjudicate or abstain; do not enable automatic rejection. | Record selected label, cited evidence, uncertainty, reviewer role, and pending/decided state. | Independent qualified adjudicator required; identity and decision are not supplied. | Reconsideration route not supplied. | Accountable AI workflow owner and qualified risk reviewers. | Draft — adjudication design pending |

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

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

| Trigger | Required reviewer competence | Evidence presented | Allowed action | Rationale record | Adjudication | Appeal | Escalation | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Two Spanish-language summaries omit budget conditions — M04-I05 (F09). | Bilingual domain reviewer; assignment and qualification evidence not supplied. | Two omission observations; source summaries and complete references are not supplied. | Hold consequential routing and request source-aligned bilingual review. | Required preservation of omitted condition and comparison evidence is a learner proposal. | Not supplied | Not supplied | Multilingual quality owner and accountable process owner. | Blocked — review evidence not supplied |

### Supporting artifact build sequence

1. **M04-A02 · Missing-routing-context review starter** — Produce a bounded, reviewable missing-routing-context review starter from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M04-I02, M04-I03, M04-I04 and address M04-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. **M04-A03 · Spanish-condition-omission review starter** — Produce a bounded, reviewable spanish-condition-omission review starter from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M04-I05 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.”

### 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 automated progression when a mandatory-review trigger, reviewer disagreement, material-language omission, or rejected appeal is unresolved. |
| **Go** | Proceed only when a qualified reviewer can inspect evidence, correct output, record rationale, and halt the process. |
| **Escalate** | Escalate critical failures and unresolved adjudication to the accountable domain, privacy/legal, and model-risk owners. |

### Completion test

- [ ] Review triggers, allowed actions, evidence view, override log, adjudication, and escalation are defined.
- [ ] F08/F09 disputes shape the standard.
- [ ] No review outcome or authorization is fabricated.

### Artifact map

- **M04-A01 · Human-review standard:** Produce a bounded, reviewable human-review standard from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 5. Criteria: M04-EC01, M04-EC02, M04-EC04. Scoped inputs: M04-I01, M04-I06, M04-I02, M04-I03, M04-I04, M04-I05.
- **M04-A02 · Missing-routing-context review starter:** Produce a bounded, reviewable missing-routing-context review starter from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M04-EC02. Scoped inputs: M04-I02, M04-I03, M04-I04.
- **M04-A03 · Spanish-condition-omission review starter:** Produce a bounded, reviewable spanish-condition-omission review starter from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M04-EC03. Scoped inputs: M04-I05.

### Evidence criteria

- **M04-EC01:** Prevents automatic rejection in the proposed pilot
- **M04-EC02:** Provides fields for source text, model output, uncertainty, correction, and final human decision while leaving unavailable fields visibly pending
- **M04-EC03:** Provides language and sensitive-data escalation paths tied to F02 through F04 and F09
- **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 — Evaluate the risk boundary

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

Build a versioned test set with routine, difficult, multilingual, missing-data, and critical-failure cases.

**Deliverable:** A blank forty-row evaluation-plan template, populated risk-category and metric definitions, and one failure-analysis starter anchored to the supplied aggregate evidence.

**Provided inputs**

- **M05-I01 · case-fact · F02:** Seven of sixty fabricated attachments contain government identifiers.
- **M05-I02 · case-fact · F03:** Four contain unrelated medical details and nine contain third-party personal information.
- **M05-I03 · case-fact · F04:** Sixteen sampled records lack enough context for reliable routing.
- **M05-I04 · case-fact · F08:** Managers disagree on eleven of thirty-one supposedly correct routing decisions.
- **M05-I05 · case-fact · F09:** Two Spanish-language summaries omit budget conditions.
- **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 · F02, F03, F04, F08, F09:** Build a starter version of “A blank forty-row evaluation-plan template, populated risk-category and metric definitions, and one failure-analysis starter anchored to the supplied aggregate evidence.” 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, F03, F04, 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:** M05-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F02-F04, F08, and F09; record that no forty independently labeled examples, approved thresholds, adjudicator assignment, test execution, or result set is supplied.
- [ ] STOP. If the forty-case set, independent labels, thresholds, adjudicator assignment, or result set is missing or conflicts with F02–F04/F08/F09, route the evaluation to the authorized evaluation owner and adjudication reviewer; do not claim threshold approval, test execution, or performance results.

### Operating procedure

1. Reserve forty stable EV identifiers and assign balanced proposed test classes before adding examples.
2. Define five separate risk categories: extraction, routing, unsupported claims, privacy leakage, and critical failure.
3. For each row, classify only fabricated or sanitized test input and cite the aggregate fact motivating that class.
4. Keep the independent reference label pending until a qualified person labels it without seeing model output.
5. Specify expected route/output and a category-specific numerator and denominator.
6. Mark critical-failure logic as provisional and assign an adjudicator role before any run.
7. Record result as pending because no test is executed; final-QC all forty rows for coverage, independence, evidence boundaries, and version.

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

| Field | What high-quality completion requires |
|---|---|
| Evaluation ID | Use the stable EV row identifier. Module use: Use the plan to design a forty-case evaluation with independent labels and explicit failure measures, not to invent cases or results. |
| Risk category | Choose a defined risk category; do not infer a sensitive attribute. Module use: Use the plan to design a forty-case evaluation with independent labels and explicit failure measures, not to invent cases or results. |
| Test-input classification | Describe the designed test class, not real personal data. Module use: Use the plan to design a forty-case evaluation with independent labels and explicit failure measures, not to invent cases or results. |
| Independent reference label | Record pending until independently labeled and adjudicated. Module use: Use the plan to design a forty-case evaluation with independent labels and explicit failure measures, not to invent cases or results. |
| Expected route/output | State the approved expected behavior as a proposal pending owner review. Module use: Use the plan to design a forty-case evaluation with independent labels and explicit failure measures, not to invent cases or results. |
| Metric | Name the category-specific measure and its denominator. Module use: Use the plan to design a forty-case evaluation with independent labels and explicit failure measures, not to invent cases or results. |
| Critical-failure flag | Mark provisional yes only for the defined severe harm condition. Module use: Use the plan to design a forty-case evaluation with independent labels and explicit failure measures, not to invent cases or results. |
| Adjudicator | Name the qualified adjudication role; do not invent an individual. Module use: Use the plan to design a forty-case evaluation with independent labels and explicit failure measures, not to invent cases or results. |
| Result | Record pending unless the packet explicitly supplies an observed result. Module use: Use the plan to design a forty-case evaluation with independent labels and explicit failure measures, not to invent cases or results. |
| Status | Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the plan to design a forty-case evaluation with independent labels and explicit failure measures, not to invent cases or results. |

### 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.

| Evaluation ID | Risk category | Test-input classification | Independent reference label | Expected route/output | Metric | Critical-failure flag | Adjudicator | Result | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| EV-01 | Privacy leakage | Fabricated attachment class containing a government-identifier pattern; no live identifier. | Pending - independently label before any run. | Quarantine for qualified review; no external transfer. | Privacy-leakage critical failures / privacy-leakage cases | Yes - provisional pending approval | Pending - authorized privacy adjudicator role not assigned | Pending - no test executed | Draft - label and adjudication pending |

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

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

| Evaluation ID | Risk category | Test-input classification | Independent reference label | Expected route/output | Metric | Critical-failure flag | Adjudicator | Result | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| EV-02 | Unsupported claims | Missing-context record class based on F04; test specimen not supplied. | Pending - reference set not supplied. | Abstain and list missing fields; no invented route or claim. | Unsupported claims / evaluated outputs | Learner proposal - pending approval | Pending - independent adjudicator not assigned | Pending - no test executed | Open - specimen, label, and approval not supplied |

### Supporting artifact build sequence

1. **M05-A02 · Risk-category and metric dictionary** — Produce a bounded, reviewable risk-category and metric dictionary from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M05-I01, M05-I02, M05-I03, M05-I04, M05-I05 and address M05-EC02, 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.”
2. **M05-A03 · Failure-analysis starter** — Produce a bounded, reviewable failure-analysis starter from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M05-I04, M05-I05 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.”

### Completed supporting-artifact examples

#### M05-A01 · Forty-row evaluation plan

**Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work.

**Criterion demonstrated:** M05-EC02

**Why this row is included:** This risk-category dictionary row makes the five separate AI evaluation measures visible without claiming that an evaluation was run.

| Evaluation ID | Risk category | Test-input classification | Independent reference label | Expected route/output | Metric | Critical-failure flag | Adjudicator | Result | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| EV-DICT-01 | Extraction accuracy/omission | Metric-definition row; test specimen not supplied. | Pending — independently labeled evaluation set not supplied. | Extract all required material fields and flag omissions. | field extraction errors / independently labeled fields | Pending rule — a material omission may be critical only after an approved severity rule. | Pending — qualified adjudicator not assigned. | Pending — evaluation not run. | Draft metric definition — approval pending |

#### M05-A01 · Forty-row evaluation plan

**Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work.

**Criterion demonstrated:** M05-EC02

**Why this row is included:** This risk-category dictionary row makes the five separate AI evaluation measures visible without claiming that an evaluation was run.

| Evaluation ID | Risk category | Test-input classification | Independent reference label | Expected route/output | Metric | Critical-failure flag | Adjudicator | Result | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| EV-DICT-02 | Routing accuracy/abstention | Metric-definition row; test specimen not supplied. | Pending — independently labeled evaluation set not supplied. | Route only supported cases and abstain when context is insufficient. | incorrect routes plus missed abstentions / independently labeled routing cases | Pending rule — a missing-context case proceeding to a consequential route may be critical. | Pending — qualified adjudicator not assigned. | Pending — evaluation not run. | Draft metric definition — approval pending |

#### M05-A01 · Forty-row evaluation plan

**Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work.

**Criterion demonstrated:** M05-EC02

**Why this row is included:** This risk-category dictionary row makes the five separate AI evaluation measures visible without claiming that an evaluation was run.

| Evaluation ID | Risk category | Test-input classification | Independent reference label | Expected route/output | Metric | Critical-failure flag | Adjudicator | Result | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| EV-DICT-03 | Unsupported claims | Metric-definition row; test specimen not supplied. | Pending — independently labeled evaluation set not supplied. | Produce no unsupported factual assertion or consequential recommendation. | outputs containing unsupported factual assertions / evaluated outputs | Pending rule — an unsupported consequential assertion may be critical. | Pending — qualified adjudicator not assigned. | Pending — evaluation not run. | Draft metric definition — approval pending |

#### M05-A01 · Forty-row evaluation plan

**Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work.

**Criterion demonstrated:** M05-EC02

**Why this row is included:** This risk-category dictionary row makes the five separate AI evaluation measures visible without claiming that an evaluation was run.

| Evaluation ID | Risk category | Test-input classification | Independent reference label | Expected route/output | Metric | Critical-failure flag | Adjudicator | Result | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| EV-DICT-04 | Privacy leakage | Metric-definition row; test specimen not supplied. | Pending — independently labeled evaluation set not supplied. | Do not expose or transfer prohibited data without approved authority. | outputs or transfers exposing prohibited data / privacy-leakage cases | Pending rule — exposure of a government identifier, medical detail, or third-party personal information may be critical. | Pending — qualified adjudicator not assigned. | Pending — evaluation not run. | Draft metric definition — approval pending |

#### M05-A01 · Forty-row evaluation plan

**Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work.

**Criterion demonstrated:** M05-EC02

**Why this row is included:** This risk-category dictionary row makes the five separate AI evaluation measures visible without claiming that an evaluation was run.

| Evaluation ID | Risk category | Test-input classification | Independent reference label | Expected route/output | Metric | Critical-failure flag | Adjudicator | Result | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| EV-DICT-05 | Critical failures | Metric-definition row; test specimen not supplied. | Pending — independently labeled evaluation set not supplied. | Detect any approved severe condition and block release pending adjudication. | approved critical-failure events / all evaluated cases | Pending — approved severe-condition list and adjudication are not supplied. | Pending — qualified adjudicator not assigned. | Pending — evaluation not run. | Draft metric definition — approval pending |

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop evaluation or release when reference labels are not independent, sensitive data is live/unapproved, a critical failure occurs, or adjudication is unresolved. |
| **Go** | Proceed to controlled evaluation only after the versioned set, labels, metrics, thresholds, owners, and privacy controls are approved. |
| **Escalate** | Escalate label disputes, privacy leakage, unsupported claims, and threshold changes to independent adjudication and the accountable risk owners. |

### Completion test

- [ ] Exactly forty EV rows exist with designed category coverage and pending results.
- [ ] Independent-label and adjudication fields are never backfilled with invented outcomes.
- [ ] Five category-specific measures and provisional thresholds are reviewable.

### Artifact map

- **M05-A01 · Forty-row evaluation plan:** Produce a bounded, reviewable forty-row evaluation plan from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 40. Criteria: M05-EC01, M05-EC02, M05-EC03. Scoped inputs: M05-I01, M05-I02, M05-I03, M05-I04, M05-I05.
- **M05-A02 · Risk-category and metric dictionary:** Produce a bounded, reviewable risk-category and metric dictionary from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M05-EC02, M05-EC03. Scoped inputs: M05-I01, M05-I02, M05-I03, M05-I04, M05-I05.
- **M05-A03 · Failure-analysis starter:** Produce a bounded, reviewable failure-analysis starter from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M05-EC02. Scoped inputs: M05-I04, M05-I05.

### Evidence criteria

- **M05-EC01:** Defines independent reference labels and an adjudication process without fabricating forty labeled examples
- **M05-EC02:** Separates extraction, routing, unsupported claims, privacy leakage, and critical-failure measures
- **M05-EC03:** Sets provisional acceptance thresholds before any future evaluation and labels them for authorized review

### Module 6 — Control change and exception

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

Draft monitoring, incident, override, change, rollback, and retirement controls without operating the workflow or executing rollback.

**Deliverable:** A workflow-runbook draft, exception-log template, change-record template, and rollback-test plan with all execution evidence pending.

**Provided inputs**

- **M06-I01 · case-fact · F05:** Vendor model-improvement use is enabled by default and content retention is stated as thirty days.
- **M06-I02 · case-fact · F06:** Security, privacy, contract, data location, deletion, and subprocessors have not been reviewed.
- **M06-I03 · case-fact · F11:** No consent supports sending attachments to the proposed funding partner.
- **M06-I04 · case-fact · F12:** Leadership estimates eight staff hours could be saved each month.
- **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 · F05, F06, F11, F12:** Build a starter version of “A workflow-runbook draft, exception-log template, change-record template, and rollback-test plan with all execution evidence pending.” 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, F06, 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 F05, F06, F11, and F12; record that approved vendor controls, transfer authority, operating roles, monitoring thresholds, rollback package, exception authority, and production approval are absent.
- [ ] STOP. If vendor controls, transfer authority, operating roles, monitoring thresholds, rollback evidence, or exception authority is missing or conflicts with F05/F06/F11/F12, route the runbook to the accountable change authority and authorized specialist reviewers; do not claim production approval or execute a change, exception release, or rollback.

### Operating procedure

1. Define versioned intake, classification, processing, human review, release, monitoring, and record-retention steps.
2. Place vendor privacy/security/contract review before any attachment transfer or model-improvement use.
3. Place consent or other approved-authority review before any partner handoff.
4. Define exception intake, risk owner, expiry, compensating control, and reapproval requirements.
5. Specify monitoring and stop triggers without inventing a baseline or threshold.
6. Design rollback prerequisites, restoration evidence, and post-rollback validation as pending controls.
7. Final-QC owners, gates, dependencies, source IDs, exception expiry, change version, and no implied execution.

### 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 runbook to control workflow change, exceptions, monitoring, and rollback before production authorization. |
| Trigger or date | Use a supplied trigger; write date not supplied when absent. Module use: Use the runbook to control workflow change, exceptions, monitoring, and rollback before production authorization. |
| Evidence and source ID | Pair the observation with its exact supplied source ID. Module use: Use the runbook to control workflow change, exceptions, monitoring, and rollback before production authorization. |
| Owner | Name the authorized operating or specialist role. Module use: Use the runbook to control workflow change, exceptions, monitoring, and rollback before production authorization. |
| Gate or threshold | State a measurable provisional gate and who must approve it. Module use: Use the runbook to control workflow change, exceptions, monitoring, and rollback before production authorization. |
| Dependency or gap | Name the evidence, owner, or prerequisite that blocks progression. Module use: Use the runbook to control workflow change, exceptions, monitoring, and rollback before production authorization. |
| Status | Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the runbook to control workflow change, exceptions, monitoring, and rollback before production authorization. |

### 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 |
| --- | --- | --- | --- | --- | --- | --- |
| Vendor-control gate | Before any attachment leaves the controlled intake boundary | F05, F06: model-improvement use is enabled; privacy/security/contract controls are unreviewed. | AI workflow owner with privacy, security, legal, and procurement reviewers | All required vendor controls reviewed and approved; evidence currently not supplied. | Contract, data-location, deletion, subprocessor, retention, and improvement-use decisions. | Blocked - review not supplied |

### 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 |
| --- | --- | --- | --- | --- | --- | --- |
| Rollback validation | Before any production change or exception release; date not supplied | F12: estimated time saving is provisional and supplies no operational baseline. | AI operations and change owner | Approved rollback package and validation checks; no threshold supplied. | Baseline, deployment version, monitoring data, restore evidence, and approval are not supplied. | Open - design review only |

### Supporting artifact build sequence

1. **M06-A02 · Exception log** — Produce a bounded, reviewable exception log from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M06-I01, M06-I02 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 · Change record** — Produce a bounded, reviewable change record 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 · Rollback-test plan** — Produce a bounded, reviewable rollback-test plan 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

#### M06-A02 · Exception log

**Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work.

**Criterion demonstrated:** M06-EC02

**Why this row is included:** The canonical M06-A02 route maps M06-EC02. The row names every required version field and explicitly prevents a reviewed-production claim while the evidence is absent.

| Entry ID | Issue or event | Evidence and source ID | Risk or impact | Owner | Bounded next step | Review point | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| VER-GATE-01 | Candidate workflow version record is incomplete: model, prompt, source set, evaluation set, owner, and approval identifiers are not supplied. | M06-I01 (F05), M06-I02 (F06), M06-I03 (F11), and M06-I04 (F12) describe unresolved vendor controls, disclosure authority, and a provisional benefit estimate; none supplies a reviewed production version. | A production baseline, change comparison, and authorized release decision cannot be demonstrated; no production version is claimed. | AI workflow and change owner with authorized privacy, security, legal, and operations reviewers | Learner-proposed gate: record the exact model, prompt, source-set, and evaluation-set versions plus owner and approval evidence; leave every unavailable value marked not supplied and block production designation. | Before production designation, change approval, or expanded use | Open — version record and approval not supplied |

#### M06-A04 · Rollback-test plan

**Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work.

**Criterion demonstrated:** M06-EC03

**Why this row is included:** M06-EC03 is canonically routed to M06-A03 and M06-A04; M06-A04 is the artifact that most directly demonstrates fallback and rollback evidence. This completed plan row defines the required proof while keeping execution and approval pending.

| Step or milestone | Trigger or date | Evidence and source ID | Owner | Gate or threshold | Dependency or gap | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Manual-fallback and rollback evidence rehearsal | Before any production change or expanded use; rehearsal date is not supplied. | M06-I04 (F12) supplies only an estimated monthly time saving; executed fallback, rollback, recovery, and comparison evidence is not supplied. | AI operations and authorized change owner | Learner-proposed gate: demonstrate completion through the manual path, restore the last authorized version, preserve logs and timestamps, and obtain reviewer disposition before expanded use. | Approved manual procedure, known-good version, safe test environment, evaluation baseline, execution record, rollback result, and approval are not supplied. | Planned — test not run and no pass result claimed |

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop production change, exception release, external sharing, or vendor processing when approval, monitoring, rollback, or data controls are absent. |
| **Go** | Proceed only to tabletop review until the full runbook, evidence capture, owners, and rollback test are approved. |
| **Escalate** | Escalate privacy/security/vendor exceptions and rollback failure to the accountable change authority and specialist reviewers. |

### Completion test

- [ ] The runbook covers normal, exception, monitoring, change, and rollback paths.
- [ ] Vendor and partner gates cite F05/F06/F11.
- [ ] No deployment, exception approval, or rollback result is implied.

### Artifact map

- **M06-A01 · Workflow runbook:** Produce a bounded, reviewable workflow runbook from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 12. Criteria: M06-EC01. Scoped inputs: M06-I03, M06-I01, M06-I02, M06-I04.
- **M06-A02 · Exception log:** Produce a bounded, reviewable exception log from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M06-EC02. Scoped inputs: M06-I01, M06-I02.
- **M06-A03 · Change record:** Produce a bounded, reviewable change record from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M06-EC03. Scoped inputs: M06-I03.
- **M06-A04 · Rollback-test plan:** Produce a bounded, reviewable rollback-test plan 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:** Defines proposed triggers for pause, investigation, notification, and re-evaluation
- **M06-EC02:** Provides version fields for model, prompt, sources, evaluation set, owner, and approval without claiming a reviewed production version
- **M06-EC03:** Defines the evidence required to demonstrate manual fallback and rollback before expanded use but does not claim either test passed
- **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

### Manager disagreement may reflect model error, an undefined policy, or both.

**Judgment required:** Establish an authorized reference standard and adjudication method before reporting accuracy.

**Do not assume:** Do not treat one manager's label or majority agreement as objective truth.

### Summarization may be low risk for some records while rejection and external disclosure materially change impact.

**Judgment required:** Decompose the workflow and decide which components, if any, are suitable for a bounded pilot.

**Do not assume:** Do not let an acceptable drafting use authorize a high-impact automated decision.

## Debrief guide

There is no single universal model, prompt, or accuracy threshold. Strong governance decomposes the use, limits data and authority, and tests consequential failures explicitly.

### Module 1

Risk changes when a summary becomes a rejection or disclosure. The use-case card should analyze each action separately and refuse to hide high-impact decisions inside an efficiency project.

**Strong evidence may include**

- Task-level harm and reversibility analysis
- Authorized use and prohibited-use boundary

### Module 2

Observable extraction is more governable than undefined worthiness labels. Grounding improves traceability but does not remove the need for correction, uncertainty, and review.

**Strong evidence may include**

- Field-cited output schema
- Explicit unknown and refusal rules

### Module 3

Redaction alone may not make an unreviewed vendor appropriate. The strongest design reduces collection, blocks sensitive attachments, and obtains contractual and technical answers before use.

**Strong evidence may include**

- Data-flow and minimization map
- Vendor-control decision record

### Module 4

A human click is not oversight. Reviewers need source visibility, competence, time, authority, and a protected way to reject the model recommendation.

**Strong evidence may include**

- Source-linked review record
- Reviewer authority and escalation standard

### Module 5

A single accuracy percentage conceals disagreement and critical harm. Evaluation should separate routine errors from privacy leakage, unsupported rejection, and language omissions.

**Strong evidence may include**

- Versioned representative test set
- Predeclared critical-failure thresholds

### Module 6

A governed pilot anticipates failure and change. Regression evidence and a tested manual fallback matter more than preserving automation uptime after the evidence boundary changes.

**Strong evidence may include**

- Versioned change and incident log
- Successful rollback and fallback test

## Specialist escalation boundaries

### Sensitive data, consent, partner disclosure, automated rejection, retention, cross-border transfer, or fairness and discrimination risk

**Route to:** Qualified privacy, legal, compliance, and responsible-AI owners

**Learner boundary:** The learner maps evidence and controls but cannot authorize processing or high-impact automation.

### Vendor security, model behavior, prompt injection, access, logging, deletion, or incident response

**Route to:** Authorized security, platform, procurement, and incident-response owners

**Learner boundary:** Training evaluation does not certify vendor or system security.

## 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.