# Close a GPU Pilot with a Data Cleanup Record

Close a GPU pilot with an agreed data inventory, cleanup evidence, separate access withdrawal and clear limits on what was verified.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/gpu-disk-cleanup-evidence/
Language: en

Close a GPU pilot with a record of the agreed data locations, cleanup actions, responsible people and unresolved exceptions. Saying everything was deleted is less useful than identifying what was checked. A folder's absence does not prove that all backups or physical storage blocks were erased.

This matters when the server returns to researchers or another operator. Prepare the completion rules before work begins, while the purpose of each dataset is still clear.

## Map the storage boundary

Identify inputs, model weights, download caches, outputs, logs and backups. Assign an owner and completion rule to each. Public weights and private project documents may need different treatment.

Docker volumes have a lifecycle separate from containers. Stopping or removing a container is therefore not automatic evidence that all its data has been cleared. Inspect the actual storage arrangement instead of relying on the application label.

## Use a completion matrix

| Object | Decision before completion | Evidence afterwards |
| --- | --- | --- |
| Source documents | Return or clear as agreed | Inventory and responsible person |
| Outputs | Deliver to their owner | Destination and confirmation |
| Temporary volume | Remove if authorised | Identifier and checked status |
| Diagnostic log | Retain a defined subset | Contents and retention period |
| Backup | Apply a separate rule | Location and decision |
| Operator key | Withdraw access | Account and time |

This is a record format, not a set of destructive commands. Do not include secrets or confidential filenames in a public handover summary.

## Check access separately

Cleanup and access revocation address different things. A valid key may still allow a former operator to connect; withdrawing it does not erase stored files or describe existing sessions. OpenSSH's sshd documentation explains key authorisation and its options.

Record the changed access configuration, agreed session closure and the owner's verification. Private keys do not belong in evidence packages. Keep any unexplained management access path listed until it has a responsible action.

## State the limits of the evidence

An empty directory establishes that directory's observed state at a particular time. It does not establish secure physical erasure, external backup deletion or the absence of an earlier export. If another assurance level is required, agree on its procedure with the data and equipment owners.

Record exceptions openly with the next action. Compare the final state with the initial pilot record so temporary permissions and storage paths are accounted for.

Continue with [GPU Operator Handover: Issue and Revoke Access Keys](/journal/gpu-operator-key-handover/) and [Return a GPU to Its Research Window](/journal/gpu-research-window-handover/).

## Official references

- [Docker — volumes](https://docs.docker.com/engine/storage/volumes/)
- [OpenSSH — sshd](https://man.openbsd.org/sshd)