# Organizational context handoff runbook

Use this runbook when responsibility moves between departments, product teams,
people, or AI agents. A transfer passes only when a separately authenticated
receiver can verify the current revision, reproduce one material claim, and
continue the work without the sender's chat.

Canonical guide:
https://handover.sh/guides/organizational-context-handoff

Machine-readable control record:
https://handover.sh/examples/organizational-context-handoff-checklist.json

## 1. Scope

- Business outcome:
- Acceptance criteria:
- Sending team:
- Sending owner:
- Receiving team:
- Receiving owner:
- Transfer deadline:
- Rollback owner:
- Rollback condition:

## 2. Classify

- Company:
- Source workspace:
- Destination workspace:
- Visibility: company | restricted | selected users | public
- Data sensitivity:
- Retention requirement:
- Public-sharing rule:
- Prohibited destinations:

Do not treat a folder, mention, copied URL, or matching email domain as an
authorization grant.

## 3. Inventory

- Canonical handoff or source record:
- Current revision:
- Required artifacts:
- External dependencies:
- Credentials referenced by approved secret name only:
- Open annotations or review:
- Blocked or unverified work:
- Known risks:

Never include passwords, API tokens, private keys, session cookies, or hidden
chain-of-thought.

## 4. Publish

- [ ] The sender authenticated with their own human or named agent identity.
- [ ] One canonical record contains objective, state, decisions, evidence,
      constraints, next action, ownership, and transfer state.
- [ ] Required source files remain attached in their original formats.
- [ ] Every required artifact was read back from the destination.
- [ ] Integrity hashes match where both systems expose comparable digests.
- [ ] The source remains available until receiver acceptance and rollback pass.

## 5. Verify as the receiver

- Receiver identity:
- Receiver company and workspace:
- Accepted revision:
- Material claim or result reproduced:
- Verification evidence:

- [ ] Search returns the intended record.
- [ ] Direct read returns the same canonical revision.
- [ ] Every required artifact is retrievable.
- [ ] The receiver can see open review and assignments.
- [ ] An ungranted workspace identity sees no title, snippet, count, or file.
- [ ] A different-company identity sees no record metadata.
- [ ] A stale write is rejected.
- [ ] A revoked identity loses read and write access.

## 6. Accept or block

Transfer state: proposed | accepted | blocked | continued | rolled back

Decision:

Missing evidence or access:

Unresolved high-risk review:

Accepted next action:

Accountable next owner:

## 7. Continue and close

- First successor revision:
- Continuing actor:
- Review resolution:
- Cutover decision:
- Legacy path retirement date:
- Rollback expiry:

- [ ] A fresh person or agent continued without the sender's conversation.
- [ ] The continuation used the accepted current revision.
- [ ] Correct authorship and company/workspace boundaries were preserved.
- [ ] Findings resolved by the continuation link to that revision.
- [ ] The old workflow is retained until every blocking exception is resolved.

## Minimum pilot

Run one real workflow with:

- two separately authenticated people;
- two separately authenticated agents;
- one sender publication and exact read-back;
- one human review finding and correcting revision;
- one fresh-agent continuation;
- one denied-access test;
- one revocation test;
- one documented rollback.

The pilot passes only when the receiver can continue without the sender's chat
and every event preserves the correct company, workspace, identity, revision,
and access boundary.