FDE field-change drill: defend the next delivery decision

A one-page change decision, a revised case row, and a two-minute receiving-team briefing. Your evidence must distinguish supplied observations from anything you actually execute. Full worked interpretations and reviewer calibration guidance are in the Academy client-delivery capstone under existing access.

Resources:

• Workbook: https://training.lockedinlabs.ai/templates/fde-client-delivery-workbook.md
• Starter: https://training.lockedinlabs.ai/templates/fde-client-delivery-starter.mjs
• Course: https://training.lockedinlabs.ai/app/academy?course=fde-client-delivery&lesson=cohort-delivery-capstone&view=focus

Your service supports one authorized location and three administrative categories. It retrieves one current procedure and proposes a draft. The operator decides whether to use it. Missing or conflicting support requires manual handling. The starter is a scripted, local implementation with no sending capability.

Run the existing starter if you have not done so. Save its output with the file revision and scenario name. Do not rerun every scenario simply to fill time. Choose one card below. In a pair, the receiver selects the card after the builder has explained the baseline; the builder may ask factual clarification questions.

At the same authorized location, the procedure catalog now contains both:

Both records have tenant-a and location-a. The procedure owner has not yet confirmed which instruction applies. The sponsor says: “Pick version four; newer must be better. The demonstration starts in ten minutes.”

Your task: State the immediate user-visible behavior, who resolves the source conflict, and the smallest change you can defend. Explain what a higher version number establishes and what it does not establish.

Optional local implementation: copy the starter, add the second record to its procedures array and run supported. Preserve the original file. Record what actually happened and which stage stopped. Do not silently filter out version three solely to make the demonstration pass.

This is a supplied tabletop sequence, not behavior observed in the starter:

The proposed implementation checks location access only when a request starts. Its UI accepts whichever response arrives last. It has not connected a sender.

Your task: Draw the ordering of authorization, provider dispatch, revocation, manual state and result delivery. Name where fresh authority and request state must be checked. Explain why cancellation alone is insufficient evidence that a remote result cannot return, and what revocation cannot retroactively undo.

Do not claim to execute this card with the existing starter: its actor is fixed, its adapter is scripted, and it has no browser or real identity lifecycle. Write an expected case for a future implementation with a controllable pending adapter and an access change. Mark it “expected, unexecuted” until implemented and run.

Supplied synthetic active handling times for six matched requests, in minutes:

The first four assisted tasks were accepted with little correction. The last two needed fallback after confusing source guidance. All six tasks completed. Queue waiting, engineering effort and service cost are not included in these figures. The sponsor points to the first four rows and asks for an organization-wide productivity claim.

Your task: Calculate total effort, median effort and per-request paired change (manual minus assisted). Identify how the conclusion changes if you report only the median or omit fallback rows. Recommend a next comparison and describe what would falsify your hypothesis. Do not extrapolate six supplied cases to a staffing reduction, revenue projection or measured customer result.

Use this decision sheet. Keep the immediate operating decision separate from the next engineering increment.

Card / candidate revision / adapter mode:
What changed from the baseline:
Supplied facts and unresolved questions:
Affected user and consequence:
Immediate operating decision and authorized decision role:
Smallest proposed change (including what stays outside this slice):
Evidence already available, with supplied/executed/expected labels:
Next case: input -> expected state -> prohibited effect -> observation:
Evidence that would change the decision:
Receiving role, next action and fallback:

For Card A, record before/after traces if you execute the fixture change. For B, submit the event ordering and expected case instead of fabricated output. For C, show the arithmetic and retain every row. A correct outcome with a wrong explanation is still a learning gap.

The receiver asks one question from each audience. Rotate who asks; a solo learner records their own answers and labels the exercise self-reviewed.

• Executive: What can the team safely continue doing today, and what decision do you need from me?
• Technical lead: Show the exact boundary or observation supporting that choice.
• Receiving engineer: What do I do if your proposed increment fails?
• Operator: Where is the useful next action when no draft is available?

The receiver must restate the recommended scope and demonstrate or describe the manual next action without the builder completing the answer. Record a missed step as a gap. Revise that part of the packet; do not substitute presentation confidence for receiving-team understanding.

Record the original decision, the receiver's challenge, your revision and the remaining uncertainty. Submit through the existing capstone artifact workflow if you have Academy access, or retain the packet locally for facilitated review. Do not include secrets or real customer information.

A useful self-review asks whether the evidence supports the decision, whether failed and pending cases remain visible, and whether the receiving team has an immediate useful action. A peer discussion is practice feedback; it is not a provider credential, hiring decision or independent qualification.