Lead a client-delivery pod: facilitator session pack

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.

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.

Download the offline Node.js starter. 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.

Builder runs the original candidate:

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:

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.

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:

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.

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.

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:

Continue with the client-delivery capstone under existing Academy access. It connects this rehearsal to discovery, implementation, evaluation, recovery and the complete receiving-team packet.

Google's SRE 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.