Return-Path: <e.dogru@conarium.dev>
X-Original-To: scitt@mail2.ietf.org
Delivered-To: scitt@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1])
	by mail2.ietf.org (Postfix) with ESMTP id E534112D1D915
	for <scitt@mail2.ietf.org>; Thu, 20 Aug 2026 17:27:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1787272078; bh=GcY85vOyBm5x5N15YNunimSBPHFm6uIsKznKu3YvJQQ=;
	h=Cc:From:In-Reply-To:References:Subject:To:Date;
	b=F3d5RCeyrAE4gFpz2wAcxqURfQ5H1oqD26lxzxFBuX28ceR7kdBnhdnA1Pb97DXpv
	 CVu+6roOMD0nX3EzWhn9IyDL/NPQX2Frui+uJTlHuJwXb5kpue3Dt0ibg002FmDcxj
	 DJ47FaCJV8hSNbmKDJUGdD3uKzrtpb6m1T9nIB2I=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -0.62
X-Spam-Level: 
X-Spam-Status: No, score=-0.62 tagged_above=-999 required=5
	tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
	DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_AFFORDABLE=1,
	HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1,
	RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
	RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001,
	SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key)
	header.d=conarium.dev
Received: from mail2.ietf.org ([166.84.6.31])
	by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id r5Hd7Hvhj_lB for <scitt@mail2.ietf.org>;
	Thu, 20 Aug 2026 17:27:57 -0700 (PDT)
Received: from bat.aspen.relay.mailchannels.net
 (bat.aspen.relay.mailchannels.net [23.83.221.13])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(No client certificate requested)
	by mail2.ietf.org (Postfix) with ESMTPS id 7C4F812D1D90E
	for <scitt@ietf.org>; Thu, 20 Aug 2026 17:27:57 -0700 (PDT)
X-Sender-Id: hostingeremail|x-authuser|e.dogru@conarium.dev
Received: from relay.mailchannels.net (localhost [127.0.0.1])
	by relay.mailchannels.net (Postfix) with ESMTP id E44CB161354
	for <scitt@ietf.org>; Fri, 21 Aug 2026 00:27:49 +0000 (UTC)
Received: from fr-int-smtpout24.hostinger.io
 (100-117-164-236.trex-nlb.outbound.svc.cluster.local [100.117.164.236])
	(Authenticated sender: hostingeremail)
	by relay.mailchannels.net (Postfix) with ESMTPA id 49D2316091F
	for <scitt@ietf.org>; Fri, 21 Aug 2026 00:27:49 +0000 (UTC)
X-Sender-Id: hostingeremail|x-authuser|e.dogru@conarium.dev
X-MC-Relay: Bad
X-MailChannels-SenderId: hostingeremail|x-authuser|e.dogru@conarium.dev
X-MailChannels-Auth-Id: hostingeremail
X-Relation-Average: 03f4860d5ccb16f4_1787272069881_1396389620
X-MC-Loop-Signature: 1787272069881:1219935520
X-MC-Ingress-Time: 1787272069881
Received: from fr-int-smtpout24.hostinger.io (fr-int-smtpout24.hostinger.io
 [148.222.54.15])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384)
	by 100.117.164.236 (trex/8.0.2);
	Fri, 21 Aug 2026 00:27:49 +0000
Received: from localhost (34.86.89.34.bc.googleusercontent.com
 [IPv6:2a00:1d35:17a4:d900:51f5:85e2:e74c:e841])
	(Authenticated sender: e.dogru@conarium.dev)
	by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4hR1Ng3S5tz1xmr
	for <scitt@ietf.org>; Fri, 21 Aug 2026 00:27:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conarium.dev;
	s=hostingermail-a; t=1787272067;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=EZ0HWoOGXRXIOwxEKhHsXR6GHr56bqDfcyqWDD/qCGg=;
	b=HQ9SBNurr4bubWreaT14a5C6PGIU8TLG/hmaAnH0Pqml0eE8bpBU+b+xwVhQC6zPq6sKes
	+mD/Qxy4Z8J/SaVUmv9MQCRnYiPA224D2QSpuMWlpIqlZLaK/ZuIHu3+kAdhRcCzGJl+eD
	X1SrLlzKQ/DzfSn5BiSKGBsfv2ZHrnlmuvrUGqmHGbYBu722idW9gp8CWgimg03Fr8qRYs
	SVxMwlTX0WTR6ncoLS0hxEwk8fJLlSVlMZEEfsBkxWF0+8npUi8YCZA3vHCLCmgRyBoIts
	N1V9qQEeggo2cyieljOgDw8czByK3nVfTPSdofVulMiA9xmmevPaOgiHNnSsCA==
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=utf-8
From: <e.dogru@conarium.dev>
In-Reply-To: 
 <CALc05oFWK2_mQEB9JLRorCS5QLc0rPrJxj3BMc0r0B82ZcH_mg@mail.gmail.com>
Message-Id: <1787272059233193813.1787272059@conarium.dev>
Mime-Version: 1.0
References: <1787262784652143705.1787262784@conarium.dev>
 <CALc05oFWK2_mQEB9JLRorCS5QLc0rPrJxj3BMc0r0B82ZcH_mg@mail.gmail.com>
To: <wdhawkins46@gmail.com>
Date: Fri, 21 Aug 2026 00:27:47 +0000 (UTC)
X-CM-Envelope: 
 MS4xfFYPEmdUZWVZ7xlms6ZPsfD8UzfNyvfY2AKhlRZYVKpHZ7EwDvtqIp8mrTwfggtfUfc0Ef0pZSY0ph/bMMedQ7Y8mMlr1is5hecJBJVKL8jffS1zuGrM
 8/M1Dmsy8arDCHOr0GBUv74V/amuL8U5MgvCJxT/kt+qr2rpOHbns40/pt2MMryCAXkHsg1jLBHtalaiKDH+620QyInC2TqyuEs8Fm/bwsl0qtV37rcLJX4k
 IMJzv8yFf2O6nVxuKpBYoA==
X-CM-Analysis: v=2.4 cv=BvrPwpX5 c=1 sm=1 tr=0 ts=6a879b83
 a=RddCdUNZqxBAE8jYSUBS9Q==:617 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10
 a=5KLPUuaC_9wA:10 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=k6UPx9b3AAAA:8
 a=JVnXbA85lWQIOTahQ2sA:9 a=jjeM4EU90gX5Hfj5:21 a=lqcHg5cX4UMA:10
 a=QEXdDO2ut3YA:10 a=313tBfKMLnzeofNEJDA5:22
X-AuthUser: e.dogru@conarium.dev
Message-ID-Hash: 2CLNMQGVBBHM5ZNG6H4ZZBR6DL2DXFA6
X-Message-ID-Hash: 2CLNMQGVBBHM5ZNG6H4ZZBR6DL2DXFA6
X-MailFrom: e.dogru@conarium.dev
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; nonmember-moderation; administrivia;
 implicit-dest; max-recipients; max-size; news-moderation; no-subject;
 digests; suspicious-header
CC: hello@vaara.io, scitt@ietf.org, jhillier@certisyn.com,
 playplay2736@gmail.com, nenadvasic@protonmail.com, Todd.Gibson@t-mobile.com
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5BSCITT=5D_Re=3A_Closing_omission_from_the_receiver=27s_vantage_?=
	=?utf-8?q?=E2=80=94_what_a_record_must_carry?=
List-Id: "Supply Chain Integrity, Transparency, and Trust" <scitt.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/scitt/nY37kbR84Inpy26QI5cphkzc_Aw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scitt>
List-Help: <mailto:scitt-request@ietf.org?subject=help>
List-Owner: <mailto:scitt-owner@ietf.org>
List-Post: <mailto:scitt@ietf.org>
List-Subscribe: <mailto:scitt-join@ietf.org>
List-Unsubscribe: <mailto:scitt-leave@ietf.org>

<div>All,</div><div><br></div><div>I said I would come back with the check =
and what it caught rather than with a plan. It is written and merged; this =
is what it caught. Walter's rung 3 question gets a measured answer at the e=
nd, because it turned out I could check it rather than argue it.</div><div>=
<br></div><div>The problem is in -05 in my own words: four sentences in the=
 Implementation Status section of -04 were accurate the day they were writt=
en and false within days, every one of them claiming less than the code did=
, and nothing in the repository compared that section to the tool. They wer=
e found by a reader holding the document beside the output.</div><div><br><=
/div><div>The check runs the section instead of reading it. Three declarati=
ons of one fact exist: the code, the prose, and now a claim table between t=
hem, because prose cannot be executed. Each behavioural sentence is bound t=
o a run of the shipped CLI over a named fixture, and two directions are enf=
orced. Every value a run produced must still appear in the sentence that st=
ates it, and the number of sentences must equal the number of claims. A sen=
tence with no claim is one nothing measures. A claim with no sentence is a =
measurement the document dropped.</div><div><br></div><div>The revision it =
reads is derived from what is in the repository rather than named in the ch=
eck, because a hard-coded revision is the same class of stale declaration t=
he check exists to catch.</div><div><br></div><div>I showed it failing thre=
e ways before wiring it in, since a check that has only ever been green dem=
onstrates nothing:</div><div><br></div><div>&nbsp; &nbsp; a value edited ou=
t of a sentence</div><div>&nbsp; &nbsp; &nbsp; -&gt; the sentence no longer=
 contains observed-without-receipt</div><div>&nbsp; &nbsp; one bullet remov=
ed</div><div>&nbsp; &nbsp; &nbsp; -&gt; states 4 observed behaviour(s), the=
 claim table runs 5</div><div>&nbsp; &nbsp; a fixture changed so the tool's=
 outcome moved, sentence untouched</div><div>&nbsp; &nbsp; &nbsp; -&gt; ite=
m outcomes are ["excluded","indeterminate"],</div><div>&nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp;the table says ["excluded","observed-without-receipt"]</div><=
div><br></div><div>The third is the one that matters: the code moved and th=
e sentence stood still, which is what happened four times in -04.</div><div=
><br></div><div>What it caught immediately is a sentence of mine. -05 says =
"The implementation's test suite contains no check that compares this secti=
on against what the code does." From the merge commit that is false, and a =
posted draft cannot be edited, so it is the first correction -06 owes.</div=
><div><br></div><div>Two limits, stated now rather than discovered later. I=
t pins the behaviour table and not the prose around it, so a paragraph can =
still go stale in a way nothing runs. And a red has two honest fixes: chang=
e the code back, or write the revision that says what the code now does. Ed=
iting a posted draft is not one of them, which makes the cost of drift a do=
cument rather than a diff.</div><div><br></div><div>Walter, on rung 3. You =
put it as: an external anchor is not automatically rung 3, an anchor is a c=
laim by whoever paid for it, and a profile that says "anchored" without say=
ing "and re-derived" has described rung 2 with extra steps. I went and look=
ed rather than answering from memory, and the implementation agrees with yo=
u, which I did not know for certain before you wrote it.</div><div><br></di=
v><div>--anchor-check deserialises the timestamp proof, refuses a proof who=
se digest is not the chain head, walks the attestations, and where the atte=
station is Bitcoin it fetches that block and compares the digest against th=
e merkle root. So the re-derivation is in the path and not in the prose.</d=
iv><div><br></div><div>The part I would not have thought to defend, and whi=
ch your framing is the reason to mention: it separates two answers that a s=
ingle exit code would have merged. A proof that fails to verify exits 14. A=
 proof that could not be checked at all, where the block could not be fetch=
ed, exits 15, and 15 is evaluated first, so "I could not check" never gets =
swallowed by "it failed". Returning 0 there would have been the same error =
in the other direction: the caller has to know the anchor was not verified,=
 not merely that it was not disproved. That is the weakest-rung rule applie=
d to our own tool, and it was written before anyone asked us for it, which =
is the only reason I can say it now without it sounding convenient.</div><d=
iv><br></div><div>Emek</div><br><br>
      <div class=3D"hmail-quote-container">
        <div class=3D"hmail-attr" data-qa=3D"message-reply-attribution">On =
Fri, Aug 21, 2026 at 2:50 AM Walter Hawkins &lt;wdhawkins46@gmail.com&gt; w=
rote:</div>
       =20
        <blockquote class=3D"hmail-quote"><div dir=3D"auto">Henri, Joel, Em=
ek, Pablo, Nenad, Todd,<br><br>Two corrections of my own before the part I =
owe this thread, since that appears<br>to be the going rate here and it's a=
 good rate.<br><br>**One.** I used the words "omission-proof" in my own not=
es and it was a rung<br>short. Our spend log is chained and gap-free under =
a signed grant, and the head<br>that seals it is counter-signed by a named =
accountant carrying a root and a<br>running total. That much I had right =
=E2=80=94 it's rung 2. What I had wrong was the<br>floor. A verifier arrivi=
ng for the first time, holding no prior state and doing<br>no anchor lookup=
, accepts an old validly-signed head together with the prefix<br>that match=
es it. Monotonic sequence, perfect arithmetic, short set. Henri's<br>correc=
tion this morning is the same shape as mine, and I'd made mine a day<br>ear=
lier without noticing what it cost.<br><br>Fixed the way Emek's rule says i=
t should be: the freshness floor is now a<br>required argument, and passing=
 nothing is an explicit downgrade whose verdict<br>is labelled tamper-evide=
nce rather than completeness. The weakest-rung rule<br>applied to an argume=
nt I had made optional.<br><br>**Two, and this is the one I think is worth =
the thread's time, because it's a<br>hole in rung 3 itself.**<br><br>We put=
 our heads on-chain: a zero-value transaction whose calldata carries the<br=
>head digest, the grant it covers, the sequence, and the key that signed it=
. A<br>first-contact verifier scans for those and takes the highest sequenc=
e as its<br>floor. That is the external anchor the ladder asks for, and two=
 days ago I'd<br>have told you it put us at rung 3.<br><br>Anchoring is per=
missionless. That property is why it resists censorship and it<br>is also t=
he attack. Anyone can write that calldata. The key field is plaintext,<br>a=
nd the accountant's key is public because it's named in the grant. So a<br>=
stranger writes an anchor for my grant at sequence 999999999, my scanner re=
ads<br>it, and every honest head I produce afterwards is refused as a rollb=
ack. The<br>floor is poisonable by anyone willing to pay for one transactio=
n, and the<br>failure mode isn't a missed omission =E2=80=94 it's an honest=
 record permanently<br>refused. We had traded a false negative for a false =
positive against ourselves,<br>which is the worse of the two trades.<br><br=
>The fix is that an anchored sequence cannot be read as a fact. It is a poi=
nter.<br>A verifier deriving a floor has to fetch the anchored bytes, recom=
pute the<br>digest over them, check the signature, and check that the head =
it just verified<br>names this grant and this sequence =E2=80=94 and only t=
hen let it move the floor. An<br>anchor whose content can't be retrieved si=
mply isn't floor-eligible, which can<br>only lower the floor toward the tam=
per-evidence downgrade, never raise it.<br><br>Stated honestly about where =
we are with it: that rule is written into our spec<br>text and our scanner =
does not yet do it. What the scanner does today is the<br>cheap half =E2=80=
=94 it ignores anchors that don't name the grant's accountant, which<br>clo=
ses the stranger-with-no-key case and leaves the forged-key case open,<br>b=
ecause that field is unauthenticated. So take the paragraph above as a clai=
m<br>about what rung 3 requires, not a claim about what I've shipped. The<b=
r>re-derivation is the next thing I write, and I'll come back with what it =
caught.<br><br>So for the statement I'd put it this way: an external anchor=
 is not<br>automatically rung 3. An anchor is a claim by whoever paid for i=
t. Rung 3 is<br>an anchor plus the verification that recovers what it point=
s at, and a profile<br>that says "anchored" without saying "and re-derived"=
 has described rung 2 with<br>extra steps. Nenad, I think this bears direct=
ly on precedence =E2=80=94 ordering a<br>revocation strictly against a sett=
lement only means something if both anchored<br>objects are re-derived firs=
t; otherwise you've ordered two assertions.<br><br>**What I owe: the rail e=
numeration.**<br><br>Every payment under a grant carries a binding in the o=
ne payer-chosen slot the<br>rail's own signature covers =E2=80=94 the EIP-3=
009 nonce, the Permit2 nonce, the XRPL<br>InvoiceID. The value is a domain-=
separated digest over the grant digest and the<br>payment identifier, so it=
's derivable by anyone holding those two and<br>recomputable from the settl=
ed transaction by anyone holding that.<br><br>The receiver's use is the par=
t this thread wants. A payee holding a settled<br>transaction recovers whic=
h grant and which payment it commits to from the<br>artefact itself, withou=
t asking the executor which authorisation it would like<br>to be judged und=
er. And the enumeration runs off the rail rather than off a<br>list: the pa=
yee walks settled transactions to their own address, not a set the<br>execu=
tor hands them. A leg the executor never wrote down is still on the rail<br=
>if the money moved, and the party holding it is the party who cannot be ma=
de to<br>un-know it arrived.<br><br>Testnet EVM rail, as promised: Coston2.=
 A head anchored as a real transaction at<br>block 34259963, the calldata r=
ead back off the chain and matched against the<br>signed head, block timest=
amp doing the ordering.<br><br>With a caveat that belongs in this thread mo=
re than most. That anchor predates<br>the hardening I described above =E2=
=80=94 its commitment has no accountant field and its<br>calldata has no ke=
y segment, so it verifies against the code as of the commit<br>that produce=
d it and not against current HEAD. I keep it as evidence that the<br>wiring=
 worked on the day, and as a small lesson I'd pass on: we anchored a shape<=
br>we were still editing, and permanence is the one property an anchor has =
whether<br>or not you were finished. New heads use the hardened shape. I'll=
 bring both,<br>labelled.<br><br>Two limits I'd rather state than have foun=
d.<br><br>The rail has to enforce slot uniqueness for once-per-payment to c=
ome free.<br>EIP-3009 and Permit2 consume the nonce, so it does. XRPL does =
not enforce<br>InvoiceID uniqueness =E2=80=94 two Payments carrying the sam=
e InvoiceID both settle =E2=80=94<br>so anyone deriving a cumulative total =
from XRPL evidence has to de-duplicate by<br>(grant, payment) and cannot le=
an on the rail for it.<br><br>The second one I had wrong until a review pul=
led it apart yesterday, and it<br>generalises past payments. The binding id=
entifies the grant; it does not bound<br>the amount. The slot commits to th=
e grant and the payment identifier and<br>nothing else, so an agent holding=
 the payer key can settle a million against a<br>payment it reports as one.=
 The cap only binds if the verifier reads amount,<br>recipient and asset ou=
t of the settled transaction and compares them back to<br>the grant. I had =
a document claiming one artefact proved both that money moved<br>and that i=
t moved within authority, and that sentence was doing work the<br>mechanism=
 didn't do. Identifying which authorisation governed an act is not<br>the s=
ame as bounding the act performed under it =E2=80=94 Nenad, that's your ite=
m 2<br>from the other end, and I think it's a second thing the substrate sh=
ould say<br>outright, because the failure is invisible and every incentive =
points at it.<br><br>The object model and its vectors are public as of toda=
y, as an open PR rather<br>than anything settled: specs/extensions/authorit=
y.md and<br>authority-vectors.json in x402-foundation/x402 #3220. If the st=
atement cites<br>components normatively the way Henri suggests, that's the =
published home for<br>the rail-binding piece, under the same one-authority =
rule Nenad named.<br><br>**Nenad's fourth vantage.**<br><br>I think it's ri=
ght and I'd add a note from our side. We have no revocation, and<br>that's =
deliberate rather than missing: our grants carry an expiry, and authority<b=
r>decays without anyone needing to deliver anything. A suppressed revocatio=
n is<br>invisible to a receiver, as you say =E2=80=94 but you can't suppres=
s the passage of<br>time. It's a real trade, not a free win: a short expiry=
 means re-issuance<br>traffic and a live principal, and a long one means a =
wide window where your<br>attack is exactly as bad as you describe. Where r=
e-issuance is affordable,<br>expiry is revocation you don't have to deliver=
, and I'd rather the substrate<br>name that as an option than have every pr=
ofile carry a revocation channel it<br>can't guarantee reaches anyone.<br><=
br>**Joel's fourth item.**<br><br>Same answer as Henri, Pablo and Nenad: we=
 don't have it. Nothing in our records<br>pins the publisher-assigned versi=
on of any corpus a decision was computed<br>against. Four for four is a bet=
ter argument for lifting it into the substrate<br>than any of us adding a f=
ield and then citing ourselves.<br><br>**Willing, and here's what I bring.*=
*<br><br>The rail-enumeration binding above, the Coston2 fixtures, and the =
rung-3<br>refinement =E2=80=94 anchor as pointer, not fact. Henri, the comp=
leteness component and<br>its rungs stay yours to state; Todd, the fraud si=
de is what keeps this attached<br>to a real failure; and if Emek's ladder i=
s going to carry the structure of the<br>document, it should carry his name=
 in it.<br><br>Walter<br></div><br><div class=3D"gmail_extra"><div>On Thu, =
Aug 20, 2026 04:53 PM, <a href=3D"mailto:e.dogru@conarium.dev" rel=3D"noref=
errer nofollow noopener">e.dogru@conarium.dev</a> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div>Joel, Henri, Pablo, Walter, Todd, Nenad,</div><div><br=
></div><div>Joel, you withdrew two claims in public before making your argu=
ment. I will put something of the same kind on the table before making mine=
.</div><div><br></div><div>The corollary you name is the half I have not do=
ne, and I can show you exactly where the line falls.</div><div><br></div><d=
iv>You wrote that the vocabulary has to reach the output, and that both our=
 implementations skip it. In mine the /2 result carries a bounds object: fo=
r each bound the comparison relied on, its source is protocol-defined, meas=
ured, operator-declared, or undeclared, and a result whose bounds are opera=
tor-declared states an outcome of that standing and no stronger. Measured a=
gainst the published package, one fixture, a receipt three seconds outside =
a two-hour window:</div><div><br></div><div>- no profile: all three bounds =
undeclared, both items indeterminate</div><div>- a profile with no clocks m=
ember: multiplicity and exclusion operator-declared, skew still undeclared<=
/div><div>- clocks.skew declared wider than the offset: operator-declared, =
and the item stays indeterminate. A declaration does not manufacture a matc=
h.</div><div>- clocks.skew declared narrower than the offset: the same item=
 becomes observed-without-receipt</div><div><br></div><div>So the vocabular=
y reaches that object. It does not reach the exit codes, which predate it a=
nd are still not a mapping of it. Your sentence covers precisely the half I=
 have not done, and I would rather that stayed in the record than get answe=
red with a plan.</div><div><br></div><div>The three clocks fields you asked=
 for are in -05 with their encoding: clocks.observation, clocks.receipt, cl=
ocks.skew, a duration grammar, a rule that an unknown key in clocks is reje=
cted by name, and a rule that the same bound declared twice must parse to t=
he same milliseconds or the run fails rather than picking one. Written to b=
e borrowed, not restated.</div><div><br></div><div>On placement. The distin=
ction is in -05 as a security consideration (sec-completeness), written aga=
inst my own implementation rather than about two of them: a truncated recei=
pt set verifies, detecting the removal needs a quantity from outside it, an=
d whether that quantity reached the verifier independently of the Issuer is=
 not visible in a digest. I support lifting it to the substrate, with one c=
aveat about how it is worded there. The property that matters is not "in-re=
cord beats argument". It is that a Consumer cannot tell the two apart from =
the artefact, so the result has to say which one it relied on. Stated as a =
ranking it invites an implementation to claim the stronger form without car=
rying it; stated as a disclosure obligation it does not.</div><div><br></di=
v><div>On the weakest-rung rule. Four documents arriving at it separately i=
s a better argument for the substrate than any one of us restating it, and =
your verdict-side version is the one I would take as the general form, beca=
use it survives translation to outputs that are not bounds at all. One caut=
ion from the side that has already shipped it: the rule is cheap to write a=
nd expensive to keep. indeterminate is only load-bearing while nobody is al=
lowed to average it, and the pressure to fold it into a coverage percentage=
 arrives from outside engineering, after the vocabulary is public and looks=
 like a scoring system.</div><div><br></div><div>One more thing worth putti=
ng in the record. Your sentence from two days ago, that a gaps section goin=
g stale understating an implementation fails the same way as one that overs=
tates, turned out to apply to mine four times over. Each statement was accu=
rate when written and false within days, always in the direction of claimin=
g less than the code did, and nothing in my test suite compares that sectio=
n against the code. So the corollary reaches further than either of us put =
it: the problem is not that our implementations skip the vocabulary. It is =
that neither of us has a check that would notice if they did. That is the g=
ap I would most like the substrate to make expensive to leave open, and it =
is the next thing I write on my own side. I will come back with the check a=
nd what it caught, rather than with a plan.</div><div><br></div><div>Emek C=
an Dogru</div><div>Conarium</div><br><br> <div> <div>On Fri, Aug 21, 2026 a=
t 12:06 AM Joel Hillier &lt;jhillier=3D<a href=3D"mailto:40certisyn.com@dma=
rc.ietf.org" target=3D"_blank" rel=3D"noreferrer nofollow noopener">40certi=
syn.com@<wbr>dmarc.ietf.org</a>&gt; wrote:</div>  <blockquote>     <p style=
=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Hi Henri, Pablo, Walte=
r, Todd,</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> E=
mek, I'm adding you to this because the rung ladder is yours and it's been =
travelling without your name on it. Henri's message this morning credits yo=
u with cloning at <code>befdced</code> and running the three cases, which i=
s true, but you're also the one who wrote the ladder and the rule that goes=
 with it. That rule is the most useful thing in this thread, and the first =
thing I did with it was turn it on my own document.It cost me two claims I =
made to you all yesterday. Both are below, before the rest.</p> <p style=3D=
"direction:ltr;margin-top:1em;margin-bottom:1em"> <b>Correction one. I told=
 you ARP's sweep chain makes a withdrawn Statement detectable. That's true =
for the middle and false for the tail.</b></p> <p style=3D"direction:ltr;ma=
rgin-top:1em;margin-bottom:1em"> Each Evaluation Sweep Statement carries th=
e previous Statement's notarisation, so I had the chain doing a job it can'=
t do. Your 0.2.4 shipped under "a hash chain is blind to a shorter tail" an=
d it applies to my series exactly as it applies to yours: a truncatedtail o=
f Sweep Statements verifies precisely as it did before.</p> <p style=3D"dir=
ection:ltr;margin-top:1em;margin-bottom:1em"> What actually puts ARP at run=
g 3 is a different mechanism, which I'd been crediting to the chain. Each S=
tatement is due inside a bounded interval measured from its trigger, and wh=
ere the trigger is a public event with a public timestamp, a sanctions list=
 publishinga delta starts a clock the operator doesn't own. An operator wit=
h no Statement inside the interval hasn't evaluated in time, and anyone can=
 check that holding none of the set. The chain covers the middle. The deadl=
ine covers the tail. Two mechanisms, and I'dhad them credited as one.</p> <=
p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> <b>Correction t=
wo, and this one is worse, because it's the sentence where I congratulated =
myself on not rounding up.</b></p> <p style=3D"direction:ltr;margin-top:1em=
;margin-bottom:1em"> I said the falsifiability argument holds for three of =
ARP's four triggers, "stated rather than rounded up." Only one of those thr=
ee rested on anything outside the reconciliation server. The other two rest=
ed on a transition list published by the server, underthe server's own key,=
 in a document with no publication time, no notarisation and no chain. A tr=
ansition simply left out of that array started no clock, and no party could=
 date the document well enough to show that it had been. On that footing th=
e count wasone in four, and the sentence claiming otherwise was the one pla=
ce the document rounded up.</p> <p style=3D"direction:ltr;margin-top:1em;ma=
rgin-bottom:1em"> It's three in four now because I fixed the mechanism rath=
er than the sentence: the document carries a publication timestamp, is nota=
rised on the ledger-head interval, and has to be republished on that interv=
al whether or not anything in it changed. That lastpart is the one that mat=
ters, and it's your placement argument doing the work. Without it, an opera=
tor that removed a witness entry and an operator that changed nothing publi=
sh the same thing, and the notarised series has no entry to be missing.</p>=
 <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> The claim is =
now conditional and the document says so: a deployment whose policy paramet=
ers aren't anchored that way has one falsifiable trigger, not three. Which =
is your rule about naming the ground, applied to a count I'd already publis=
hed.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> <b>On=
e more, since it's the mechanism I described to Walter yesterday.</b> I sai=
d ARP's witness quorum counts entries under common control once, because tw=
o instances of one observer aren't two observers. The distinctness test was=
 written over the operating-partyidentifier alone and said nothing about th=
e keys. Two entries declaring the same key under two different party identi=
fiers satisfied a quorum of two with a single signature. Both entries verif=
y, the identifiers are distinct, and a relying party doing exactlywhat the =
document said counted one signer twice. Now fixed by requiring the verifica=
tion method references to be pairwise distinct as well.</p> <p style=3D"dir=
ection:ltr;margin-top:1em;margin-bottom:1em"> Worth separating that from th=
e limit I did state correctly. Whether two named parties are genuinely inde=
pendent can't be tested by a verifier and the document concedes it. Whether=
 two entries name one key can always be tested, and wasn't.</p> <p style=3D=
"direction:ltr;margin-top:1em;margin-bottom:1em"> <b>Now the thing I owe th=
is thread.</b></p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1=
em"> Henri and Pablo have both said they'd need to add the fourth item befo=
re they could point at one, and Henri's suggested the substrate cite compon=
ents normatively rather than restate them. Together that means the fourth i=
tem gets lifted out of ARP. So let mehand it over along with what was wrong=
 with it, rather than after it's in shared text.</p> <p style=3D"direction:=
ltr;margin-top:1em;margin-bottom:1em"> A Partial Attestation carries a Sour=
ce-Data Version Identifier Set: one identifier per source consulted in eval=
uating the predicate. Each is a tuple of the list name as declared in the b=
ilateral agreement, and the state identifier the list publisher assignsto t=
hat state, not a value the answering party made up. It rides in the protect=
ed header so it's covered by the register's signature, and it's carried int=
o the output so it's covered by the sealing signature.</p> <p style=3D"dire=
ction:ltr;margin-top:1em;margin-bottom:1em"> The reason it's the publisher'=
s identifier and not the register's is the part worth carrying into any sha=
red text, because it isn't obvious and it's the whole point. A register-cho=
sen opaque string would be an arbitrary-bandwidth channel from register to =
relyingparty, travelling under signature into a sealed and ledgered artefac=
t, and the accompanying rule that differing identifiers mustn't be read as =
disagreement would normalise it. Taking the identifier from the publisher's=
 own state sequence is what makes it evidenceinstead of a side channel.</p>=
 <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Three things =
were wrong with the encoding, all found yesterday, all now repaired:</p> <p=
 style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> 1. The Set had n=
o ordering rule. Five other collections in ARP carry an explicit bytewise s=
ort. This one was called a Set in its own section heading, was carried into=
 two signatures, and was never sorted, so a register consulting three lists=
 had six conformingencodings of one attestation. Now sorted.</p> <p style=
=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> 2. The state identifie=
r was disjunctive with no discriminator. "A published version token, or a d=
igest of the published corpus where the publisher assigns none." Text in on=
e branch, digest bytes in the other, same position, no algorithm named, and=
 no statementof what the corpus is as a byte sequence. It now carries an ex=
plicit form discriminator, and the digest branch is taken over the octets t=
he publisher serves, before any decompression. That second part is the one =
I'd have got wrong: a list published as a compressedarchive has at least tw=
o byte sequences with an equal claim to being the corpus, and two registers=
 choosing differently produce two identifiers for one state, which a retroa=
ctive sweep then reads as a version change that never happened.</p> <p styl=
e=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> 3. It was carried twi=
ce with no equality rule. ARP has exactly the right sentence for this, that=
 a value carried twice with no equality rule is a value an implementation m=
ay read either way, and applied it to the two other duplicated headers and =
not to thisone.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:=
1em"> So the shape and the reason are worth lifting. The encoding is worth =
lifting as of this morning and wasn't yesterday.</p> <p style=3D"direction:=
ltr;margin-top:1em;margin-bottom:1em"> <b>On placement, Emek, your distinct=
ion deserves to be a named property of the substrate rather than a remark a=
bout two implementations.</b></p> <p style=3D"direction:ltr;margin-top:1em;=
margin-bottom:1em"> You put it as: Henri's seal is a record inside the stre=
am, signed and carried with the evidence, readable by whoever holds the set=
; Conarium's pin is an argument to the verifier, so a third party handed on=
ly the receipt set can't tell it's short unless someonestates what it shoul=
d have been, and the obvious someone is the issuer, the party the audit is =
about.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Tha=
t's sharper than the rung number alone, because two mechanisms can sit on t=
he same rung and differ entirely in who has to be asked. I'd state it as th=
ree placements:</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:=
1em"> Inside the evidence. Travels with the set, needs nobody. Henri's seal=
.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Supplied=
 by the audited party. The verifier has to be told the expected count or te=
rminal hash, and the party best placed to tell it is the one under audit. C=
onarium's pin, and you said so yourself rather than letting the symmetry fl=
atter you.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em">=
 Supplied by a party with no stake. ARP's deadline is this one: the clock i=
s started by a list publisher who's never heard of the reconciliation serve=
r.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> The thi=
rd is strongest and least available, because it only exists where the oblig=
ation happens to be triggered by something public. It isn't a design choice=
 you can make freely. Where it exists it should be used, and where it doesn=
't the statement should saywhich of the other two you're on.</p> <p style=
=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> The sweep found a four=
th case that the three-way split predicts and I hadn't looked for: a mechan=
ism sitting at the first placement whose evidence is only obtainable from t=
he second. ARP's head consistency statements are signed by independent witn=
esses, whichis the whole point of them, and the document specified the arte=
fact, the quorum arithmetic and the freshness window and specified no chann=
el by which a relying party obtains one. The obvious implementation is that=
 the responding service hands them over withits response. Every check passe=
s. The witness signature stops the service forging a statement and does not=
hing to stop it choosing which ones to pass on, so under exactly the fork t=
he mechanism exists to detect, each branch's reader gets the witnesses that=
branch was fed. Now fixed by requiring witnesses to publish on their own or=
igins and forbidding acceptance of one obtained from the responding service=
.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Worth ad=
ding to the substrate as a rule in its own right: <i>state where the eviden=
ce is obtained, not only where it is produced.</i> An artefact produced at =
the third placement and delivered by the second is at the second.</p> <p st=
yle=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> <b>Your weakest-run=
g rule already exists in ARP under another name, which I think argues it's =
the right general rule rather than a local convention.</b></p> <p style=3D"=
direction:ltr;margin-top:1em;margin-bottom:1em"> You wrote that a result wh=
ich doesn't say which rung it stands on has to be read at the weakest one, =
and that it's Walter's completeness ladder one level up.</p> <p style=3D"di=
rection:ltr;margin-top:1em;margin-bottom:1em"> ARP arrived at the same rule=
 from the verdict side and calls it verdict re-typing. An answer over a reg=
ister whose attestation can't be verified doesn't produce a weaker match, i=
t produces <code>indeterminate</code>. Where a re-notification can't say wh=
ether a change came from policy or from the underlying corpus, it has to ca=
rry <code>attribution-indeterminate</code> and name which causes were exami=
ned and why neither could be excluded, because a bare qualifier is a discre=
tionary escape signed by the party that benefits from it. And conformance r=
un records carry a <code>does_not_establish</code> field so the things a ru=
n didn't prove are enumerated rather than inferred from silence.</p> <p sty=
le=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Four instances, four=
 documents, arrived at separately: bounds in yours, populations in Walter's=
, verdicts and conformance claims in mine. Worth stating once in the substr=
ate, roughly as: <i>every result names the ground it stands on, and a resul=
t that names none is read at the weakest ground available to it.</i></p> <p=
 style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> The corollary is=
 the one implementations skip, including both of ours. The vocabulary has t=
o reach the output. You say your exit codes predate the vocabulary and stil=
l aren't a mapping of it. I found two of the same shape this week: a verifi=
er told to refusea proof with no defined way to say which of four refusals =
it made, and one reason code carrying five distinct causes because four oth=
er sections pointed at it for conditions its own definition never named. Bo=
th now split. Defining the distinction and givingthe implementation no way =
to express it is a document agreeing with itself.</p> <p style=3D"direction=
:ltr;margin-top:1em;margin-bottom:1em"> <b>On your open question about the =
boundary declaration.</b></p> <p style=3D"direction:ltr;margin-top:1em;marg=
in-bottom:1em"> You framed it well: a boundary inside the record has nothin=
g to drift from and is the stronger guarantee, but it's asserted by one par=
ty at issue time; a profile is the weaker binding and the only one that can=
 be agreed between parties before a run and pointedat afterwards by both.</=
p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> ARP's answe=
r is to make the profile a signed bilateral instrument with a hash. The agr=
eement is settled before any run, both parties compute an agreement hash ov=
er its declared items independently and have to get the same value, and eve=
ry reconciliation commitsto that hash. Drift suspends reconciliation rather=
 than producing a weaker answer. So it keeps the agreed-not-asserted proper=
ty of a profile and gains the nothing-to-drift-from property of an in-recor=
d boundary.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"=
> The cost is that it only works bilaterally. It doesn't reach a population=
 of parties who have never negotiated, which is most of Walter's setting. W=
orth having in the statement as one of the answers rather than the answer.<=
/p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> <b>Pablo, =
your precedence point generalises, and it flips direction depending on what=
's being anchored.</b> Yours is <code>anchoring_precedence</code>: the anch=
or has to be strictly earlier than the outcome it covers, because an anchor=
 arriving after the fact proves nothing about what was true when the outcom=
e was recorded. ARP's is the mirror image. The Statement has tofall later t=
han the trigger and inside a bounded interval, because what's being proved =
is that a duty was discharged on time, not that a fact was true beforehand.=
</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Same unde=
rlying requirement, that an anchor with no ordering constraint against the =
thing it covers is decorative. Two opposite orderings, because one anchors =
the proof and the other anchors the duty. I'd say it that way in the shared=
 text: every external anchordeclares its required ordering relative to what=
 it covers, and which of the two it is.</p> <p style=3D"direction:ltr;margi=
n-top:1em;margin-bottom:1em"> Agreed on normative citation over restatement=
, with one addition. Where a component is cited rather than restated, the c=
iting statement should also name the rung the component reaches. Henri's co=
rrection this morning is the case in point, and so are both ofmine above. N=
one of the three components changed. The claim made about each was one rung=
 short. A substrate that cites a component and repeats an over-broad claim =
about it has moved the error rather than removed it.</p> <p style=3D"direct=
ion:ltr;margin-top:1em;margin-bottom:1em"> Joel</p>   </blockquote> </div> =
</blockquote></div></div> </blockquote>
      </div>

