# Transfer record

An engagement should leave two durable results. One team must operate the solution, and later teams should receive any learning the work supports. This record covers both, because neither should be left implicit.

Source: article three, "Set and verify the operating handoff" and "Turn a local result into useful learning for later teams".

## Who fills this in, and what it decides

The FDE lead prepares part one; the receiving team performs the readiness exercises; the service owner and business workflow owner accept in section 5. The FDE lead prepares part two with the platform product owner, who accepts or declines each shared asset in section 8. The practice lead confirms that the engagement's delivery commitment can close. Transfer happens after the solution operates within its approved scope and before the FDE team closes that commitment.

Roles named in this document:

- Receiving team: the team that will run the released solution after the engagement. It may be a business-technology team, a product team, or a shared service team.
- Service owner: accountable, within the receiving team, for deployment, support, dependencies, and technical change.
- Business workflow owner: accountable for the procedure and the meaning of a useful result.
- FDE lead: owns the delivery evidence until the receiving team accepts.
- Platform product owner: accepts a shared asset, with its maintenance and support obligations.
- Later teams: the shared platform team, or another FDE team working on a related process.

Transfer means demonstrated operating capability: a receiving team with access, time, skills, a recovery route, and funding. A signed record cannot substitute for it.

## Part one: the operating handoff

### 1. Who takes it

- Receiving team:
- Named service owner:
- Named business workflow owner:
- Backup capacity for each:
- Support route:
- Access required, and confirmed on:
- Funding line, from the service allocation in the funding plan:

### 2. The readiness exercises

The receiving team performs each one with the agreed documentation and access, and without the FDE team at the keyboard. The FDE lead records the result; the receiving team records what it needed that was not written down.

| Exercise | Performed by | Date | Passed unaided | What they needed that was not written down |
| --- | --- | --- | --- | --- |
| Deploy a routine change | | | yes / no | |
| Run the evaluation and read a failure | | | yes / no | |
| Inspect an unsuccessful case | | | yes / no | |
| Explain the solution's limitations | | | yes / no | |
| Exercise recovery and manual fallback | | | yes / no | |

Each "no" is a gap in documentation, access, skill, or capacity. Record which, and who closes it, before the transfer date.

| Gap | Kind | Closed by | Date |
| --- | --- | --- | --- |
| | | | |

If the team cannot perform the exercises, leaders change the design, fund capability, extend specialist support, or delay transfer. The practice lead records which.

- Decision if any exercise fails: change the design | fund capability | extend specialist support | delay transfer

### 3. What is being handed over

The approved scope is written as a release: one version, one population, one set of sources, one authority, one review process, one operating arrangement. Any change to one of them is an expansion, which is a new release decision, and the last field names who can make it.

- Approved scope:
- Known limitations:
- Recovery procedure, and the date it was last exercised:
- Who can approve an expansion of scope:

### 4. What stays elsewhere

Some responsibilities may remain with the FDE practice or another specialist service, such as a shared evaluation service maintained centrally. Continuing involvement needs a defined service, capacity, and funding commitment. Otherwise informal requests to the original engineers hide the fact that responsibility never moved.

| Responsibility | Retained by | Defined service and capacity | Funded from |
| --- | --- | --- | --- |
| | | | |

### 5. Acceptance

The handoff is complete when the receiving team can perform the agreed exercises and accepts the defined responsibilities.

| Role | Name | Accepts the responsibilities above | Date |
| --- | --- | --- | --- |
| Service owner | | | |
| Business workflow owner | | | |
| FDE lead | | | |
| Practice lead (confirms the delivery commitment can close) | | | |

## Part two: the learning

Not every observation justifies shared investment. Distinguish what worked locally from what later teams can safely reuse, so that a successful delivery can improve the platform without turning every local decision into an enterprise standard.

### 6. What later teams can reuse from each output

The FDE lead records each output the engagement produced, with its owner and the scope its evidence covers. In the screening specimen, the retrieval component may serve several workflows, the valuation definition applies to one coverage group, and the evaluation collection's structure may generalise while its source material stays restricted.

| Output | Scope it applies to | Owner | Where it lives |
| --- | --- | --- | --- |
| A retrieval or integration component | Several workflows, if its meaning is stable across them | | |
| A domain definition | Usually one coverage group or one policy owner | | |
| An evaluation collection | Its structure may generalise while its source material stays restricted | | |
| A negative finding | The conditions it was observed under | | |

### 7. Proposing a shared improvement

Bring it to the platform product owner with a short evidence note rather than a repository. The product owner can then choose a new component, a product change, or better documentation.

- The repeated problem:
- Affected cases:
- Current alternatives:
- Likely users:
- Operating cost:
- Known limits:
- A failing example, and the decision it blocked:
- Evidence from a second case:

A second adopter is the practical test. Adaptation effort and support demand are better reuse evidence than an import count. In the series, the manufacturing supplier-certification workflow plays this role for source-ownership and effective-date metadata.

- Second adopter, and what it tested:
- Helped without adding contradictory assumptions: yes / no
- Adapting it required embedding local methodology: yes / no
- Verdict: shared investment justified | keep local | split, with the facts shared and the interpretation local

A component can be technically reusable and still impose too much semantic coupling to be a good platform feature.

### 8. Platform acceptance

Acceptance means more than the code. Each row needs a name, or the practice has transferred a repository while retaining the real responsibility. The platform product owner completes it.

| Obligation | Owner | Funded from |
| --- | --- | --- |
| Defects | | |
| Compatibility changes | | |
| Documentation | | |
| Security review | | |
| Usage support | | |
| Future requests from other consumers | | |

- Accepted by the platform product owner, and date:

### 9. Negative findings worth keeping

A finding that a solution was unsuitable affects future decisions and deserves a maintained record. It should explain the conditions, not become an unsupported claim about every possible use of the technology.

| Finding | Conditions it held under | Evidence that would justify reconsideration | Owner |
| --- | --- | --- | --- |
| | | | |

### 10. Continuing cost of the shared assets

Evaluation evidence changes meaning over time: a new policy can invalidate an old label, a new case type can expose missing coverage, and repeated development against the same examples weakens their independence. A shared control depends on conditions that another use must check; an earlier approval is evidence for the new assessment, not authorisation for it. These costs belong in the shared investment decision.

- Evaluation collection owner, and update cadence:
- Conditions a shared control depends on (identity, processing location, classification):
- Who reassesses those conditions for a new use: