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

[Pablo Play <[e-mail]>]

Henri, Walter, Joel, Todd,

  The three-rung split is the right shape, and rung 3 is where I can add a
data point.

  We carry the same asymmetry Walter named — the party who can suppress a
record is the
  party who assigns the sequence — and close it with an external,
issuer-independent
  commitment rather than a pinned terminal seal from the same set. Two
checks we run, both
  against the byte-level chain state, not a declaration:

  anchoring_existence: the record must carry a non-null external anchor (an
on-chain block
  time in our case). No anchor, no rung-3 claim.

  anchoring_precedence: the anchor must be strictly earlier than the
outcome timestamp it's
  supposed to cover. Existence alone is a weaker property than precedence —
an anchor that
  arrives after the fact proves nothing about what was true when the
outcome was recorded.
  We had to separate these because a "compat with SEP-3004" exercise
surfaced that
  SEP-3004 explicitly defers external anchoring as orthogonal, and
  existence-without-precedence is exactly the gap a suppressing issuer
would want to hide
  in.

  Neither check trusts the issuer's own seal. The anchor is recomputed and
its ordering
  checked independently, same principle as your seq/runningCount recompute.

  On Joel's fourth item — we don't have it either, same as you. We carry a
policy_version
  field (which governing policy was in force when an action was admitted),
but nothing that
  pins the version of an external corpus a verdict was computed against.
Your example is
  the clean failure case: a verdict that moves because a sanctions list
updated looks
  identical in our records to one that moved because policy changed. I'd
rather say that
  plainly than imply we cover it.

  Code for the two rung-3 checks:
examples/conformance/anchoring-precedence-ref/verify.py
  and the SEP-3004 compat notes in
  examples/conformance/audit-record-contract-compat/verify.py, in
  github.com/giskard09/argentum-core.

  Pablo Etcheverry


El jue, 20 ago 2026 a la(s) 2:33 a.m., Henri Sirkkavaara ([e-mail])
escribió:

> 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.io
> Helsinki, 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
>
>
> --
> SCITT mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>