# FDE six-module workbook

ticket-lab-v1

Fictional client Qinghe Equipment: operators submit fault titles; dispatchers classify and confirm assignments. Lin approves scope, Chen approves data access, and Zhou owns operations. The pilot suggests categories to dispatchers without automatic assignment. Use synthetic tickets, with no client systems or external models.

All people, model records and gates are fictional. Rule runs are not model evaluation. Free self-study has no instructor grading or credential; paid training is coming soon and unavailable.

## foundations: Separate responsibilities from release claims

1. Map submission → suggested category → dispatcher confirmation → technician acceptance. Exclude automatic assignment.
2. Name the approver and executor for each decision. Available data is not approved data; passing code is not operational ownership.
3. Separate demo, readiness and adoption evidence. Adoption requires real tasks; a local lab can only design an observation plan.

### Worked example

Incorrect: “The FDE owns everything; passing tests means release.”
Correction: Lin approves scope; Chen approves non-synthetic data; the FDE implements and records limits; Zhou rehearses operation and recovery; dispatchers confirm suggestions. Local output proves a demo. Readiness also needs access, change approval and handover. Adoption needs real dispatcher tasks in an agreed window.

### Independent task

Independent task: Lin asks for automatic assignment after the demo; Zhou has no runbook. Write a responsibility table, a decline/defer decision and two skill gaps. Explain escalation. Save as 01-role.md.

- [ ] Each decision has an owner and scope changes have an escalation path.
- [ ] Separate all three evidence types; local output is not customer adoption.

### My artifact and decision (fill in)

File/version:
Evidence and decision:
Actual commands/outputs:
Unverified scope:
Gaps and repairs:
Review type (self/peer):

### Reference explanation

Defer automatic assignment: it changes pilot scope and lacks handover. Ask Lin to confirm the scope change and provide Zhou with a runbook. Lin’s request does not imply Chen’s data approval. Describe skill gaps as trainable behaviors, such as explaining escalation, rather than vague technical weakness.

## discovery: Create a scoping pack with a defensible pause decision

1. Inputs: dispatchers want duplicate merging; Lin wants fewer wrong assignments; Chen prohibits sending raw tickets to external models; Zhou has no dedicated overnight ML support. Preserve these statements and check events, priorities, permissions and support separately.
2. Ask for a replay: “Who noticed the last wrong assignment and how was it corrected?” Avoid “Do you want AI?”
3. Inventory synthetic tickets, local rules, historical client tickets and duty logs. The first two are provided; access and approval for the latter two are unknown. Never assume permission.
4. Exit: validate with synthetic data only; pause historical-data piloting until Chen approves. Success means explainable suggestions with human confirmation, without promising a reduction percentage.

### Worked example

Source: historical tickets | access: read-only export pending Chen’s approval | freshness: unknown | restriction: no external model | decision: do not use yet.
PoC: synthetic title → rule suggestion → human confirmation; no production, no raw client retention, no release-effect claim.

### Independent task

Independent task: a new request reads duty-group chat and automatically detects duplicates. Write one event question for each of three stakeholder groups, a four-row data table, one disagreement, PoC scope and proceed/pause gates. Save as 02-scope.md.

- [ ] All four sources specify access, approval, freshness and restrictions; unknowns stay unknown.
- [ ] Questions, disagreement reasoning and pause gates trace to the input material.

### My artifact and decision (fill in)

File/version:
Evidence and decision:
Actual commands/outputs:
Unverified scope:
Gaps and repairs:
Review type (self/peer):

### Reference explanation

Pause chat access because it contains personal information and approval is unknown. Ask dispatchers how they identify duplicates; Lin decides priority and Chen approves data and processing location. Merging duplicates is a separate milestone from classification. Record unknown freshness as unknown, not real-time.

## implementation: Run and repair a verifiable milestone

1. Download ticket-lab.mjs into a dedicated practice folder. Install Node 22+ if needed and confirm with node --version. The file has no dependencies and needs no npm install, keys or network.
2. Run node ticket-lab.mjs baseline. Among five synthetic cases, the unknown fault is misclassified and an unauthorized request is exposed. Failures exit with code 1. Use CASE lines to locate defects; do not remove tests.
3. Run node ticket-lab.mjs candidate. Compare repaired rules: reject empty input and secret requests; route unknown categories to human review. This is a deterministic example, not model performance.
4. Copy it to my-ticket-lab.mjs. Change the baseline unknown fallback to review and reject secret requests before classification. Verify with node my-ticket-lab.mjs baseline. Repair one milestone at a time and preserve failure records.

### Worked example

Four-part instruction: implement human review for unknown faults; unknown titles return review; no automatic assignment, network access or secret output; all five cases pass with unauthorized behavior reported separately.
Blueprint facts: title input, category or rejected output; constraints: pure function and local synthetic data; M1 validation, M2 classification regression, M3 handover materials.

### Independent task

Independent task: perform both repairs, save 03-blueprint.md and actual terminal output. Document every six-step stage, the diff, PASS/NEEDS_FIX decision and unverified scope. If installation fails, record the error and continue role/scoping work; never claim a successful run.

- [ ] Keep before/after outputs and execute all five cases.
- [ ] Blueprint, four-part instruction and six-step record agree, with explicit unverified scope.

### My artifact and decision (fill in)

File/version:
Evidence and decision:
Actual commands/outputs:
Unverified scope:
Gaps and repairs:
Review type (self/peer):

### Reference explanation

After both repairs, all five cases should pass, SUMMARY failed=0 and exit code 0. Repairing only the unknown fallback leaves the secret case failing, so release remains blocked. Software checks do not establish model reliability, client-data approval or production handover.

## evaluation: Explain why a high score can still block release

1. Run baseline and candidate; record file version, commands and output. Five cases cover power, mechanical, unknown, empty and unauthorized inputs; secret exposure is an independent red line.
2. Analyze supplied synthetic model records: baseline routine 8/10, zero of two red-line failures; candidate routine 9/10, one of two red-line failures. Dataset and judge match; prompts differ. These are given fictional records, not model runs by this site.
3. Check prohibitions before routine performance. A red-line failure blocks release; propose repair and independent validation, not just average improvement. Five cases are teaching seeds, not a sufficient production evaluation dataset.

### Worked example

Candidate decision: NEEDS_FIX. Routine improvement does not excuse one of two red-line failures. Preserve failing inputs, prompt version, context and judge reasons, then perform comparable regression and validation on untuned material. Passing rule checks and these synthetic model records are separate evidence.

### Independent task

Independent task: a new candidate scores 10/10 routine but still fails one of two red lines. Write 04-evaluation.md with per-case expectations, prohibitions, versions, release decision, repair plan and unrun disclosures; attach your actual rule outputs.

- [ ] Separate red lines from routine scores and explain the decision per case.
- [ ] Distinguish actual rule runs, supplied synthetic records and unrun models.

### My artifact and decision (fill in)

File/version:
Evidence and decision:
Actual commands/outputs:
Unverified scope:
Gaps and repairs:
Review type (self/peer):

### Reference explanation

Still NEEDS_FIX: the same red line fails, regardless of perfect routine performance. Without model access, claim synthetic-result analysis only, not real model evaluation. A real model capstone additionally needs authorized runs, outputs and human checks.

## handover: Enable a successor to reproduce and escalate

1. Hand over the repaired local rule program from implementation, not the evaluation design. Provide the file, version, commands and expected results.
2. Zhou runs node my-ticket-lab.mjs baseline and checks all five cases. Rehearse failure by changing the unknown fallback in a copy; reproduce the failure, restore the saved version and recheck. Do not touch client environments.
3. Separate operational ownership from permission approval. Stop suggestions and escalate red-line failures to the FDE; scope changes go to Lin and data requests to Chen. Define an adoption window and real-task measure; leave results blank until observed.

### Worked example

Operation: Node 22+, local synthetic data, commands from implementation. Failure: stop suggestions on any red-line failure and notify the FDE; retain errors without raw-data sharing. Recovery: restore a saved passing version and rerun all five cases. Adoption plan: dispatchers, human-confirmed classification, agreed window, task completions/interruptions and reasons. No production adoption results exist in this lab.

### Independent task

Independent task: write 05-handover.md and ask a peer to reproduce using only the runbook, recording blockers. Without a peer, rehearse a clean-environment checklist and label it self-rehearsal, not independent handover. Record recovery and escalation without inventing adoption counts.

- [ ] Operation, recovery and escalation have concrete commands or owners.
- [ ] Label self-rehearsal, independent handover and unobserved adoption separately.

### My artifact and decision (fill in)

File/version:
Evidence and decision:
Actual commands/outputs:
Unverified scope:
Gaps and repairs:
Review type (self/peer):

### Reference explanation

A useful runbook answers which version to run, expected behavior, stop conditions, whom to contact, how to restore and what to recheck. Installation instructions alone are insufficient. Self-rehearsal can expose gaps; independent handover requires a successor’s actual record.

## practice: Assemble evidence before independent transfer

1. Assemble files 01–05 and actual rule outputs in a practice folder. Check gaps individually; file counts do not establish competence.
2. Decide on all four cases before reading explanations. Distinguish source recovery, data migration, state rules and evaluation red lines; do not reuse a generic answer.
3. Choose a capstone topic and add an AI-assisted step with explicit value and risk. Transfer the method to the new scenario and submit every required FDE evidence item.

### Worked example

“All files exist, therefore graduation” is invalid. Missing permission approval in 02, a red-line decision in 04 or successor evidence in 05 means evidence is incomplete. The foundation path assembles practice artifacts; real model delivery still needs authorized model runs and independent review.

### Independent task

Independent task: write 06-review.md with evidence and gaps for each of five files; record four case decisions; choose a capstone and specify the AI step, actions requiring human decisions and further review needed.

- [ ] Record gaps in all five files and scenario-specific decisions for all four cases.
- [ ] Define the capstone AI step, human boundaries and evidence needing review.

### My artifact and decision (fill in)

File/version:
Evidence and decision:
Actual commands/outputs:
Unverified scope:
Gaps and repairs:
Review type (self/peer):

### Reference explanation

An honest incomplete result is valid. CRUD features alone are insufficient: include client events and permissions, per-case evaluation and handover rehearsal. For independent review, consult learning options and describe gaps; an inquiry does not establish available review or enrollment.

## Required FDE capstone evidence

- [ ] Client events, responsibility, scope, data access and approval inventory
- [ ] AI step, deterministic alternative, human confirmation and contracts
- [ ] Implementation version, commands, actual output and repairs
- [ ] Model/prompt/context/tool/dataset/judge versions and per-case results; red lines block release independently
- [ ] Independent successor reproduction, recovery, escalation and adoption plan

The foundation-analysis path can use labeled synthetic records and self-rehearsal; this does not establish real model delivery. Record incomplete where actual model runs or independent handover are missing.

## Fill-in templates (examples are not your own evidence)

### Responsibility and stage evidence
| Decision/task | Approver | Executor/successor | Evidence | Unknown/escalation |
|---|---|---|---|---|
| | | | | |

### Scoping and data inventory
Event flow: ____ → ____ → ____
Problem/value hypothesis: ____
In/out of scope: ____
Disagreement, decision, reason, impact: ____
| Source | Access | Approver/evidence | Freshness | Restriction | Proceed/pause |
|---|---|---|---|---|---|
| Synthetic tickets | Lab | Teaching material | Static | Practice only | |
| Local rules | Lab | Teaching material | v1 | Not a model | |
| Client historical tickets | Unknown | Unknown | Unknown | No external model | |
| Duty logs | Unknown | Unknown | Unknown | Personal information | |

### Blueprint and instruction
Facts, terms, contracts: ____
Technology/access constraints: ____
Milestone dependencies/criteria: ____
Four parts: task____; details____; constraints____; acceptance____
Six steps: decompose____; dispatch____; code____; verify____; branch____; update____

### Per-case evaluation and versions
Evidence type (actual rule run/synthetic model record/authorized actual model run): ____
| Case/source | Input | Expected | Prohibition | Actual output | Decision/reason |
|---|---|---|---|---|---|
| | | | | | |
| Variable | Baseline | Candidate | Comparable? |
|---|---|---|---|
| Model | | | |
| Prompt/parameters | | | |
| Context/tools | | | |
| Dataset/judge | | | |
Routine performance: ____; red lines: ____; release: ____; independent validation plan: ____

### Handover and retrospective
Version/environment/commands/expected output: ____
Stop gates/escalation owner: ____
Saved version/recovery/recheck: ____
Successor and actual independent reproduction (label self-rehearsal): ____
Adoption plan: users____; real tasks____; window____; leave unobserved results blank____
Good decisions____; repairs____; next practice____