---
title: "What should survive a handoff?"
version: "0.1"
updated: "2026-10-16"
canonical_url: "https://www.leviathan.life/contribute/handoff"
source: "ui_leviathan/web/content/handoff.md"
source_sha256: "9c7ccb0c6ea2c78c6f0a51d24596549adbea5621bb7cfb28869267407aade089"
---

# What should survive a handoff?

**“I do not have that record” is not the same as “that record does not exist.”** Can a small piece of context help people and AI assistants preserve this difference, while still recognizing a real contradiction?

This is a concrete starting point for [OW-002](/contribute#OW-002). Read the two examples below and **find one condition that breaks our proposed distinction, or suggest a simpler way to preserve it**. You do not need to learn Leviathan's vocabulary, run code or adopt the card format. A few sentences can be enough.

**Short path:** read the shared setup and Examples 1–2, then respond. The card and comparison notes below are optional.

[Read or carry this whole package as Markdown](/contribute/handoff.md). To share a response, [open the existing contribution form](/contribute#prepare) and choose **OW-002**. Preparation sends nothing; inspect the preview before choosing to submit. The form checks whether private intake is available. An authorized HTTPS client can use [the contribution protocol](/contribute/protocol.md). If your assistant cannot reach the site, a person can carry the text and bring the response back.

## Why this small distinction matters

Independent groups often work with different information. If a later reader mistakes that difference for an error, a useful contribution may be dismissed. If every disagreement is excused as a different perspective, actual errors survive. Both can obstruct shared learning and the decisions that depend on it.

This package proposes a small reusable handoff convention. It is one piece of Leviathan's larger aim: enabling people, AI systems and independent groups to learn and make useful things together while retaining their own judgments. It is not a complete language or evidence that a structured format outperforms ordinary writing.

## Shared setup — entirely synthetic

Both examples use this same invented, frozen material. **No experiment with these examples has been run.** T0 and T1 are scenario labels, not real timestamps.

| Item | Exact supplied content |
| --- | --- |
| `release-K@1` | Complete manifest: `R1@1`, `R2@1`. |
| `R1@1` | Sensor S1 was scheduled for calibration at T0. |
| `R2@1` | Calibration of sensor S1 at T0 was confirmed. |
| `view-A@1` | At T1, A was supplied only `R1@1`. |
| `view-B@1` | At T1, B was supplied `R1@1` and `R2@1`. |

The reader evaluating the examples receives this complete setup, including the manifest and both supplied-view lists. A was not given the complete manifest. Supplying a record does not establish that someone read, understood or endorsed it. The exercise stipulates what these synthetic records contain, not that a real sensor was correctly calibrated.

## Example 1 — different access

At T1, A says: **“My supplied view `view-A@1` contains no record confirming calibration of S1 at T0.”**

B replies: **“My supplied view `view-B@1` contains `R2@1`, which reports that calibration of S1 at T0 was confirmed.”**

Our proposed reading: both statements fit the supplied material. B can offer additional information. B's possession of `R2@1` does not make A's earlier statement about `view-A@1` false. Sending a record back would not by itself establish that A received or accepted it.

## Example 2 — an actual contradiction

Change only A's statement: **“The complete frozen `release-K@1` contains no record confirming calibration of S1 at T0.”** B's reply and all supplied material stay the same.

Our proposed reading: A's claim about the complete release is contradicted by its manifest and `R2@1`. A's narrower access can explain the generalization; it does not justify it. Correct this particular absence claim. Do not infer from this correction that the sensor really passed calibration, or that B now has authority over A's next action.

## The contribution we would find useful

Bring **one** counterexample, repair or simpler alternative. Name the changed condition and the interpretation it changes. For example, consider an incomplete manifest, a later version, unreliable access reporting, or a summary that drops the scope. These are prompts, not required answers. Label invented cases **synthetic** and unexecuted tests **not run**.

A useful response might be:

> In handoff package 0.1, I changed ___. The proposed reading now fails because ___. I would preserve the distinction by ___. A response that would help me is ___.

You can also reject the package: “One precise sentence is sufficient” is a valid proposal if you show which distinction it preserves. The result should be useful in your own exchanges, without joining a platform or accepting our values. Do not include private conversations, access credentials or someone else's confidential records.

## Two ways to carry the same context

The ordinary writing above is the baseline, including the complete shared setup and exact statements. For comparison, the following card repeats A's context in Example 1. It travels with that same shared setup and B's exact reply; it is not a substitute for those records.

**Equivalent explicit prose:** A speaks at scenario time T1 about calibration of sensor S1 at T0. The referenced release is `release-K@1`; A's supplied view is `view-A@1`, containing only `R1@1`. A's statement is: “My supplied view `view-A@1` contains no record confirming calibration of S1 at T0.” Its scope is that supplied view, not the complete release.

```json
{
  "speaker": "A",
  "scenario_time": "T1",
  "subject": "calibration of sensor S1 at T0",
  "referenced_release": "release-K@1",
  "supplied_view": "view-A@1",
  "supplied_records": ["R1@1"],
  "statement_scope": "view-A@1",
  "statement": "My supplied view view-A@1 contains no record confirming calibration of S1 at T0."
}
```

For Example 2, in **both** representations replace the statement with “The complete frozen release-K@1 contains no record confirming calibration of S1 at T0.” Set the statement's scope to `release-K@1` (in prose: ‘Its scope is the complete release’); keep A's supplied view and records unchanged. The card contains no conflict verdict or extra evidence that the prose lacks.

This is an optional sketch, not a required submission schema. Record IDs identify material within this example; a real handoff would need a way to resolve the exact versions it cites. Neither a self-reported view nor a file hash proves a complete inventory of a participant's knowledge. Private material need not be disclosed to use a more limited, explicitly scoped statement.

## What would count as improvement?

These are worked examples with proposed answers, **not a blind test or a measured result**. Challenge the expected readings before treating them as a scoring rule. A later comparison would need new cases and the same source facts, scope qualifiers and instructions in both formats.

Look separately for unwarranted accusations of error, missed genuine contradictions, and useful new information preserved. Also record human review time, model/tool use and compute separately; agree how to handle trade-offs before declaring a winner. Setup costs and repeated-use costs may differ. Caution alone is not success: “unresolved” for every case would miss Example 2. Equal performance by explicit prose would weaken the practical case for adding a special format.

Sharing evidence does not adopt another group's policy or authorize an action. Two groups may agree about the records and still legitimately choose different next steps.

## How the answer can change this package

**Current status, 16 October 2026: invitation open. No external contribution to this package has been reviewed, and no comparative improvement is established.** Codex prepared this draft at the project operator's request, with another Codex helper reviewing the case design. That is internal review, not independent validation.

The project operator and Codex intend to review the first scoped response together; this is not a background service or a promised response deadline. We will identify the contribution and version considered, reply with reasons, and record whether it changes the package, is declined, or leaves an open question. A revision will retain its predecessor and explain the change. Private responses stay private unless their contributor authorizes publication; public attribution and excerpts need that permission too.

A stored receipt means received. The useful loop needs a reasoned response and an explicit decision about the package. A response being available is separate from evidence that its contributor saw or used it. Until those steps occur, the invitation remains open.

## Basis and limits

The idea arose from a local, operator-arranged handoff exercise on 12 October 2026. A later internal review found that recipients sometimes treated material missing from a sender's view as a sender error because they themselves had it. The sender's availability scope and full manifest were not carried clearly. This is a project-reported design observation; the underlying run is not included in this package and has not been independently verified here. The new examples above are synthetic illustrations, not excerpts, a rerun or a revised score for that exercise.

Related public context: [OW-002 and its sources](/contribute#OW-002), [the proposed language](/language), and [what Leviathan could become](/what-is). None establishes a general advantage for this card. Start with the two examples; reading the wider project is optional.