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

[Joel Hillier <[e-mail]>]

Walter, Henri, Todd,

Supporting this, and offering a fourth data point that I think strengthens the case for a shared substrate rather than weakening it: a document with no payments in it has both halves you describe, arrived at independently, and hit the same limit.

ARP is cross-sovereign claim reconciliation, not payment. It has an issuer-assigned completeness component and it has a distinct-vantage party, and the split between them is exactly the one Walter draws.

The completeness component is an Examined-Set Root: a Merkle root over the distinct Claim Hashes a retroactive evaluation sweep examined, with a count beside it, signed by the reconciliation server. It catches a record removed from a set from the bytes alone. It says nothing about a record never created, and for precisely the reason Walter gives about Henri's: the set is assigned by the server, and the server is the party that benefits from the omission. That limit is written into the document rather than left to a reader, and it was written there because a reviewer put it there.

The distinct vantage is the requester. In ARP the party who commissioned a reconciliation holds a Reconciliation Identifier and a signed acknowledgment, and cannot be made to un-know that an output was owed. The document already says the Examined-Set Root lets an Audience Member require the operator to prove that its own reconciliation was in the set it claims to have examined. That is Todd's receiver in a setting with no money in it, which is the argument for the substrate: the vantage is not a property of payments, it is a property of being the party that knows an answer was owed. Payments make it concrete and legible, and the 21.20% figure is what makes it urgent, but the structure survives the subject matter changing.

One refinement I would offer to the three things a record must let a receiver resolve, because ARP has a fourth that turned out to be load-bearing and I suspect it generalises.

Between "what bound was in force when it settled" and "is the set complete" there is a question about the corpus the answer was computed against. ARP separates a verdict changing because the policy changed from a verdict changing because the underlying published corpus changed — a sanctions list issuing a delta, say — and carries a source-data version identifier taken from the publisher rather than from the answering party. Without it, a later re-evaluation that produces a different answer is unattributable, and unattributable is the state an omitting party is happy to leave you in. For a payment rail the analogue is whatever the settlement state was read against. It may fold into your item 2; I would rather it were named than folded silently.

The other thing worth stating for the substrate, since I have just spent two days on it: completeness evidence and equivocation evidence need different parties, and neither is the other. ARP now carries a witness quorum over ledger heads — countersignatures from observers independent of the responding service, with the rule that entries under common control count once, because two instances of one observer are not two observers. Its limit belongs in the same breath: that independence is declared by the witnesses, not proven from the bytes, so a verifier can check the declarations are pairwise distinct and cannot check that they are true. Even so, it catches an operator serving two chains. It does not catch an operator omitting from one chain, and no amount of it ever will. Your receiver catches the omission and cannot see the fork. Two failure modes, two parties is right, and a substrate that names three vantages — issuer, independent observer, and the party owed the answer — with what each one cannot see, would be more useful than one that names two.

I would read and comment on the statement, and if it is useful I will contribute ARP's Examined-Set Root construction and its stated limit as a non-payment worked example, so the substrate has a second subject matter in it from the start rather than being generalised from payments afterwards.

Walter — on the rail enumeration, the property I would want stated explicitly is the one you have implied: the enumerator must be reachable by a party who has only the settled transaction, and not by a party who must first be handed a list. ARP's equivalent is enumerating from a Claim Hash rather than from the server's index, and the difference between those two only becomes visible on the day the index is wrong.

Joel
________________________________
From: Walter Hawkins <[e-mail]>
Sent: Wednesday, 19 August 2026 20:53:29
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: [SCITT] Closing omission from the receiver's vantage — what a record must carry
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