FDE Exit: Why Training Completion ≠ Responsibility Transfer — The 4 Drills You Need

Determine Handover Mode Before Discussing Independent Operations

"Customer can operate independently" sounds reasonable but does not apply to all delivery models. If the system is deployed on-premises or in a private cloud and the customer's technical team is responsible for operations, the customer may indeed need to independently release, troubleshoot, roll back, and upgrade. In SaaS or managed services, however, the customer typically should not release platform versions, operate infrastructure, or execute service rollbacks; those responsibilities may long belong to the supplier's platform, SRE, or agreed operations team. The customer needs to independently complete capability enablement, daily use, business confirmation, exception reporting, and manual takeover. Hybrid mode is more common: source systems and business approvals belong to the customer, the AI platform is run by the supplier, and on-site configuration is jointly maintained. There is no single moment when the "customer takes over the entire system." Therefore, before handover begins, the operating mode must be confirmed.

Customer Self-Operated: Customer/business team handles business confirmation, source system responsibility, platform daily operations and changes. Agreed operations team provides product support or upgrades per contract. FDE must prove customer technical team can complete operations and changes within authorized boundaries.

SaaS or Managed Operations: Customer handles daily enablement, business confirmation, exception evidence, manual takeover. Agreed operations team handles platform release, monitoring, troubleshooting, recovery, and upgrade. FDE must prove both parties know trigger conditions, operational boundaries, and escalation paths.

Hybrid Operations: Customer handles source systems, business processes, and on-site configuration. Agreed operations team handles platform, infrastructure, and shared capabilities. FDE must prove every link has a clear owner and cross-boundary faults can be handled continuously.

Operating mode is not a synonym for deployment method. The same private cloud deployment may be managed by the supplier; the same SaaS may leave the customer responsible for source system permissions, business confirmation, and actual outcomes. Handover verification must revolve around real responsibility division, not inference from "where the software is installed."

Handover Gates: Can Each Responsible Party Perform Independently Without the FDE?

The handover gate is not an industry standard but a framework organized by the author around the FDE exit problem. It does not replace contracts, organizational policies, security reviews, or operations specifications; it turns "can leave" into four categories of verifiable evidence.

Category 1: Change

Can the agreed responsible party complete version releases, configuration adjustments, or capability enablement within a controlled process? In self-operated mode, verify the customer technical team can release changes per the approved process and knows change impact, verification methods, and stop conditions. In SaaS/managed mode, platform release remains with the agreed operations team; the customer must prove they can complete tenant-side configuration, capability enablement, and business confirmation — not gain platform release permissions. If a routine configuration change still requires the FDE to log in and execute manually, handover is not complete.

Category 2: Troubleshooting

When alerts, abnormal business results, or tool call failures occur, who judges first, what evidence is needed, and to whom is the problem handed? The operations team must be able to locate common technical issues using alerts, logs, and runbooks; the customer business team must be able to describe the specific business object, occurrence time, expected result, actual result, and manual handling. Both types of evidence must be correlatable, but platform logs cannot replace source system facts, and business descriptions cannot replace engineering diagnosis. If all issues ultimately can only be located by the FDE from memory, no amount of documentation creates troubleshooting capability.

Category 3: Recovery

When the system is abnormal, can the agreed operations team execute rollback, degradation, or shutdown? Can the customer promptly initiate manual takeover and business fallback? Recovery is not just technical rollback. For the exception order Agent, the technical side may roll back model, rule, skill, or tool versions; the business side must know which orders no longer accept AI suggestions, which tasks revert to manual, and which already-issued actions need reconciliation. If rollback scripts exist but no one has rehearsed them, or if the platform recovers but business state remains unknown, the recovery link cannot be proven.

Category 4: Escalation

When first-line handling capacity is exceeded, do all responsible parties know whom to escalate to, what conditions trigger escalation, what evidence to bring, and within what time a response is expected? Escalation is not throwing the problem into a group chat or defaulting to the original FDE. It must at least clarify paths for business owner, source system owner, platform operations team, security/compliance owner, and distinguish general consultation, production incident, security event, and unclosed risks.

The common judgment across these four gates is: If any agreed responsibility can still only be fulfilled by the FDE, the project is in a "half-exit" state. Training headcount, document page count, and reporting satisfaction cannot substitute for performance evidence.

AWS Operational Readiness Review (ORR) similarly emphasizes that operational readiness is not a one-time pre-launch check but should be continuously updated throughout the service lifecycle, covering release quality, incident management, runbooks, monitoring, and rollback mechanisms. This article's handover gates borrow the idea of "verifying operational capability with checkable mechanisms" but target FDE responsibility transfer, not a direct translation of AWS ORR.

Gate reviews cannot end with "basically no problem" in a meeting. Each review must record at least six items: handover responsibility, agreed owner, verification scenario, evidence location, unclosed issues, and confirming authority. For conditional passes, also record temporary measures, validity period, and re-verification time; "will complete later" cannot become an open-ended promise.

The review can only produce four decisions:

Handover Complete: Key responsibilities all verified; FDE can exit as planned.

Conditional Handover: No blocking issues; remaining problems have owners, validity periods, and re-verification arrangements.

Defer Exit: Key responsibilities still depend on FDE; continue drills, complete artifacts, or reduce operational scope.

Enter Abnormal Exit: Project cannot complete normal handover; meet minimum handover standards for responsibility closure, risk transfer, and asset disposal.

None of these four decisions are made unilaterally by the FDE. The FDE provides complete evidence and highlights dependencies but does not grant final approval; handover is confirmed by the corresponding operations or project owner, residual risks are accepted by the authorized risk acceptor, and capability stoppage is decided by the business, system, or governance authority.

Responsibility Transfer Is Not a Single Curve but Four Tracks

Drawing handover as a single curve of "FDE dominance gradually decreasing, customer autonomy gradually increasing" creates a new misunderstanding: as if all responsibilities belonged to the FDE early on and are handed to the customer at exit. Reality is different. At least four tracks of different nature exist.

Customer Inherent Responsibilities: Already held by business, source system, security, or management bodies at project start; continuously perform business confirmation, risk acceptance, and authorization decisions during project; continue to be borne by original authority bodies after FDE exit.

Engineering Responsibilities to Transfer: FDE participates in key design, build, and verification at start; identify handover persons, operate jointly, and complete evidence during project; performed independently by agreed handover persons after exit.

Ongoing Operational Responsibilities: Determined by deployment and service model at start; customer team or supplier operations team continuously bears during project; ownership does not change due to FDE exit.

FDE On-site Responsibilities: Drive issue convergence and personally complete key engineering work at start; verify each responsible party can take over, gradually exit daily operations during project; no longer enter daily operational loops after exit.

The first track could never be transferred to the FDE. The FDE can assist in sorting source system permissions and preparing risk review materials, but cannot approve business actions on behalf of the business owner, accept risks on behalf of security/compliance owners, or write platform operation success as source system final success.

The second track is what needs gradual transfer: on-site configuration knowledge, integration links, verification methods, common fault handling, and agreed change processes. The FDE does not just organize meetings but participates in key build, test, and drills; however, this knowledge and operations cannot remain solely with the FDE forever.

The third track depends on service model. SaaS platform operational responsibility may always belong to the supplier; customer source system always belongs to the customer team. FDE exit changes on-site dependencies, not automatically rewriting contracts and system owners.

The fourth track shrinks as the project progresses. The FDE is deeply on-site and in engineering loops early, drives handover parties to operate jointly mid-term, retreats to review and consulting late, and finally exits daily loops.

Therefore, what handover truly must eliminate is not "FDE's share" but responsibility gaps with no clear owner . A responsibility can be transferred or retained by the original team per contract, but must not be left dangling.

Nine Categories of Operational Artifacts Must Bind Agreed Owners

Independent performance cannot rely only on personnel experience; it needs locatable, executable, verifiable operational artifacts. The author organizes them into nine categories:

Operations Owner: Who is responsible for system, capabilities, and business results; contact and backup mechanisms. Possible owners: customer technical team, platform team, business owner.

SLO: Availability, latency, error budget, or business task service targets; statistical caliber and review cycle. Confirmed jointly by service owner and business stakeholder.

Alerts: What risk each alert corresponds to, who responds, what action to take, how to control noise. Owner: agreed operations team.

Runbook: Diagnostic steps, evidence locations, handling boundaries, and escalation conditions for common issues. Owner: team actually executing the process.

Release & Rollback: Change approval, verification window, rollback or degradation mechanisms, and business reconciliation requirements. Owner: release team and related system owners.

Permission Management: Role permissions, application, review, revocation, and emergency access mechanisms. Owner: customer or platform permission management owner.

Evaluation & Regression: Regression scope and blocking conditions after model, rule, knowledge, skill, and tool changes. Owner: capability owner, quality and engineering teams.

Failure Drills: Drill scenarios, participating roles, observed results, issue rectification, and re-verification records. Owner: operations owner organizes, multi-party participation.

Unclosed Risks: Risk, impact, temporary measures, accepting authority, validity period, and closure conditions. Owner: authorized risk accepting authority.

The nine artifacts do not equal nine independent documents. They can live in monitoring platforms, configuration libraries, evaluation systems, tickets, architecture decisions, and runbooks. The key is each category has a locatable carrier, current version, clear owner, and actual usage evidence.

Operations owner is not a universal responsible person. The platform team may be responsible for service availability, the business owner for task boundaries and actual usage, the source system owner for transaction state. Writing them all as "customer responsible" is as vague as handing them all to the FDE.

NIST AI RMF includes post-launch monitoring, incident response, recovery, change management, and secure decommissioning in continuous risk management, emphasizing that roles and responsibilities must be explicit. For enterprise AI, this means unclosed risks cannot disappear with FDE departure; risks must either be closed, accepted by an authorized body within explicit scope and validity, or trigger degradation, shutdown, or handover stop.

Knowledge Transfer Is Not Last-Week Concentrated Training

The most common handover method is a few training sessions in the final project week and sending the document catalog to the customer. It proves "we lectured," not that the handover party "can do it."

Real knowledge transfer should start early in the project.

Early: Team confirms responsibility boundaries, knowledge carriers, and handover persons. Every key configuration, interface, rule, evaluation, and operational decision must retain source, version, and owner, avoiding knowledge existing only in chat logs or an engineer's laptop.

Mid-term: Handover parties begin joint operations. FDE demonstrates once, then handover personnel complete under FDE observation, then enter a phase where FDE does not directly operate but intervenes only at trigger boundaries. Every change, fault, and retrospective must reverse-update runbooks, evaluation sets, and escalation paths.

Late: Verify true independence through drills:

Self-operated mode: Customer technical team completes a release, verification, and rollback drill within an approved window or controlled environment.

SaaS/managed mode: Agreed operations team completes platform-side troubleshooting and recovery drill; customer completes capability enablement, business exception reporting, and manual takeover drill.

Hybrid mode: Both sides complete a cross-boundary fault drill, verifying evidence can connect from business object to platform logs back to source system final state.

Drills are not to create production risk. No need to deliberately destroy real business to prove rollback; can be done in controlled environments, approved windows, or risk-reviewed fault injection. But drills must produce actual evidence: who operated, which runbook used, where they got stuck, what permissions needed, how to escalate after failure.

Judging whether knowledge transferred does not look at whether training materials are complete, but whether the handover party can complete tasks matching their responsibilities without FDE proxy operations.

Who Takes the Exception Order Agent?

Returning to this article's synthetic case. The exception order chain identifies potentially delayed orders, reads order, contract, and fulfillment info, generates handling suggestions, confirmed by authorized personnel, then source system completes status write-in. Previous articles discussed on-site evidence, business model, architecture boundaries, controlled loop, Agent access, and production gates.

Entering handover phase, cannot simply write "system handed to customer." At minimum, responsibilities must be split:

Business department maintains exception order judgment boundaries, confirmers, and manual handling paths.

Source system owner continues to own order status authority, write permissions, and final receipt.

Agreed operations team maintains Agent service, monitoring, alerts, version release, and rollback.

Capability owner maintains rules, prompts, skills, evaluation sets, and applicability scope.

FDE drives these responsibilities to form verifiable connections and verifies the chain still runs without them.

If using customer self-operated, the customer technical team must also take over Agent service release and troubleshooting. If using SaaS, platform operations remain with supplier; customer does not need infrastructure permissions but must independently complete tenant configuration, business confirmation, exception evidence submission, and manual fallback.

A handover drill can be designed: modify a non-high-risk configuration, trigger regression evaluation and complete controlled release; inject a tool timeout, verify alert, degradation, and escalation path; select a synthetic exception order, verify business personnel can confirm or reject suggestion; finally simulate Agent unknown state, check if it stops repeated actions and enters manual reconciliation. These are method demonstrations, not production effect proofs. Without real operational records, cannot claim a customer has completed handover.

Even If Project Cannot Handover Successfully, Exit with Engineering Dignity

Not all projects reach normal handover. Budget cuts, business direction changes, technical route overturns, organizational changes, or partnership breakdowns may force early FDE exit. Cannot forge an "acceptance completed," nor leave unclosed risks in place because the project stops. Abnormal exit's goal is not to prove success but to guard three minimum standards: Responsibilities not dangling, risks not abandoned, assets disposed per agreement.

At minimum, handle five categories:

How to maintain running capabilities: Which capabilities continue, which degrade or stop, current owner, temporary measure validity.

How to transfer unclosed risks: Record risk impact, known evidence, mitigation measures, accepting authority, validity period, and follow-up decisions; do not use "under observation" to mask no one responsible.

How to handle code and operational materials: Clarify handover scope of source code, configuration, build methods, runbooks, evaluation assets, and known limitations; do not write "files sent" as "runnable."

How to rotate and reclaim credentials: Confirm ownership of accounts, certificates, tokens, and emergency access; complete rotation, revocation, or reclamation. Abnormal exit especially must not pass personal credentials directly or retain unnecessary production access.

How to handle data and IP: Per contract and approval basis, handle customer data, logs, model and Agent assets, on-site knowledge and copies; clarify return, retention, deletion, and proof methods.

Normal and abnormal exit criteria differ. Normal exit requires each handover party to independently perform agreed responsibilities; abnormal exit's minimum requirement is to place existing systems, risks, permissions, and assets back into clear boundaries. Neither can be unilaterally declared complete by the FDE; relevant owners and authorized bodies must confirm based on shared evidence.

FDE's Final Responsibility: Make Daily Operations No Longer Depend on Themselves

In the exit phase, the FDE is not a bystander. They must drive early establishment of handover mode, responsibility tracks, operational artifacts, and drill mechanisms; personally participate in key build and verification; and transform on-site dependencies into clear owners, executable processes, and auditable evidence.

But this responsibility has a clear ceiling:

FDE cannot operate production systems long-term for customer or agreed operations teams.

FDE cannot accept risks or confirm final results on behalf of business, security, compliance, and source system owners.

FDE cannot treat "no recent incidents" as handover success.

FDE cannot substitute one-time training for continuous capability, nor temporarily operate for handover parties just to pass gates.

FDE cannot take customer assets, retain unnecessary permissions, or discard unclosed risks during abnormal exit.

Training completion does not equal permission to leave. True exit is when each agreed responsible party, without FDE accompaniment, can still independently perform within established boundaries; responsibilities that should transfer have transferred, responsibilities that should not transfer remain with original owners, and ongoing operational responsibilities are not left dangling because the FDE left. Only then does the FDE's responsibility for "from problem to production" truly close the loop.

Article 08 answered how to complete responsibility transfer and handover. The next article will continue: how knowledge, configuration, failures, and improvements from a single on-site delivery feed back into product and platform, rather than staying in a single customer project.

References

AI Pilot to Scale: Replicating Not the Agent but the Verified Capability Package (WeChat article)

Trustworthy AI Is Not Adding a Review: It's Building a Continuous Operational Governance System (WeChat article)

AWS: Operational Readiness Reviews

AWS Well-Architected: Use Runbooks to Perform Procedures

Google SRE: Production Readiness Review

NIST: AI Risk Management Framework Core

Agent Calling Tools Is Not Enough: How FDE Connects AI to Data, Permissions, and Real Processes (WeChat article)

Function Launch ≠ Value Proof: How FDE Uses Production Gates and Value Metrics to Prevent False Success