# Service handoff rehearsal Planned hypothetical exercise. **Current disposition: blocked. All demonstrations: not run.** This sheet records the proposed rehearsal, not a runnable service or completed transfer. Read [The pilot works. Can anyone else run it?](https://caisi.dev/notes/ai-service-handoff/). ## Proposed scope and people The teaching service collects invoice facts and prepares a correction for review. To let it post a correction to a ledger, the system owner would need separate permission and evidence that the receiving system checks approvals, prevents duplicate changes, and confirms the saved result. Taking ownership of the repository grants none of that permission. | Role | Proposed responsibility / limit | | ------------------------------- | ---------------------------------------------------------------------------------------------------- | | Accounts-payable workflow owner | Decide which invoices belong and what a correct result requires; cannot waive policy | | Receiving service owner | Own incoming work, incidents, support, budget, and the next review | | Receiving engineer | Lead permitted changes, tests, investigation, and restoration of the previous version | | Qualified backup | Run the service without depending on the original builder | | Finance controls approver | Check expected answers against source records and approve policy decisions separately where required | | Release authority | Decide whether the tested version may go live or must stay on hold | Actual individuals, access, dates, and agreement remain unconfirmed. A retained internal service can use its own backup rather than invent an organizational transfer. ## Proposed reservations and safe boundary Receiving engineer: 120 minutes. Backup: 60 minutes. Controls approver: 30 minutes. Release authority: 30 minutes. These are reserved planning assumptions, not measured durations. Split or stop if time expires. Use a permitted non-production environment. Inspect where tools actually connect and which credentials they use; prevent unintended external changes and name who can stop the exercise. Keep the current code and settings, the previous compatible version, source and policy versions, runbooks, alert contacts, and recovery records available. Never borrow the builder's account. ## Exercise record For the evaluation-case exercise, the receiving engineer adds a permitted invoice exception and a request that must be refused for lack of permission. A separate qualified approver checks the expected answers against the invoice and policy. The engineer then supplies a deliberately wrong result to the grader, the software that checks outputs, and confirms that it rejects the result. Record what each person actually did and any help from the builder. This is a proposed sequence, not a completed demonstration. | Exercise | Current evidence / acceptance requirement | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | | Explain scope and limits | Not run; receiving owner identifies permitted and prohibited actions | | Add evaluation case | Not run; save the exception, unauthorized-request case, separately checked answers, and rejection of the bad result | | Prepare bounded change | Not run; save the exact version, affected decisions, test and compatibility results, and decision to release or hold | | Restore baseline | Not run; restore compatible code and settings, then check the result in the permitted environment | | Respond to alert | Not run; reach the responsible person, stop new work when required, and assign pending cases | | Reconcile lost receipt | Not run; use the original operation ID and permitted receiving-system records to settle the result; keep unknown results on hold | | Support operator | Not run; record who responds, which team must repair the problem, and the next action | | Review and retire | Not run; review value and cost, then cover access, schedules, pending work, retained records, users, and the replacement process | Record each original-builder intervention and its reason. Safe intervention is allowed; it prevents claiming that step was independently demonstrated. Restoring software does not undo a business effect. ## Separate hypothetical 28-day operating allocation These assumptions belong only to this planning example. USD throughout. | Category | Calculation / allocation | | -------------------------------------------------- | ------------------------------------------- | | Receiving-engineer support | 6 hours × USD 75/hour = USD 450 | | Backup support | 2 hours × USD 75/hour = USD 150 | | Operator support | 4 hours × USD 40/hour = USD 160 | | Labor subtotal | USD 760 | | Infrastructure and tooling | USD 180 | | Routine assurance outside the reserved labor hours | USD 160 | | Proposed period allocation | USD 1,100 | | Sensitivity: four additional engineer hours | USD 300 extra; revised allocation USD 1,400 | Labor allocation is not necessarily new cash spending. The routine-checking amount excludes work already counted above. Benefits, complete workflow cost, business loss, accepted volume, and whether the service fits its cost limit remain unknown. No return on investment is calculated. Compare reserved and recorded costs at the next review, including hidden builder work and work shifted to operators. ## Proposed disposition Handoff stays blocked. The receiving service owner must confirm actual people, access, availability, and exercise dates. Propose the next review for the end of an agreed 28-day operating period; no meeting has been booked. If the builder provides temporary support, agree what it covers, who requests it, the maximum hours, when it ends, and which later changes could justify a new job. This worksheet does not authorize the builder's exit or a production release. ## Blank target record ### Start with these questions 1. Who will own the service and cover their absence after the builder leaves? 2. Can those people perform a permitted change, test it, and restore the previous version without borrowing the builder's account? 3. Who handles an alert, a pending case, or a change whose result is unknown? 4. Which missing demonstration keeps the handoff blocked? ### Record what the receiving team demonstrates | Question | Record from your permitted environment | | ------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- | | What may the service do, and is it currently permitted to operate? | Record | | Who is the receiving owner or retained team, and who is the qualified backup? | Record | | Who separately approves policy decisions and production releases? | Record | | Which access and non-production environment are permitted? How are unintended external changes prevented? | Record | | Who can stop the exercise? | Record | | Which exact code and settings will be tested, and which previous compatible version can be restored? | Record | | Who performed each exercise, what evidence was saved, and where did the builder help? | Record | | Which changes have uncertain results, what can the source system confirm, and who investigates the rest? | Record | | How much support and review time is available, with what cover during an absence? | Record | | Which budget period, cost categories, assumed rates, actual costs, and exclusions apply? | Record | | How much work was accepted in that same period, and how much operator effort did it require? | Record | | What blocks handoff, who resolves each gap, on which agreed dates, and when is the next service review? | Record | | If temporary builder support is proposed, what work, maximum hours, and end date are agreed? What later change could justify bringing the builder back? | Record | | Should the service continue, be limited, be repaired, stop, or have its handoff accepted? Who may decide? | Record | Keep private identities, customer evidence, credentials, and restricted destinations in approved systems, not in a public copy of this sheet.