Public course previewThis is not your assigned passport. No identity, answers, or completion progress are stored here.How to start your passport
Handbook / labs

labs

Lab: Project Handover

A project handover transfers approved code, data, access, setup, and operational knowledge to another authorized person. It must work without the departing person's computer, private account, or chat history.

Goal: enable another authorized researcher to reproduce, continue, and archive the project without your personal machine or chat history.

Prerequisites: the project's code, environment, storage, and information owner are known.

Execution context: work in the project repository and approved storage. Do not copy secrets into the handover packet.

For the assessed fictional exercise, follow the Passport lesson. This companion supports private project planning; its extra packet/map is not another public submission. Keep real people, paths and records private.

Required Handover Packet#

Project purpose and owner:
Repository and default branch:
Setup/environment command:
Test or smoke command:
Representative run command:
Source-data owner and location:
Working-data location:
Final results and checkpoints:
Temporary data safe to delete:
Access groups/services:
Known limitations and failed approaches:
AI assistance/disclosure requirements:
Retention and next review date:

Reproduction Check#

Ask another authorized person, or use a clean environment, to:

  1. clone the repository;
  2. create the declared environment;
  3. run tests or a small smoke check;
  4. locate approved data without receiving a secret in chat;
  5. identify the command and resources for a representative run;
  6. locate final results and identify which copy is the main approved copy.

Record failures as documentation defects and fix the instructions.

Access Cleanup#

The supervisor or system owner decides which access remains. Revoke temporary tokens, remove obsolete guest/collaborator access, transfer service ownership, and preserve only credentials through approved ownership mechanisms. Never hand over a personal password or private key.

Verification#

  • Repository status is clean and required commits are pushed.
  • Tests/smoke check run from declared setup.
  • Durable and temporary storage are explicitly distinguished.
  • The next owner can find required files and results without personal-path assumptions.
  • No secret appears in documentation or history.

Common Failures And Safe Recovery#

  • Only one environment works: recreate it from declarations and document missing system dependencies.
  • Results depend on an unknown checkpoint: identify provenance before claiming reproducibility.
  • Data exists only in personal or temporary storage: transfer and verify it with the information owner.

Understand Before Accepting AI Output#

  • Another person performed or reviewed the reproduction check.
  • The agent did not invent commands, paths, results, or access rights.
  • I can identify the main approved copies of required files and results.
  • Personal credentials are not part of the handover.

Evidence#

Review the real packet, reproduction result and authorized reviewer privately through the project owner's approved destination. Never put these real identities, paths or records in the public Passport. Its fictional exercise checks bounded fields and does not execute the example reproduction command.

Ask For Help When#

Ownership is disputed, required data cannot be located, an external account is personal-only, or access cannot be transferred safely.