Baton

01

In plain English

What it is

A structured project handover that shows the next owner what is still open and what they are taking responsibility for.

How it works

The outgoing owner would prepare open tasks, pending decisions and required files. The incoming owner checks access and recent changes, then explicitly accepts the current handover.

Why it matters

To make responsibilities and missing information clear before the previous owner steps away.

02

The working model

A handover is a decision against a current package of responsibilities. Sharing a folder does not record that decision.

The boundary that matters Project responsibility and external file access are separate. Accepting a handover does not transfer Drive ownership.

03

How it fits together

A person acts, the system checks, a result follows — and one other path, for when the check does not pass. This describes proposed responsibilities and decisions, not deployed infrastructure.

%% Director-friendly architecture. Maturity and limits are recorded in accDescr.
flowchart TB
  accTitle: How Project Baton works
  accDescr: The current project owner prepares outstanding work and decisions for handover. Signal checks recent changes and the incoming owner’s file access. The incoming owner reviews and explicitly accepts the current responsibilities before the transfer is recorded. Gaps leave the handover pending with the current owner still responsible. External Drive ownership does not transfer. This is a proposed concept.
  A(["Current owner<br/>Prepares the handover"])
  B("Handover package<br/>Open work and decisions")
  C{"Details current<br/>and files accessible?"}
  D(["Incoming owner<br/>Accepts the responsibilities"])
  E("Project responsibility transferred<br/>Acceptance recorded")
  X("Handover pending<br/>Current owner remains responsible")
  A --> B
  B -->|Check file access| C
  C -->|Ready| D
  D -->|Accept current details| E
  C -->|Changes or gaps| X
  classDef human fill:#faf7f2,stroke:#bf8c53,color:#24211c;
  classDef work fill:#ffffff,stroke:#a3a5ad,color:#25262a;
  classDef decision fill:#f3efff,stroke:#967bcb,color:#30244c;
  classDef result fill:#f0f6ff,stroke:#7b9dca,color:#1d365b;
  classDef exception fill:#fff5ec,stroke:#ce9b63,color:#64431e;
  class A,D human;
  class B work;
  class C decision;
  class E result;
  class X exception;

04

The case study

A handover is complete when responsibility is understood and accepted, not when a folder is shared.

Responsibilities

State snapshot

Responsibilities, pending decisions, and known access gaps.

Change review

Identify mutations since the handover was prepared.

Acceptance record

Incoming owner acknowledges the current transfer scope.

The boundary

Signal Studio ownership does not transfer ownership of external Drive files. Provider access and project responsibility must be checked independently.

The trade-off

Freezing all work would simplify acceptance but interrupt the project. A changing project instead needs clear deltas and a final revision check.

When it fails

Evidence Design proposal · local demonstration uses synthetic data

Read next