Every FDE engagement needs an exit test
A deployment is not finished when the demo works or the FDE leaves. It is finished when a named customer operator can run the production system, diagnose it, escalate it, and improve it without renting the original team's memory.
Why the handoff belongs in the design
AWS makes customer self-sufficiency an explicit property of its FDE model. Its official announcement says customer engineers progress from observers to co-builders to autonomous operators, leaving with deployed systems, runbooks, architectural documentation, trained internal champions, and codified expertise.
OpenAI's Technical Deployment Lead role describes the other side of the same operating contract: delivery plans need milestones, dependencies, acceptance criteria, adoption work, reusable patterns, and measurable customer value. Together, those sources support a practical conclusion: handoff is not a final documentation sprint. It is a production requirement that should shape the engagement from the start.
Source-backed facts, practical synthesis: AWS names self-sufficiency and durable artifacts directly. OpenAI names acceptance criteria, adoption, reliability, and reusable patterns. The six-gate exit test below is FDE Brief's operating checklist built from those public role definitions.
The six-gate FDE exit test
1. Production owner
A named customer-side owner accepts the system. They have decision rights for normal operation, maintenance, access, and change—not just a place on the stakeholder list.
2. Observability
The operator can see whether the workflow is healthy. Logs, evals, alerts, dashboards, and business-level signals expose failures without requiring the embedded team to reconstruct context.
3. Runbook
Routine failure and recovery paths are written down. The runbook covers expected faults, rollback, safe degradation, access boundaries, and the first diagnostic steps.
4. Trained operator
The customer proves operation through a rehearsal. A handoff meeting is not enough. The future operator should execute a normal release, diagnose a seeded fault, and recover or escalate it.
5. Escalation path
Novel failures have owners and response boundaries. The team knows what stays with the customer, what returns to the product vendor, what requires security or governance review, and how urgency is communicated.
6. Reusable signal
The field lesson survives the engagement. Repeated constraints become an eval, component, platform request, architecture pattern, or explicit product hypothesis—not folklore held by the departing FDE.
How to test the handoff
- Remove the original FDE from the operating channel for a rehearsal window.
- Ask the named owner to run a normal release or workflow change.
- Introduce one known failure and verify that observability points to the runbook.
- Introduce one unknown failure and verify that the escalation path works.
- Review which engagement lesson became a reusable artifact or product decision.
If the rehearsal fails, the correct response is not to hide the gap with more embedded support. Reopen the failed gate, assign an owner, and repeat the test.
Three false exits
- The demo exit: the happy path works, but production ownership and failure handling remain undefined.
- The document exit: artifacts exist, but no customer operator has demonstrated that they can use them under pressure.
- The availability exit: the engagement formally ends, but the original FDE remains the default operator through an informal support channel.
Sources
- AWS: $1 billion investment in forward deployed AI engineers
- OpenAI: Technical Deployment Lead, Forward Deployed Engineering
- FDE Brief 30-day KPI and Search Console reports generated 2026-07-23.
The question
Which exit gate is most likely to pull your FDE back into a deployment that was supposed to be finished?
Get the next FDE operating checklist
Weekly field notes for engineers and operators building customer-owned production systems.