Mission 10 · Operate and transfer

Transfer ownership and learning

Prove the accountable operating team can support, evaluate, change, recover, and retire the service before the delivery team steps back.

Self-directed lesson

Field question: Can the operating team exercise every capability needed to own the service without hidden dependency?
Working artifact: Enablement handoff + learning record
Effort: 2 hours

You will learn

Why documentation alone is not operating capability.
How exercises prove support, evaluation, change, incident, rollback, and retirement readiness.
How to sanitize recurring field learning before productizing it.

Field practice

Name the service owner and exercise support, evaluation, change, incident, rollback, and retirement paths.
Record gaps, owners, evidence, and the explicit delivery-team exit condition.
Separate customer-specific context from reusable product or practice learning.

Before you begin

Bring the service contract, runbooks, release evidence, current risks, support model, change process, and named operating team.

Learning objectives

Prove the operating team can support, evaluate, change, recover, and retire the service.
Define explicit delivery-team exit conditions and remaining dependencies.
Sanitize reusable field learning without leaking customer context.

Core lesson

What you need to know

Transfer capability, not documents

A handoff is complete when the accountable operating team can exercise the service's critical capabilities without hidden delivery-team dependence. Name the service owner, support roles, escalation authority, change approvers, evaluation owner, incident commander, and retirement authority. Documentation supports those roles; it does not prove them.

Run exercises for normal support, evaluation regression, configuration or model change, incident containment, rollback, restore, access revocation, cost breach, and retirement. Capture who acted, what evidence they used, where they hesitated, and which gaps remain.

Make exit and support explicit

Define the delivery-team exit condition, warranty or support boundary, unresolved risks, ownership acceptance, and next service review. Do not manufacture customer dependence. If the operating team cannot safely own the service, record the gap and extend or constrain the transition rather than declaring handoff complete.

Confirm access, credentials, dashboards, alerts, runbooks, repositories, vendor relationships, cost controls, and data responsibilities transfer to authorized owners. Remove temporary delivery access when the transfer condition is met.

Productize learning safely

Separate customer facts from reusable patterns. A field-learning record should state the recurring problem, evidence across engagements, proposed reusable capability, confidentiality treatment, owner, validation path, and decision to productize, configure, document, or leave customer-specific. One anecdote is a lead, not a platform mandate.

Worked field case

Transferring the denial service

The customer teams are exercising operation of the constrained rec-0.4.3 service, but transfer evidence is incomplete.

Evidence available

The operating owner records constrain from the service review; the evaluation owner reruns the modifier-exception regression after a policy update.
The support team has diagnosed a simulated stale-policy incident, disabled recommendations, and exercised staging rollback and queue reconciliation.
Retirement and data disposition remain tabletop, and two temporary delivery credentials are still active until their documented revocation date.

Reasoning path

Distinguish exercised support, evaluation, change, incident, rollback, and queue recovery from the retirement steps that remain tabletop.
Record remaining gaps and constrain exit until the operating team closes the non-waivable ones.
Sanitize the modifier-exception learning into a general policy-versioning pattern without payer or customer data.

Result

Exit remains conditional: several operating capabilities are exercised, but retirement/data disposition and temporary access must be closed or explicitly retained within an accepted support boundary.

Practice exercise

Prove an accountable handoff

Use live field evidence, a sanitized retrospective, or synthetic practice to test whether the receiving team can operate the service without the builders. Synthetic work demonstrates the exercise design, not real operating ownership.

Name all operating, support, evaluation, change, incident, rollback, and retirement owners.
Exercise at least one normal, one failure, and one change scenario.
Record access transfer, remaining risk, support boundary, and delivery-team exit conditions.
Create one sanitized field-learning record and choose its reusable disposition.

Keep

An enablement handoff and field-learning record backed by exercised evidence.

Review your work

Field rubric

Named owners can perform critical actions without hidden builder access.
At least one recovery path has been exercised by the receiving team.
Exit conditions and residual dependencies are explicit.
Reusable learning contains no customer-confidential context.

Complete when

The operating team has demonstrated support, change, recovery, and retirement capability.
Temporary access and delivery dependencies have disposition dates.
The reusable learning decision has evidence and an owner.

Check your understanding

Could the team diagnose, contain, recover, and safely retire the service tomorrow without the delivery team?

Working template

Download the mission artifact, complete it with source evidence, and review it against the rubric above.

Download Enablement handoff + learning record template

Guided study and progress

Open this mission in the guided school to confirm the exercise and rubric, save completion in this browser, and resume the ten-mission path.

Open guided mission

Compare and go deeper

This lesson is self-contained. Compare your work with the calibrated answer, then use the attributed references when you need governed detail or additional implementation practice.

Annotated answer FDE Guide reference ↗Attributed technical depth ↗