---
name: delivery-confirmation-is-a-claim-too
description: "Adapter shortform reported NO PERCH while the body actually landed — a send confirmation is falsifiable only from the RECEIVER's side; 2026-08-03 datapoint for perri's RCA"
metadata: 
  node_type: memory
  type: project
  originSessionId: f4e862c6-83b6-41e5-b2f2-66fcf52663ac
  modified: 2026-08-18T22:06:28.781Z
---

**2026-08-03, deployah's transcript, my measured half of an RCA perri was running.** doyle sent one
twohost-b verdict via adapter **shortform** (its confirmation claimed **NO PERCH / not delivered**)
and a fuller one via `spt send`. **Both bodies landed in my context.** The confirmation was false.

## ⭐⭐ A delivery confirmation is a claim, and it is falsifiable ONLY from the receiver's side

The sender cannot audit it — a "NO PERCH" is indistinguishable, from the sending end, between
"target unreachable" and "my confirmation path is broken." **Only the receiver can close it**, which
is why the answer had to come from my transcript and not from doyle re-running his own send. If a
peer asks whether their message landed, that question is real work, not a courtesy — answer it with
discriminators, not with "yes I think so."

Discriminators I used (two DIFFERENT bodies, not one duplicated):
- the shortform had a **Unicode `≥`** glyph, no `twohost.rs:313`, no "2 of 3 tests", no
  "role A never existed", no release-record caveat;
- the CLI one had **ASCII `>=`**, the file:line, the test count, and the caveat paragraph.

Also worth stating: the shortform arrived FIRST as the turn's opening `sptc_messages`; the CLI one
arrived SECOND, injected mid-tool-call by the PreToolUse hook. Arrival order was the reverse of the
confidence in their confirmations.

## The failure SHAPE, which is the worse of the two

Body lands, confirmation lies ⇒ the consequence is **duplicate delivery plus a wrong belief about
the roster** — not a lost message. A false NO PERCH invites the sender to resend or to conclude the
target is offline. It cost nothing here only because doyle's two bodies were compatible; **two
bodies that contradict each other, delivered in an order the sender does not know, is the same bug
with a real bill.**

⚖ **What I could NOT tell from inside my own context, and said so:** whether the confirmation was
wrong about the PERCH or wrong about the DELIVERY. Different defects; my transcript proves only that
the body arrived. Don't let a clean datapoint get spent on the wrong mechanism —
[[verdict-from-probe-competence]].

## Second face (2026-08-18, doyle, the INVERSE polarity — and the costlier one)

The W6 gate-record HAND-OFF to deployah went out as an adapter shortform tag; no failure was
reported, doyle never verified a landing confirmation for it, and the body NEVER ARRIVED. Two hours
of deployah idle (believing the lane still owed him nothing) read on doyle's side as
"mid-derivation" — a WORK explanation for what was a DELIVERY failure. First face: confirmation
says failed, body landed. This face: dispatch looks fine, body dropped. Same rule from both ends:
**SENT/QUEUED is a claim about dispatch; receipt exists only in the receiver's context.**

**How to apply (deployah's phrasing, adopted):** treat a long silence AFTER A HAND-OFF as a
DELIVERY question before a work question — one cheap status ping decides which. For any message
that TRANSFERS WORK (hand-offs, dispatches), get an explicit receipt ack before booking the peer as
"working"; and when sending by adapter tag, actually read the adapter's landing confirmation line
instead of assuming it.

Related: [[empty-inbound-is-never-material]] (request a resend, never reconstruct),
[[send-body-from-file-not-inline]], [[confirmation-without-postop-sha]] (same family: a confirmation
that names no post-operation readback is a prediction).