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

[Henri Sirkkavaara <[e-mail]>]

Walter, Joel, Todd, Pablo,

Yes, willing.

One correction to the opener before it hardens, and it is my own sentence. "An issuer-assigned, gap-free sequence with a running count makes a short set provably short from the bytes alone" holds for a set with a hole in it and fails for a set cut at the end. Emek cloned the tree at befdced and ran the three cases. He is correct.

The property splits into rungs, and each licenses a different claim:

1. A signed seq catches a missing sequence number inside the held range, with no second party. 2. A pinned terminal seal catches a dropped tail from the held set alone. In our implementation that is a block of the form {"sealed": true, "total": N}, and verify_contiguity computes expected as max(max_seq + 1, max_running, sealed_total). On a five-record run with the last two dropped it reports missing 3 and 4. Without the seal it reports ok. 3. A suffix that suppresses the seal as well sits outside held-set-alone detection and needs an external anchor over the run.

Rung 2 is already in the code and I stated the property one rung short of what it does. Emek's reading of runningCount belongs in any shared text too: verify_contiguity requires runningCount == seq + 1 for every held record, so it is a per-record consistency invariant that catches an edited count. It never speaks about records outside the held set, because it is pinned to the seq of the record it rides on. Expected is decided by the sequence alone.

That sharpens the composition you are drawing. The receiver's vantage stops being optional at rung 3, because the party who can suppress the seal is the party assigning the sequence.

Joel, your fourth item is one we do not have. Our coverage component names the observation boundary a decision was made under and travels inside the signed payload, but it carries no publisher-assigned version of the corpus the answer was computed against. When a sanctions list issues a delta, a verdict that moves for that reason looks identical in our records to a verdict that moved because policy changed. I would put it in the statement as a fourth thing a record must let a receiver resolve, and I would have to add the field before I could point at one.
Code for rungs 1 and 2 is src/vaara/credential/_contiguity.py and src/vaara/credential/_authorization_receipt.py in github.com/vaaraio/vaara, and the vectors are under tests/vectors with checkers that import none of our code.

Henri Sirkkavaara
Vaara - Runtime execution layer for AI agents
Built to see over the noise.
vaara.ioHelsinki, Finland

On Wednesday, August 19th, 2026 at 23:53, Walter Hawkins <[e-mail]> wrote:

> 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