# Lead a client-delivery pod: facilitator session pack

Edition 1 · 25 October 2026 · 60 minutes · Original LockedIn Labs teaching case

Open the [interactive pod rehearsal](/training/labs/pod-delivery). Each participant uses their own tab. Download a **Resume file (JSON)** before leaving and use **Resume a saved draft** to continue later. The workbench does not synchronize participants or save work after a refresh. Use a shared candidate label so records can be compared without collecting employee names or client information.

## 1. Set up a useful team practice

This session is for enterprise employees learning to deliver together and forward-deployed engineer (FDE) cohorts preparing for client work. The shared task is a fictional healthcare-administration service: help an operator locate a form using an authorized procedure. It produces a draft for human review. It does not send messages, provide clinical guidance or decide eligibility.

By the end, each person should be able to locate the evidence behind a handoff, return an actionable gap, explain who can resolve a source conflict, and defend a bounded next step when a client requests more. A facilitator observes those actions; attendance and a successful team presentation do not establish individual independence or placement readiness.

Use five participants where possible. Smaller groups may combine roles; record the combination and which receiving action had no independent observer. A solo learner can switch perspectives on paper and label the result self-review. The facilitator can be one of the participants, but should declare when they supply a hint.

| Role | Own contribution | Decision they do not inherit |
| --- | --- | --- |
| FDE Lead | State the delivery slice, coordinate dependencies and return a clear next decision to the client. | Client scope acceptance or permission to use a source. |
| AI Solution Architect | Explain the request, identity, source and action boundaries; show where the design stops. | The source steward's authority to withdraw or approve procedures. |
| Builder (Senior FDE / FDE I) | Identify the exact starter or changed copy, run the requested cases and supply reproducible output. | Acceptance merely because the program exits successfully. |
| FDE + AI Evaluation | Write expectations before execution, challenge both input orders and separate a prediction from an observation. | Real-world safety, usefulness or field qualification from fixture checks. |
| Client Product Owner / operator role-play | Receive the packet, try the operator task and state what the proposed scope would allow. | Access, source ownership or production release authority. |

The last role combines two perspectives only for this exercise. In an engagement, name the actual product-scope owner and receiving operator separately. The procedure steward and access owner are unresolved dependencies unless someone has explicit authority to act for them; the facilitator cannot grant that authority by assigning a role card.

## 2. Prepare the candidate and first decision — 10 minutes

Download the [offline Node.js starter](/templates/fde-client-delivery-starter.mjs). Use Node.js 24, a terminal and a working folder. No packages, model, credentials, network calls or real records are needed to run it. Read the file before execution. A tabletop-only group can inspect the source, but must label its answers as predictions.

Agree a candidate label such as `POD-EXERCISE-A/original-edition-3`. Every participant records that same label. Keep the original file and any changed copy distinct; a label is a reference, not an integrity proof. If you alter the file, retain the diff and give that candidate a new label.

Before discussing an answer, each participant writes:

- My role and the handoff I am responsible for.
- The smallest next step I would support, and the evidence I need first.
- The person or role whose decision I cannot make for them.

Start the interactive rounds to preserve this initial decision. Later reasoning goes in the revision, so the original remains visible. Use synthetic aliases if the group needs identifiers. Do not paste employee evaluations, client secrets, patient information or access tokens into a learning record.

## 3. Round one: receive a supported result — 15 minutes

Builder runs the original candidate:

```sh
node fde-client-delivery-starter.mjs supported
```

The evaluation role records the expected result before the run. Afterward, the builder passes the exact candidate, case name, source reference and observed output to the architect. The architect explains the boundary to the lead and client-role receiver. Everyone keeps their own contribution and any assistance.

The receiver must find `ADMIN-FORM-04`, version `3`, and the draft in the actual output. The starter supplies a fixed simulated actor and returns a permitted instruction verbatim in offline-scripted mode. This demonstrates the authored fixture behavior, not real authentication or a model's quality. Show the path from source to draft rather than calling it a successful AI deployment.

Use this handoff form throughout:

```text
Sender role:
Candidate / case / artifact reference:
What I predict, ran, or personally observed:
Source ID and version (or missing/conflicting reference):
Receiver role and exact action they attempted:
Decision: pending | accepted for a stated purpose | returned with a gap
Purpose or gap:
Next owner / action / evidence needed:
Assistance provided:
```

An acceptable practice decision is narrow: “Receive this output for a fixture walkthrough.” It is not “Approve the service for customers.” If the receiver cannot locate the source or candidate, return that specific gap instead of taking over their screen.

## 4. Round two: introduce the source conflict — 15 minutes

The facilitator now announces: “The source feed contains two current records with the same reference and different instructions. Someone wants to choose the first result so the demo can continue.” Ask each role to write a prediction before executing:

```sh
node fde-client-delivery-starter.mjs ambiguous
node fde-client-delivery-starter.mjs ambiguous-reversed
```

The original candidate should produce a manual outcome for both orders and withhold the draft. Preserve both actual outputs. The same-reference conflict is deliberate: a plausible instruction and a stable-looking identifier do not resolve authority. The evaluation role checks both orders; the architect locates the cardinality guard; the builder shows the exact candidate; the lead names the blocked dependency; the client-role receiver explains the manual next step.

Ask the group: Who may reconcile the procedures? What evidence would let the team try again? A strong answer identifies the procedure steward, an authorized revision or withdrawal and a new candidate evaluation. Do not change a `current` flag merely to turn the exercise green. If you inspect `resolved-current`, label its steward action as a supplied fixture assumption, not an approval you obtained.

Optional extension after the session: in a separately labeled copy, weaken the guard as described in the starter. Retain both conflicting outputs, restore the guard and explain why input order changed the answer. Keep this changed-copy experiment out of the original candidate's evidence.

## 5. Round three: transfer the work and challenge the scope — 10 minutes

The receiver takes control without the builder driving. They locate the candidate and source version, explain why the conflict withheld a draft, and describe the existing manual procedure lookup. Record whether they read the packet, received a verbal hint or needed the builder to take over. A useful returned handoff names exactly which missing instruction would let the receiver retry.

The facilitator introduces a client request: “Good demonstration. Add another location and automatically send the replies.” The FDE Lead gives a brief response supported by the other roles:

1. What the current fixture evidence supports.
2. Which new access, source, side-effect and recovery questions remain.
3. Which real owners would need to decide, and the smallest next investigation.

The client-role player can accept a proposed investigation for the role-play. They cannot convert an exercise into a client signature, access grant or release approval. Keep the current scope and requested expansion separate in the handoff.

## 6. Debrief and export individual evidence — 10 minutes

Each participant completes their own record before the group compares answers:

- My original decision and the evidence that changed it.
- The artifact or explanation I personally contributed.
- A receiving challenge I got, and how I revised my handoff.
- The help I used, including peer guidance and AI assistance.
- One next practice that would address a remaining gap.

Download a Resume file (JSON) to keep an editable copy with exact text, blanks and editor locks. Markdown and JSON reports are readable summaries; they cannot be reopened as drafts. When resuming, choose your saved resume file, inspect the case edition and role, and explicitly replace the work in your tab. Download the current draft first if you need both copies. Cancelling or selecting an invalid file leaves the current work unchanged. Older report files remain useful references, but they do not contain the raw state needed to resume.

Export a report for the facilitator to compare manually with the shared candidate and observations. Imported text and locks are participant-controlled practice; reopening them does not verify when an answer was written, execution, authenticity or independence. Files are read locally in your browser and must match this case edition. A prediction is not an executed result; reporting a peer's output is not running it yourself. Retain unanswered fields and pending decisions. Choose a retention and sharing location through the organization's normal learning process; the public workbench does not create a cohort record or store submissions.

During the debrief, look for observable actions rather than assigning a general “ready” label:

| Observation | Useful next practice if it is missing |
| --- | --- |
| Receiver finds the exact candidate and source without the sender taking over. | Repair the packet and repeat that receiving step. |
| Both conflict orders produce a correctly labeled observation or prediction. | Run both original cases and explain the guard before changing code. |
| Lead distinguishes delivery coordination from client, source and access decisions. | Rehearse the expansion request with a different owner constraint. |
| Each learner explains their own contribution and assistance. | Rotate roles in another session; preserve the first session's record. |

Continue with the [client-delivery capstone](/app/academy?course=fde-client-delivery&lesson=cohort-delivery-capstone&view=focus) under existing Academy access. It connects this rehearsal to discovery, implementation, evaluation, recovery and the complete receiving-team packet.

## References and teaching scope

Google's [SRE Workbook: Incident Response](https://sre.google/workbook/incident-response/) describes explicit roles, coordination practice and a working response record. This session adapts those practice principles to a different, original delivery exercise; it does not reproduce Google's incident process or claim its endorsement. Reference checked 25 October 2026. The synthetic case, role prompts, timing and exercise are authored by LockedIn Labs.