[SCITT] Closing omission from the receiver's vantage — what a record must carry

[Walter Hawkins <[e-mail]>]

Henri, Todd,

Opening this as its own thread, off all three of our drafts, because the
piece it's about belongs to none of them and touches all of them.

The gap is the one Henri named and Todd occupies from the other side:
closing omission needs a party who knows an answer was owed. A hash-chained
receipt makes deletion and reordering detectable and leaves omission open —
a payment that never entered the chain leaves no gap to find. A sender-side
attestation can't help either, because the party that can suppress the
record is the same party producing the attestation. The only actor in the
loop who knows a payment was owed, and cannot be made to un-know it, is the
one receiving the money. Todd's PRVO-2 is that actor, and the 21.20%
fictitious-settlement figure is what makes the vantage concrete rather than
theoretical.

So the question worth answering here, and I think it's a small one: what
does a record have to carry for a party in the receiving position to use
it, resolving all of it without ever contacting the executor? Henri put the
shape better than I would have — three things:

1. which authorization governed this payment,
2. what bound was in force when it settled, and
3. whether the set of records claiming to cover this payment is complete.

The third is where the two failure modes separate cleanly, and why this
composes instead of competing. An issuer-assigned, gap-free sequence with a
running count — Henri's completeness component — makes a short set provably
short from the bytes alone, no second party required. It catches a record
removed from a set. It says nothing about a record never created, because
that is issuer-assigned, and the issuer sits on the side that benefits from
the omission. The receiver catches exactly that: the executor can suppress
a record; it cannot suppress the arrival of money. Two failure modes, two
parties, and neither party covers both — which is the whole argument for
treating the receiver as a distinct evidence vantage rather than folding it
into any one draft.

The natural enumerator on the receiver's side is the settlement rail:
records bound to the settled transaction's own digest, one per payee leg,
so an absent party enumerates from the rail instead of from a list the
executor hands them, and a missing leg is visible to whoever holds it. That
is the part I would rather pull out of my x402 profile and specify here,
where it is not subordinate to one payment-authorization draft.

What I would propose we produce, if you are both willing: a short statement
of the receiver as an evidence vantage — the three things a record must let
it resolve, the completeness component and its stated limit, and what a
rail profile has to say for the rail's own records to serve the
enumeration. Not a fourth draft competing with the three we have; the
shared substrate the other three can each reference.

Henri, the completeness component and its limit are yours to state. Todd,
the fraud side — why the receiver's knowledge is the input the sending side
cannot manufacture — is what keeps this grounded in a real failure rather
than a neat construction. I will bring the rail-enumeration binding and a
testnet EVM rail to exercise it against real settled transactions.

Walter