Outcome#
Project ownership transfers to an authorized successor, required records remain recoverable, temporary copies are handled deliberately, and unnecessary access is revoked without destructive improvisation.
Concept#
Departures create data-loss and lingering-access risk when handover starts after accounts expire. Offboarding must distinguish project records from disposable copies and preserve incident or retention obligations.
Worked Example#
Operational actions have named owners and dates, and no project asset depends on the departing person's private account or storage.
A correct example uses these decisions:
- Choose the safe high-level offboarding order. Inventory and transfer ownership. -> Verify durable data, code, and documentation. -> Rotate shared credentials and remove access. -> Record completion and remaining retention decisions.
- What must be removed from the project? Dependencies on the departing person's private accounts, laptop, and undocumented knowledge.
Common Trap#
Removing accounts before transferring ownership, or assuming that access revocation also archives project knowledge.
If Blocked#
Preserve data and access state while ownership or retention is unclear. Do not perform broad deletion to “clean up.” Use the project handover lab and escalate to the relevant owner.
Useful references:
Understand Before Accepting AI Output#
An agent cannot approve deletion, retention, ownership transfer, or access revocation. The named owner of each system must confirm its own action.