# Workflow handover checklist

Outre | Reference template | 10 October 2026

Use this checklist to agree when a workflow is ready to change hands. Adapt it to the consequences of the work. A completed checklist is not a security certification, a compliance assessment, or proof of production readiness.

You may use and adapt this template in your own work. This permission applies to this template, not to other Outre code or client material.

## Handover record

- Workflow: [name]
- Purpose and intended users: [description]
- Implementation version or reference: [link]
- Business owner: [name]
- Day-to-day operator: [name]
- Technical maintainer: [name or team]
- Approver for consequential changes: [name or role]
- Acceptance date: [date]
- Next review: [date or trigger]

## Scope and authority

- [ ] Inputs, outputs, and the condition for a completed run are documented.
- [ ] The authoritative source for each important business record is identified.
- [ ] Allowed actions, prohibited actions, and approval requirements are explicit.
- [ ] Known limitations and unresolved risks are recorded.
- [ ] A manual alternative is documented where continuity requires one.

## Access and dependencies

- [ ] The receiving team has tested its own access, not the builder's credentials.
- [ ] Account owners and billing owners are identified.
- [ ] Permissions are limited to the job and approved by the responsible owner.
- [ ] Credentials are stored through an approved process, never in this checklist.
- [ ] Connected services, renewal dependencies, and recurring costs are documented.
- [ ] The process for removing the builder's access is agreed.

## Normal operation

- [ ] A representative case has been completed by the receiving operator.
- [ ] Expected output has been checked in the destination system.
- [ ] The team knows where to find run status and relevant evidence.
- [ ] Input validation and handling of incomplete information are documented.
- [ ] The operator can distinguish completed, failed, and untouched work.

## Exceptions and recovery

- [ ] A realistic failure has been rehearsed with approved sample data.
- [ ] The operator knows when to retry, escalate, or stop.
- [ ] Uncertain outcomes are checked before an action is repeated.
- [ ] Duplicate prevention has been tested where relevant.
- [ ] Partial failures across connected systems are visible.
- [ ] A disable procedure is available and has been tested safely.
- [ ] Recovery, rollback, or compensating action is defined where feasible.
- [ ] Logs do not unnecessarily reproduce confidential inputs or credentials.

## AI-assisted steps, when applicable

- [ ] Model, prompt, and relevant configuration versions are recorded.
- [ ] Retrieval inputs cannot expand the agent's permissions.
- [ ] Consequential writes are authorized by the application, not only a prompt.
- [ ] An approval is tied to the exact action and is rechecked if the proposal changes.
- [ ] Missing evidence and ambiguity can produce no action.
- [ ] Representative tests cover contradictions, permission failures, and unavailable tools.
- [ ] Sensitive evaluation data stays in an approved location.
- [ ] Manual review or another fallback is available when output is not trustworthy.

## Outcome and operating cost

- [ ] A successful completed case is defined and counted, not inferred from an API success response.
- [ ] Handling time, errors, and unresolved exceptions have a baseline or an explicit measurement plan.
- [ ] Human review and correction effort are recorded alongside automated work.
- [ ] Recurring model, service, integration, and maintenance costs have an owner.

## Routine change

- [ ] The receiving operator has rehearsed one routine change without the builder leading.
- [ ] Configuration and documentation locations are known.
- [ ] Changes that require technical support or fresh approval are identified.
- [ ] A test procedure exists before changes reach live work.
- [ ] The owner of future documentation updates is named.

## Acceptance and continuing support

- Normal-run evidence: [link or reference]
- Failure-rehearsal evidence: [link or reference]
- Routine-change evidence: [link or reference]
- Baseline and completed-case evidence: [link or reference]
- Remaining limitations: [description]
- Risks accepted, by whom, and until when: [record]
- Stabilization or support arrangement: [scope, route, and dates]
- Changes requiring a new scope: [description]
- Accepted by the receiving owner: [name and date]

For corrections to this template, use the contact form at https://outretechnology.com/contact. This reference resource has no service-level commitment.