MIME-Version: 1.0
References: <1787262784652143705.1787262784@conarium.dev>
 <CALc05oFWK2_mQEB9JLRorCS5QLc0rPrJxj3BMc0r0B82ZcH_mg@mail.gmail.com>
 <1787272059233193813.1787272059@conarium.dev>
 <CALc05oGzHYVzZjWYDFCa0FYzSTHAz4_xY0wMr80j-UbPE5-UoA@mail.gmail.com>
 <z7XRDPPaX3By1sxJwdNM8-FqQMDTOW43O10genKixWn3mEz5m_xkYFwdQ324tf5_ATaSPdhnIgKg-uSwdLGy9twqj8odSf1ZqeUtNpFzzKk=@vaara.io>
In-Reply-To: 
 <z7XRDPPaX3By1sxJwdNM8-FqQMDTOW43O10genKixWn3mEz5m_xkYFwdQ324tf5_ATaSPdhnIgKg-uSwdLGy9twqj8odSf1ZqeUtNpFzzKk=@vaara.io>
From: Pablo Play <playplay2736@gmail.com>
Date: Fri, 21 Aug 2026 06:32:34 -0300
Message-ID: 
 <CANWAHpowbgTkTmMQ-sDs1pgZF-UAgfLxZN+DqfWLxLyMPY_E-w@mail.gmail.com>
To: Henri Sirkkavaara <hello@vaara.io>
Content-Type: multipart/alternative; boundary="000000000000b920d906598b51d0"
Message-ID-Hash: M3ALI6HO5NJ37JUYY3RD6T2QT6S3JZMF
CC: Walter Hawkins <wdhawkins46@gmail.com>, e.dogru@conarium.dev,
 scitt@ietf.org, jhillier@certisyn.com, nenadvasic@protonmail.com,
 Todd.Gibson@t-mobile.com
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?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/scitt/LoudEdvGtL5RgnVdo0wRtIbeTW4>

--000000000000b920d906598b51d0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Henri, all =E2=80=94

  Second empirical data point under the closed-enum property, from a
different mechanism than
  Vaara's release condition but the same shape: a binary result whose
reasons already
  partition into two non-overlapping categories, documented additively
rather than widening
  the enum.

  verify_chain() in our stack returns valid: false for two structurally
different situations
  =E2=80=94 a trail that was never reachable to evaluate, and one that was =
read
completely and failed
  a real check. The read path is binary by construction (single-row lookup,
no partial
  reads), so trail_not_found always runs first against the raw result, and
everything
  evaluated after it =E2=80=94 including missing_signature_ref =E2=80=94 is=
 a check against
a record we
  already read in full. That gives a clean partition without touching the
valid contract:

    trail_not_found                  -> unreached
    missing_signature_ref            -> ran-and-failed
    delegation_ref_parent_mismatch   -> ran-and-failed
    cycle_detected                   -> ran-and-failed

  Merged as-is, 69 lines added, 0 removed (commit e12658d,
  github.com/giskard09/argentum-core, negotiation-ref.md).

  Same underlying rule as your blocked-but-verified receipt: a value that
resolves cleanly
  deserves its own place in the partition, not a collapse into whichever
adjacent state is
  easiest to code against.

  =E2=80=94 Pablo

El vie, 21 ago 2026 a la(s) 2:28=E2=80=AFa.m., Henri Sirkkavaara (hello@vaa=
ra.io)
escribi=C3=B3:

> Nenad, Walter, Joel, Pablo, Emek, Todd,
>
> The principal row is right and I would take it further than a row. Your
> revocation case and the receiver's settlement case are the same shape at
> two different levels, and neither party can be substituted for the other,
> which by this thread's own argument puts the vantage question in the
> substrate rather than in any one draft.
>
> On the closed-enum property, I have something to put under it rather than
> another agreement.
>
> Vaara 1.71.0 ships a release condition: money is held against a signed
> statement of what must be proved, and a receipt proving the authorised
> action happened is what releases it. Evaluation returns one of four state=
s,
> each carrying a reason from a closed set. The mapping from reason to stat=
e
> is a table, not control flow, so no code path can file a forgery under a
> hold.
>
> The partition runs on one axis. A broken signature, a receipt under a key
> the condition does not pin, or evidence that does not resolve to the dige=
st
> the receipt signed are failures as evidence, and they refuse. A missing
> receipt, a receipt for another action, another authorization, or one that
> soundly proves a refusal are sound and insufficient, and they hold.
> Soundness is checked before the clock, so an expired window cannot swallo=
w
> a tampering finding.
>
> Eight vectors in tests/vectors/release_condition_v0, all four states
> present, and a checker that imports no Vaara and recomputes every verdict
> from the case bytes. Among them is a receipt that verifies correctly and
> proves the action was blocked. It must not release, and treating it as a
> plain false would put it in the same state as a forgery.
>
> DOI 10.5281/zenodo.22029444 if it is useful to cite the exact bytes.
>
> *Henri Sirkkavaara*
> *Vaara *- Runtime execution layer for AI agents
> *Built to see over the noise.*
> vaara.io
> Helsinki, Finland
>
> On Friday, August 21st, 2026 at 04:10, Walter Hawkins <
> wdhawkins46@gmail.com> wrote:
>
> Emek,
>
> You came back with the check and what it caught, so here is mine =E2=80=
=94 same
> shape, a day behind you.
>
> The rule, as shipped. An anchored sequence moves a verifier's floor only
> when all of the following hold: the calldata parses and names this grant;
> the key segment equals the grant's accountant; the anchored content was
> actually retrieved; the anchor digest recomputes over the retrieved head;
> the head's signature verifies; and the head itself names this grant, this
> accountant, and this sequence. Anything short of that is ignored with a
> warning naming the reason, and a refusal can only lower the floor toward
> the tamper-evidence downgrade, never raise it. The old scan =E2=80=94 the=
 one that
> trusts the sequence printed in calldata =E2=80=94 survives under an UNVER=
IFIED
> label for survey work, because a claimed sequence is still a lead worth
> following. It is no longer anything a verifier may refuse an honest head
> against.
>
> Shown failing before wired in, on your reasoning that a check which has
> only ever been green demonstrates nothing. Four controls:
>
> - The forged-key attack from my last message, run for real: a stranger's
> anchor claiming sequence 999999999 under the accountant's public key. The
> unverified scan reads 999999999 =E2=80=94 poisoned exactly as I described=
 it two
> days ago. The verified scan holds the floor at the genuine head and print=
s
> a warning naming the anchor it ignored.
>
> - An anchor whose retrieved head does not reproduce the anchored digest:
> no floor movement.
>
> - Calldata claiming one sequence over a head that states another: no floo=
r
> movement.
>
> - No qualifying anchor at all: the floor is null, and null is not zero. "=
I
> could not derive a floor" is the labelled tamper-evidence downgrade, not =
a
> fact about sequence 0.
>
> What it caught immediately: my own anchor. The only anchor we have ever
> written to a chain =E2=80=94 the Coston2 transaction at block 34259963 th=
at I
> brought to this thread as evidence =E2=80=94 is refused by the rule it mo=
tivated. I
> read its calldata back off the chain today: it parses, and it carries no
> key segment at all, because the grammar predates the hardening; the head =
it
> points to predates the accountant field. Two independent grounds, either
> one fatal to floor-eligibility. Your check's first catch was your own
> sentence; mine refused my own anchor. It stays in the record, labelled, a=
s
> tamper evidence of the day the wiring first worked =E2=80=94 which is exa=
ctly as
> much as the hardened rule permits it to be. The lesson I passed on last
> time, that we anchored a shape we were still editing, now has an
> enforcement mechanism instead of a caveat.
>
> Your 14-versus-15 split is in here too, arrived at separately. An anchor
> whose content cannot be fetched is ignored with "content not retrieved, s=
o
> its sequence is unverified" =E2=80=94 could-not-check never gets swallowe=
d into
> failed, and never silently reads as verified. The null-rather-than-zero
> floor is the same rule one level up. I'd add both of ours to the pile Joe=
l
> is counting: the weakest-rung rule keeps being reinvented at whatever lay=
er
> someone is standing on, which is the strongest argument yet that it belon=
gs
> in the substrate stated once.
>
> Two limits, stated now rather than found later.
>
> First, the verifier takes the retrieved heads as inputs; where they came
> from is outside the rule. Joel's placement rule =E2=80=94 state where the=
 evidence
> is obtained, not only where it is produced =E2=80=94 lands on this with f=
ull force.
> A verifier handed heads by the executor it is auditing has re-derived at
> the second placement, and the result object should say so. Mine does not
> yet distinguish the placements; that is the next honest gap.
>
> Second, floor-eligibility depends on retrievability, so the floor's
> strength decays with content availability. An adversary who cannot forge =
a
> floor can still lower one by making anchored content unfetchable. That
> fails in the right direction =E2=80=94 a downgrade rather than honest hea=
ds refused
> =E2=80=94 but it is a downgrade an attacker can induce, and the record ha=
s to name
> it, or "no floor" reads as "nothing was ever anchored", which is a
> different claim.
>
> Walter
>
> On Thu, Aug 20, 2026 07:27 PM, e.dogru@conarium.dev wrote:
>
>> All,
>>
>> 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 end, because it turned out=
 I
>> could check it rather than argue it.
>>
>> The problem is in -05 in my own words: four sentences in the
>> Implementation Status section of -04 were accurate the day they were
>> written and false within days, every one of them claiming less than the
>> code did, and nothing in the repository compared that section to the too=
l.
>> They were found by a reader holding the document beside the output.
>>
>> The check runs the section instead of reading it. Three declarations of
>> one fact exist: the code, the prose, and now a claim table between them,
>> because prose cannot be executed. Each behavioural sentence is bound to =
a
>> run of the shipped CLI over a named fixture, and two directions are
>> enforced. Every value a run produced must still appear in the sentence t=
hat
>> states it, and the number of sentences must equal the number of claims. =
A
>> sentence with no claim is one nothing measures. A claim with no sentence=
 is
>> a measurement the document dropped.
>>
>> The revision it reads is derived from what is in the repository rather
>> than named in the check, because a hard-coded revision is the same class=
 of
>> stale declaration the check exists to catch.
>>
>> I showed it failing three ways before wiring it in, since a check that
>> has only ever been green demonstrates nothing:
>>
>> a value edited out of a sentence
>> -> the sentence no longer contains observed-without-receipt
>> one bullet removed
>> -> states 4 observed behaviour(s), the claim table runs 5
>> a fixture changed so the tool's outcome moved, sentence untouched
>> -> item outcomes are ["excluded","indeterminate"],
>> the table says ["excluded","observed-without-receipt"]
>>
>> The third is the one that matters: the code moved and the sentence stood
>> still, which is what happened four times in -04.
>>
>> What it caught immediately is a sentence of mine. -05 says "The
>> implementation's test suite contains no check that compares this section
>> 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.
>>
>> Two limits, stated now rather than discovered later. It 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: change the
>> code back, or write the revision that says what the code now does. Editi=
ng
>> a posted draft is not one of them, which makes the cost of drift a docum=
ent
>> rather than a diff.
>>
>> Walter, on rung 3. You put it as: an external anchor is not automaticall=
y
>> rung 3, an anchor is a claim by whoever paid for it, and a profile that
>> says "anchored" without saying "and re-derived" has described rung 2 wit=
h
>> extra steps. I went and looked rather than answering from memory, and th=
e
>> implementation agrees with you, which I did not know for certain before =
you
>> wrote it.
>>
>> --anchor-check deserialises the timestamp proof, refuses a proof whose
>> digest is not the chain head, walks the attestations, and where the
>> attestation is Bitcoin it fetches that block and compares the digest
>> against the merkle root. So the re-derivation is in the path and not in =
the
>> prose.
>>
>> The part I would not have thought to defend, and which your framing is
>> the reason to mention: it separates two answers that a single 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 fetched, exits
>> 15, and 15 is evaluated first, so "I could not check" never gets swallow=
ed
>> 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 applied =
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.
>>
>> Emek
>>
>>
>> On Fri, Aug 21, 2026 at 2:50 AM Walter Hawkins <wdhawkins46@gmail.com>
>> wrote:
>>
>> Henri, Joel, Emek, Pablo, Nenad, Todd,
>>
>> Two corrections of my own before the part I owe this thread, since that
>> appears
>> to be the going rate here and it's a good rate.
>>
>> **One.** I used the words "omission-proof" in my own notes and it was a
>> rung
>> short. Our spend log is chained and gap-free under a signed grant, and
>> the head
>> that seals it is counter-signed by a named accountant carrying a root an=
d
>> a
>> running total. That much I had right =E2=80=94 it's rung 2. What I had w=
rong was
>> the
>> floor. A verifier arriving for the first time, holding no prior state an=
d
>> doing
>> no anchor lookup, accepts an old validly-signed head together with the
>> prefix
>> that matches it. Monotonic sequence, perfect arithmetic, short set.
>> Henri's
>> correction this morning is the same shape as mine, and I'd made mine a d=
ay
>> earlier without noticing what it cost.
>>
>> Fixed the way Emek's rule says it should be: the freshness floor is now =
a
>> required argument, and passing nothing is an explicit downgrade whose
>> verdict
>> is labelled tamper-evidence rather than completeness. The weakest-rung
>> rule
>> applied to an argument I had made optional.
>>
>> **Two, and this is the one I think is worth the thread's time, because
>> it's a
>> hole in rung 3 itself.**
>>
>> We put our heads on-chain: a zero-value transaction whose calldata
>> carries the
>> head digest, the grant it covers, the sequence, and the key that signed
>> it. A
>> first-contact verifier scans for those and takes the highest sequence as
>> its
>> floor. That is the external anchor the ladder asks for, and two days ago
>> I'd
>> have told you it put us at rung 3.
>>
>> Anchoring is permissionless. That property is why it resists censorship
>> and it
>> is also the attack. Anyone can write that calldata. The key field is
>> plaintext,
>> and the accountant's key is public because it's named in the grant. So a
>> stranger writes an anchor for my grant at sequence 999999999, my scanner
>> reads
>> it, and every honest head I produce afterwards is refused as a rollback.
>> The
>> floor is poisonable by anyone willing to pay for one transaction, and th=
e
>> failure mode isn't a missed omission =E2=80=94 it's an honest record per=
manently
>> refused. We had traded a false negative for a false positive against
>> ourselves,
>> which is the worse of the two trades.
>>
>> The fix is that an anchored sequence cannot be read as a fact. It is a
>> pointer.
>> A verifier deriving a floor has to fetch the anchored bytes, recompute t=
he
>> digest over them, check the signature, and check that the head it just
>> verified
>> names this grant and this sequence =E2=80=94 and only then let it move t=
he floor.
>> An
>> anchor whose content can't be retrieved simply isn't floor-eligible,
>> which can
>> only lower the floor toward the tamper-evidence downgrade, never raise i=
t.
>>
>> Stated honestly about where we are with it: that rule is written into ou=
r
>> spec
>> text and our scanner does not yet do it. What the scanner does today is
>> the
>> cheap half =E2=80=94 it ignores anchors that don't name the grant's acco=
untant,
>> which
>> closes the stranger-with-no-key case and leaves the forged-key case open=
,
>> because that field is unauthenticated. So take the paragraph above as a
>> claim
>> about what rung 3 requires, not a claim about what I've shipped. The
>> re-derivation is the next thing I write, and I'll come back with what it
>> caught.
>>
>> So for the statement I'd put it this way: an external anchor is not
>> automatically rung 3. An anchor is a claim by whoever paid for it. Rung =
3
>> is
>> an anchor plus the verification that recovers what it points at, and a
>> profile
>> that says "anchored" without saying "and re-derived" has described rung =
2
>> with
>> extra steps. Nenad, I think this bears directly on precedence =E2=80=94 =
ordering a
>> revocation strictly against a settlement only means something if both
>> anchored
>> objects are re-derived first; otherwise you've ordered two assertions.
>>
>> **What I owe: the rail enumeration.**
>>
>> Every payment under a grant carries a binding in the one payer-chosen
>> slot the
>> rail's own signature covers =E2=80=94 the EIP-3009 nonce, the Permit2 no=
nce, the
>> XRPL
>> InvoiceID. The value is a domain-separated digest over the grant digest
>> and the
>> payment identifier, so it's derivable by anyone holding those two and
>> recomputable from the settled transaction by anyone holding that.
>>
>> The receiver's use is the part this thread wants. A payee holding a
>> settled
>> transaction recovers which grant and which payment it commits to from th=
e
>> artefact itself, without asking the executor which authorisation it woul=
d
>> like
>> to be judged under. And the enumeration runs off the rail rather than of=
f
>> a
>> list: the payee walks settled transactions to their own address, not a
>> set the
>> executor hands them. A leg the executor never wrote down is still on the
>> rail
>> if the money moved, and the party holding it is the party who cannot be
>> made to
>> un-know it arrived.
>>
>> Testnet EVM rail, as promised: Coston2. A head anchored as a real
>> transaction at
>> block 34259963, the calldata read back off the chain and matched against
>> the
>> signed head, block timestamp doing the ordering.
>>
>> With a caveat that belongs in this thread more than most. That anchor
>> predates
>> the hardening I described above =E2=80=94 its commitment has no accounta=
nt field
>> and its
>> calldata has no key segment, so it verifies against the code as of the
>> commit
>> that produced it and not against current HEAD. I keep it as evidence tha=
t
>> the
>> wiring worked on the day, and as a small lesson I'd pass on: we anchored
>> a shape
>> we were still editing, and permanence is the one property an anchor has
>> whether
>> or not you were finished. New heads use the hardened shape. I'll bring
>> both,
>> labelled.
>>
>> Two limits I'd rather state than have found.
>>
>> The rail has to enforce slot uniqueness for once-per-payment to come fre=
e.
>> EIP-3009 and Permit2 consume the nonce, so it does. XRPL does not enforc=
e
>> InvoiceID uniqueness =E2=80=94 two Payments carrying the same InvoiceID =
both
>> settle =E2=80=94
>> so anyone deriving a cumulative total from XRPL evidence has to
>> de-duplicate by
>> (grant, payment) and cannot lean on the rail for it.
>>
>> The second one I had wrong until a review pulled it apart yesterday, and
>> it
>> generalises past payments. The binding identifies the grant; it does not
>> bound
>> the amount. The slot commits to the grant and the payment identifier and
>> nothing else, so an agent holding the payer key can settle a million
>> against a
>> payment it reports as one. The cap only binds if the verifier reads
>> amount,
>> recipient and asset out of the settled transaction and compares them bac=
k
>> to
>> the grant. I had a document claiming one artefact proved both that money
>> moved
>> and that it moved within authority, and that sentence was doing work the
>> mechanism didn't do. Identifying which authorisation governed an act is
>> not
>> the same as bounding the act performed under it =E2=80=94 Nenad, that's =
your item
>> 2
>> from the other end, and I think it's a second thing the substrate should
>> say
>> outright, because the failure is invisible and every incentive points at
>> it.
>>
>> The object model and its vectors are public as of today, as an open PR
>> rather
>> than anything settled: specs/extensions/authority.md and
>> authority-vectors.json in x402-foundation/x402 #3220. If the statement
>> cites
>> components normatively the way Henri suggests, that's the published home
>> for
>> the rail-binding piece, under the same one-authority rule Nenad named.
>>
>> **Nenad's fourth vantage.**
>>
>> I think it's right and I'd add a note from our side. We have no
>> revocation, and
>> that's deliberate rather than missing: our grants carry an expiry, and
>> authority
>> decays without anyone needing to deliver anything. A suppressed
>> revocation is
>> invisible to a receiver, as you say =E2=80=94 but you can't suppress the=
 passage
>> of
>> time. It's a real trade, not a free win: a short expiry means re-issuanc=
e
>> traffic and a live principal, and a long one means a wide window where
>> your
>> attack is exactly as bad as you describe. Where re-issuance is affordabl=
e,
>> expiry is revocation you don't have to deliver, and I'd rather the
>> substrate
>> name that as an option than have every profile carry a revocation channe=
l
>> it
>> can't guarantee reaches anyone.
>>
>> **Joel's fourth item.**
>>
>> Same answer as Henri, Pablo and Nenad: we don't have it. Nothing in our
>> records
>> pins the publisher-assigned version of any corpus a decision was compute=
d
>> against. Four for four is a better argument for lifting it into the
>> substrate
>> than any of us adding a field and then citing ourselves.
>>
>> **Willing, and here's what I bring.**
>>
>> The rail-enumeration binding above, the Coston2 fixtures, and the rung-3
>> refinement =E2=80=94 anchor as pointer, not fact. Henri, the completenes=
s
>> component and
>> its rungs stay yours to state; Todd, the fraud side is what keeps this
>> attached
>> to a real failure; and if Emek's ladder is going to carry the structure
>> of the
>> document, it should carry his name in it.
>>
>> Walter
>>
>> On Thu, Aug 20, 2026 04:53 PM, e.dogru@conarium.dev wrote:
>>
>>> Joel, Henri, Pablo, Walter, Todd, Nenad,
>>>
>>> Joel, you withdrew two claims in public before making your argument. I
>>> will put something of the same kind on the table before making mine.
>>>
>>> The corollary you name is the half I have not done, and I can show you
>>> exactly where the line falls.
>>>
>>> You wrote that the vocabulary has to reach the output, and that both ou=
r
>>> implementations skip it. In mine the /2 result carries a bounds object:=
 for
>>> each bound the comparison relied on, its source is protocol-defined,
>>> measured, operator-declared, or undeclared, and a result whose bounds a=
re
>>> operator-declared states an outcome of that standing and no stronger.
>>> Measured against the published package, one fixture, a receipt three
>>> seconds outside a two-hour window:
>>>
>>> - no profile: all three bounds undeclared, both items indeterminate
>>> - a profile with no clocks member: multiplicity and exclusion
>>> operator-declared, skew still undeclared
>>> - clocks.skew declared wider than the offset: operator-declared, and th=
e
>>> item stays indeterminate. A declaration does not manufacture a match.
>>> - clocks.skew declared narrower than the offset: the same item becomes
>>> observed-without-receipt
>>>
>>> So the vocabulary reaches that object. It does not reach the exit codes=
,
>>> which predate it and are still not a mapping of it. Your sentence cover=
s
>>> precisely the half I have not done, and I would rather that stayed in t=
he
>>> record than get answered with a plan.
>>>
>>> The three clocks fields you asked for are in -05 with their encoding:
>>> clocks.observation, clocks.receipt, clocks.skew, a duration grammar, a =
rule
>>> that an unknown key in clocks is rejected by name, and a rule that the =
same
>>> bound declared twice must parse to the same milliseconds or the run fai=
ls
>>> rather than picking one. Written to be borrowed, not restated.
>>>
>>> On placement. The distinction is in -05 as a security consideration
>>> (sec-completeness), written against my own implementation rather than a=
bout
>>> two of them: a truncated receipt set verifies, detecting the removal ne=
eds
>>> a quantity from outside it, and whether that quantity reached the verif=
ier
>>> independently of the Issuer is not visible in a digest. I support lifti=
ng
>>> it to the substrate, with one caveat about how it is worded there. The
>>> property that matters is not "in-record 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 carrying it; stated a=
s a
>>> disclosure obligation it does not.
>>>
>>> On the weakest-rung rule. Four documents arriving at it separately is 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, becau=
se
>>> 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
>>> allowed to average it, and the pressure to fold it into a coverage
>>> percentage arrives from outside engineering, after the vocabulary is pu=
blic
>>> and looks like a scoring system.
>>>
>>> One more thing worth putting in the record. Your sentence from two days
>>> ago, that a gaps section going stale understating an implementation fai=
ls
>>> the same way as one that overstates, turned out to apply to mine four t=
imes
>>> over. Each statement was accurate when written and false within days,
>>> always in the direction of claiming less than the code did, and nothing=
 in
>>> my test suite compares that section 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 che=
ck
>>> that would notice if they did. That is the gap I would most like the
>>> substrate to make expensive to leave open, and it is the next thing I w=
rite
>>> on my own side. I will come back with the check and what it caught, rat=
her
>>> than with a plan.
>>>
>>> Emek Can Dogru
>>> Conarium
>>>
>>>
>>> On Fri, Aug 21, 2026 at 12:06 AM Joel Hillier <jhillier=3D
>>> 40certisyn.com@dmarc.ietf.org> wrote:
>>>
>>> Hi Henri, Pablo, Walter, Todd,
>>>
>>> Emek, 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 you with cloning at befdced and running the three cases, which
>>> is 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 th=
e
>>> 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.
>>>
>>> *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=
.*
>>>
>>> Each Evaluation Sweep Statement carries the 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" and it applies =
to
>>> my series exactly as it applies to yours: a truncatedtail of Sweep
>>> Statements verifies precisely as it did before.
>>>
>>> What actually puts ARP at rung 3 is a different mechanism, which I'd
>>> been crediting to the chain. Each Statement is due inside a bounded
>>> interval measured from its trigger, and where the trigger is a public e=
vent
>>> with a public timestamp, a sanctions list publishinga delta starts a cl=
ock
>>> the operator doesn't own. An operator with no Statement inside the inte=
rval
>>> hasn't evaluated in time, and anyone can check that holding none of the
>>> set. The chain covers the middle. The deadline covers the tail. Two
>>> mechanisms, and I'dhad them credited as one.
>>>
>>> *Correction two, and this one is worse, because it's the sentence where
>>> I congratulated myself on not rounding up.*
>>>
>>> I said the falsifiability argument holds for three of ARP's four
>>> triggers, "stated rather than rounded up." Only one of those three rest=
ed
>>> on anything outside the reconciliation server. The other two rested 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
>>> transition 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 the count wasone in four, and the sentence claiming otherwise w=
as
>>> the one place the document rounded up.
>>>
>>> It's three in four now because I fixed the mechanism rather than the
>>> sentence: the document carries a publication timestamp, is notarised on=
 the
>>> ledger-head interval, and has to be republished on that interval whethe=
r or
>>> not anything in it changed. That lastpart is the one that matters, and =
it's
>>> your placement argument doing the work. Without it, an operator that
>>> removed a witness entry and an operator that changed nothing publish th=
e
>>> same thing, and the notarised series has no entry to be missing.
>>>
>>> The claim is now conditional and the document says so: a deployment
>>> whose policy parameters 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 published.
>>>
>>> *One more, since it's the mechanism I described to Walter yesterday.* I
>>> said ARP's witness quorum counts entries under common control once, bec=
ause
>>> two instances of one observer aren't two observers. The distinctness te=
st
>>> was written over the operating-partyidentifier alone and said nothing a=
bout
>>> the keys. Two entries declaring the same key under two different party
>>> identifiers satisfied a quorum of two with a single signature. Both ent=
ries
>>> verify, the identifiers are distinct, and a relying party doing exactly=
what
>>> the document said counted one signer twice. Now fixed by requiring the
>>> verification method references to be pairwise distinct as well.
>>>
>>> Worth separating that from the limit I did state correctly. Whether two
>>> named parties are genuinely independent can't be tested by a verifier a=
nd
>>> the document concedes it. Whether two entries name one key can always b=
e
>>> tested, and wasn't.
>>>
>>> *Now the thing I owe this thread.*
>>>
>>> Henri and Pablo have both said they'd need to add the fourth item befor=
e
>>> they could point at one, and Henri's suggested the substrate cite
>>> components normatively rather than restate them. Together that means th=
e
>>> fourth item gets lifted out of ARP. So let mehand it over along with wh=
at
>>> was wrong with it, rather than after it's in shared text.
>>>
>>> A Partial Attestation carries a Source-Data Version Identifier Set: one
>>> identifier per source consulted in evaluating the predicate. Each is a
>>> tuple of the list name as declared in the bilateral agreement, and the
>>> state identifier the list publisher assignsto that state, not a value t=
he
>>> answering party made up. It rides in the protected header so it's cover=
ed
>>> by the register's signature, and it's carried into the output so it's
>>> covered by the sealing signature.
>>>
>>> The reason it's the publisher's identifier and not the register's is th=
e
>>> part worth carrying into any shared text, because it isn't obvious and =
it's
>>> the whole point. A register-chosen opaque string would be an
>>> arbitrary-bandwidth channel from register to relyingparty, travelling u=
nder
>>> signature into a sealed and ledgered artefact, and the accompanying rul=
e
>>> that differing identifiers mustn't be read as disagreement would normal=
ise
>>> it. Taking the identifier from the publisher's own state sequence is wh=
at
>>> makes it evidenceinstead of a side channel.
>>>
>>> Three things were wrong with the encoding, all found yesterday, all now
>>> repaired:
>>>
>>> 1. The Set had no ordering rule. Five other collections in ARP carry an
>>> explicit bytewise sort. 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.
>>>
>>> 2. The state identifier was disjunctive with no discriminator. "A
>>> published version token, or a digest of the published corpus where the
>>> publisher assigns none." Text in one branch, digest bytes in the other,
>>> same position, no algorithm named, and no statementof what the corpus i=
s as
>>> a byte sequence. It now carries an explicit form discriminator, and the
>>> digest branch is taken over the octets the 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 two byte sequences with a=
n
>>> equal claim to being the corpus, and two registers choosing differently
>>> produce two identifiers for one state, which a retroactive sweep then r=
eads
>>> as a version change that never happened.
>>>
>>> 3. It was carried twice with no equality rule. ARP has exactly the righ=
t
>>> sentence for this, that a value carried twice with no equality rule is =
a
>>> value an implementation may read either way, and applied it to the two
>>> other duplicated headers and not to thisone.
>>>
>>> So the shape and the reason are worth lifting. The encoding is worth
>>> lifting as of this morning and wasn't yesterday.
>>>
>>> *On placement, Emek, your distinction deserves to be a named property o=
f
>>> the substrate rather than a remark about two implementations.*
>>>
>>> You put it as: Henri's seal is a record inside the stream, 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 only the
>>> receipt set can't tell it's short unless someonestates what it should h=
ave
>>> been, and the obvious someone is the issuer, the party the audit is abo=
ut.
>>>
>>> That's sharper than the rung number alone, because two mechanisms can
>>> sit on the same rung and differ entirely in who has to be asked. I'd st=
ate
>>> it as three placements:
>>>
>>> Inside the evidence. Travels with the set, needs nobody. Henri's seal.
>>>
>>> Supplied by the audited party. The verifier has to be told the expected
>>> count or terminal hash, and the party best placed to tell it is the one
>>> under audit. Conarium's pin, and you said so yourself rather than letti=
ng
>>> the symmetry flatter you.
>>>
>>> Supplied by a party with no stake. ARP's deadline is this one: the cloc=
k
>>> is started by a list publisher who's never heard of the reconciliation
>>> server.
>>>
>>> The third is strongest and least available, because it only exists wher=
e
>>> the obligation happens to be triggered by something public. It isn't a
>>> design choice you can make freely. Where it exists it should be used, a=
nd
>>> where it doesn't the statement should saywhich of the other two you're =
on.
>>>
>>> The sweep found a fourth case that the three-way split predicts and I
>>> hadn't looked for: a mechanism sitting at the first placement whose
>>> evidence is only obtainable from the second. ARP's head consistency
>>> statements are signed by independent witnesses, whichis the whole point=
 of
>>> them, and the document specified the artefact, the quorum arithmetic an=
d
>>> the freshness window and specified no channel by which a relying party
>>> obtains one. The obvious implementation is that the responding service
>>> hands them over withits response. Every check passes. The witness signa=
ture
>>> stops the service forging a statement and does nothing to stop it choos=
ing
>>> which ones to pass on, so under exactly the fork the mechanism exists t=
o
>>> detect, each branch's reader gets the witnesses thatbranch was fed. Now
>>> fixed by requiring witnesses to publish on their own origins and forbid=
ding
>>> acceptance of one obtained from the responding service.
>>>
>>> Worth adding to the substrate as a rule in its own right: *state where
>>> the evidence is obtained, not only where it is produced.* An artefact
>>> produced at the third placement and delivered by the second is at the
>>> second.
>>>
>>> *Your weakest-rung rule already exists in ARP under another name, which
>>> I think argues it's the right general rule rather than a local conventi=
on.*
>>>
>>> You wrote that a result which doesn't say which rung it stands on has t=
o
>>> be read at the weakest one, and that it's Walter's completeness ladder =
one
>>> level up.
>>>
>>> ARP arrived at the same rule from the verdict side and calls it verdict
>>> re-typing. An answer over a register whose attestation can't be verifie=
d
>>> doesn't produce a weaker match, it produces indeterminate. Where a
>>> re-notification can't say whether a change came from policy or from the
>>> underlying corpus, it has to carry attribution-indeterminate and name
>>> which causes were examined and why neither could be excluded, because a
>>> bare qualifier is a discretionary escape signed by the party that benef=
its
>>> from it. And conformance run records carry a does_not_establish field
>>> so the things a run didn't prove are enumerated rather than inferred fr=
om
>>> silence.
>>>
>>> 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 substrate, roughly as: *every result names the
>>> ground it stands on, and a result that names none is read at the weakes=
t
>>> ground available to it.*
>>>
>>> The corollary is the one implementations skip, including both of ours.
>>> The vocabulary has to reach the output. You say your exit codes predate=
 the
>>> vocabulary and still aren't a mapping of it. I found two of the same sh=
ape
>>> this week: a verifier told to refusea proof with no defined way to say
>>> which of four refusals it made, and one reason code carrying five disti=
nct
>>> causes because four other sections pointed at it for conditions its own
>>> definition never named. Both now split. Defining the distinction and
>>> givingthe implementation no way to express it is a document agreeing wi=
th
>>> itself.
>>>
>>> *On your open question about the boundary declaration.*
>>>
>>> You framed it well: a boundary inside the record has nothing to drift
>>> from and is the stronger guarantee, but it's asserted by one party at i=
ssue
>>> time; a profile is the weaker binding and the only one that can be agre=
ed
>>> between parties before a run and pointedat afterwards by both.
>>>
>>> ARP's answer is to make the profile a signed bilateral instrument with =
a
>>> hash. The agreement is settled before any run, both parties compute an
>>> agreement hash over its declared items independently and have to get th=
e
>>> same value, and every reconciliation commitsto that hash. Drift suspend=
s
>>> reconciliation rather than producing a weaker answer. So it keeps the
>>> agreed-not-asserted property of a profile and gains the
>>> nothing-to-drift-from property of an in-record boundary.
>>>
>>> The cost is that it only works bilaterally. It doesn't reach a
>>> population of parties who have never negotiated, which is most of Walte=
r's
>>> setting. Worth having in the statement as one of the answers rather tha=
n
>>> the answer.
>>>
>>> *Pablo, your precedence point generalises, and it flips direction
>>> depending on what's being anchored.* Yours is anchoring_precedence: the
>>> anchor has to be strictly earlier than the outcome it covers, because a=
n
>>> anchor arriving after the fact proves nothing about what was true when =
the
>>> outcome was recorded. ARP's is the mirror image. The Statement has tofa=
ll
>>> later than the trigger and inside a bounded interval, because what's be=
ing
>>> proved is that a duty was discharged on time, not that a fact was true
>>> beforehand.
>>>
>>> Same underlying requirement, that an anchor with no ordering constraint
>>> against the thing it covers is decorative. Two opposite orderings, beca=
use
>>> one anchors the proof and the other anchors the duty. I'd say it that w=
ay
>>> in the shared text: every external anchordeclares its required ordering
>>> relative to what it covers, and which of the two it is.
>>>
>>> Agreed on normative citation over restatement, with one addition. Where
>>> a component is cited rather than restated, the citing statement should =
also
>>> name the rung the component reaches. Henri's correction this morning is=
 the
>>> case in point, and so are both ofmine above. None of the three componen=
ts
>>> 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 th=
e
>>> error rather than removed it.
>>>
>>> Joel
>>>
>>>
>

--000000000000b920d906598b51d0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Henri, all =E2=80=94<br><br>=C2=A0 Second empirical data p=
oint under the closed-enum property, from a different mechanism than<br>=C2=
=A0 Vaara&#39;s release condition but the same shape: a binary result whose=
 reasons already<br>=C2=A0 partition into two non-overlapping categories, d=
ocumented additively rather than widening<br>=C2=A0 the enum.<br><br>=C2=A0=
 verify_chain() in our stack returns valid: false for two structurally diff=
erent situations<br>=C2=A0 =E2=80=94 a trail that was never reachable to ev=
aluate, and one that was read completely and failed<br>=C2=A0 a real check.=
 The read path is binary by construction (single-row lookup, no partial<br>=
=C2=A0 reads), so trail_not_found always runs first against the raw result,=
 and everything<br>=C2=A0 evaluated after it =E2=80=94 including missing_si=
gnature_ref =E2=80=94 is a check against a record we<br>=C2=A0 already read=
 in full. That gives a clean partition without touching the valid contract:=
<br><br>=C2=A0 =C2=A0 trail_not_found =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0-&gt; unreached<br>=C2=A0 =C2=A0 missing_signatu=
re_ref =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-&gt; ran-and-failed<br>=C2=
=A0 =C2=A0 delegation_ref_parent_mismatch =C2=A0 -&gt; ran-and-failed<br>=
=C2=A0 =C2=A0 cycle_detected =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 -&gt; ran-and-failed<br><br>=C2=A0 Merged as-is, 69 lines=
 added, 0 removed (commit e12658d,<br>=C2=A0 <a href=3D"http://github.com/g=
iskard09/argentum-core">github.com/giskard09/argentum-core</a>, negotiation=
-ref.md).<br><br>=C2=A0 Same underlying rule as your blocked-but-verified r=
eceipt: a value that resolves cleanly<br>=C2=A0 deserves its own place in t=
he partition, not a collapse into whichever adjacent state is<br>=C2=A0 eas=
iest to code against.<br><br>=C2=A0 =E2=80=94 Pablo</div><br><div class=3D"=
gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">El=
 vie, 21 ago 2026 a la(s) 2:28=E2=80=AFa.m., Henri Sirkkavaara (<a href=3D"=
mailto:hello@vaara.io">hello@vaara.io</a>) escribi=C3=B3:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial,s=
ans-serif;font-size:14px"><span>Nenad, Walter, Joel, Pablo, Emek, Todd,</sp=
an><div><br></div><div><span>The principal row is right and I would take it=
 further than a row. Your revocation case and the receiver&#39;s settlement=
 case are the same shape at two different levels, and neither party can be =
substituted for the other, which by this thread&#39;s own argument puts the=
 vantage question in the substrate rather than in any one draft.</span></di=
v><div><br></div><div><span>On the closed-enum property, I have something t=
o put under it rather than another agreement.</span></div><div><br></div><d=
iv><span>Vaara 1.71.0 ships a release condition: money is held against a si=
gned statement of what must be proved, and a receipt proving the authorised=
 action happened is what releases it. Evaluation returns one of four states=
, each carrying a reason from a closed set. The mapping from reason to stat=
e is a table, not control flow, so no code path can file a forgery under a =
hold.</span></div><div><br></div><div><span>The partition runs on one axis.=
 A broken signature, a receipt under a key the condition does not pin, or e=
vidence that does not resolve to the digest the receipt signed are failures=
 as evidence, and they refuse. A missing receipt, a receipt for another act=
ion, another authorization, or one that soundly proves a refusal are sound =
and insufficient, and they hold. Soundness is checked before the clock, so =
an expired window cannot swallow a tampering finding.</span></div><div><br>=
</div><div><span>Eight vectors in tests/vectors/release_condition_v0, all f=
our states present, and a checker that imports no Vaara and recomputes ever=
y verdict from the case bytes. Among them is a receipt that verifies correc=
tly and proves the action was blocked. It must not release, and treating it=
 as a plain false would put it in the same state as a forgery.</span></div>=
<div><br></div><span>DOI 10.5281/zenodo.22029444 if it is useful to cite th=
e exact bytes.</span><br></div><div style=3D"font-family:Arial,sans-serif;f=
ont-size:14px"><span><br></span></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div><div><span><b></b></span></div><div style=3D"font-family:Arial,san=
s-serif"><b>Henri Sirkkavaara</b></div><div style=3D"font-family:Arial,sans=
-serif"><div><b style=3D"font-size:9pt">Vaara </b><span style=3D"font-size:=
9pt">-=C2=A0</span><span style=3D"font-size:9pt">Runtime execution layer fo=
r AI agents</span></div><div><i><span style=3D"font-size:9pt;line-height:no=
rmal">Built to see over the noise.</span></i></div><div><span style=3D"font=
-size:9pt;line-height:normal;color:rgb(144,144,144)"><a href=3D"https://vaa=
ra.io" title=3D"vaara.io" target=3D"_blank"><span style=3D"color:rgb(144,14=
4,144)">vaara.io</span></a></span></div><span style=3D"font-size:9pt;line-h=
eight:normal;color:rgb(144,144,144)">Helsinki, Finland<br></span></div><spa=
n style=3D"font-size:9pt;line-height:normal;color:rgb(144,144,144)"></span>=
</div>
   =20
            <div>
       =20
            </div>
</div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div>
        On Friday, August 21st, 2026 at 04:10, Walter Hawkins &lt;<a href=
=3D"mailto:wdhawkins46@gmail.com" target=3D"_blank">wdhawkins46@gmail.com</=
a>&gt; wrote:<br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div><div dir=3D"auto">Emek,<br><br>You came b=
ack with the check and what it caught, so here is mine =E2=80=94 same shape=
, a day behind you.<br><br>The rule, as shipped. An anchored sequence moves=
 a verifier&#39;s floor only when all of the following hold: the calldata p=
arses and names this grant; the key segment equals the grant&#39;s accounta=
nt; the anchored content was actually retrieved; the anchor digest recomput=
es over the retrieved head; the head&#39;s signature verifies; and the head=
 itself names this grant, this accountant, and this sequence. Anything shor=
t of that is ignored with a warning naming the reason, and a refusal can on=
ly lower the floor toward the tamper-evidence downgrade, never raise it. Th=
e old scan =E2=80=94 the one that trusts the sequence printed in calldata =
=E2=80=94 survives under an UNVERIFIED label for survey work, because a cla=
imed sequence is still a lead worth following. It is no longer anything a v=
erifier may refuse an honest head against.<br><br>Shown failing before wire=
d in, on your reasoning that a check which has only ever been green demonst=
rates nothing. Four controls:<br><br>- The forged-key attack from my last m=
essage, run for real: a stranger&#39;s anchor claiming sequence 999999999 u=
nder the accountant&#39;s public key. The unverified scan reads 999999999 =
=E2=80=94 poisoned exactly as I described it two days ago. The verified sca=
n holds the floor at the genuine head and prints a warning naming the ancho=
r it ignored.<br><br>- An anchor whose retrieved head does not reproduce th=
e anchored digest: no floor movement.<br><br>- Calldata claiming one sequen=
ce over a head that states another: no floor movement.<br><br>- No qualifyi=
ng anchor at all: the floor is null, and null is not zero. &quot;I could no=
t derive a floor&quot; is the labelled tamper-evidence downgrade, not a fac=
t about sequence 0.<br><br>What it caught immediately: my own anchor. The o=
nly anchor we have ever written to a chain =E2=80=94 the Coston2 transactio=
n at block 34259963 that I brought to this thread as evidence =E2=80=94 is =
refused by the rule it motivated. I read its calldata back off the chain to=
day: it parses, and it carries no key segment at all, because the grammar p=
redates the hardening; the head it points to predates the accountant field.=
 Two independent grounds, either one fatal to floor-eligibility. Your check=
&#39;s first catch was your own sentence; mine refused my own anchor. It st=
ays in the record, labelled, as tamper evidence of the day the wiring first=
 worked =E2=80=94 which is exactly as much as the hardened rule permits it =
to be. The lesson I passed on last time, that we anchored a shape we were s=
till editing, now has an enforcement mechanism instead of a caveat.<br><br>=
Your 14-versus-15 split is in here too, arrived at separately. An anchor wh=
ose content cannot be fetched is ignored with &quot;content not retrieved, =
so its sequence is unverified&quot; =E2=80=94 could-not-check never gets sw=
allowed into failed, and never silently reads as verified. The null-rather-=
than-zero floor is the same rule one level up. I&#39;d add both of ours to =
the pile Joel is counting: the weakest-rung rule keeps being reinvented at =
whatever layer someone is standing on, which is the strongest argument yet =
that it belongs in the substrate stated once.<br><br>Two limits, stated now=
 rather than found later.<br><br>First, the verifier takes the retrieved he=
ads as inputs; where they came from is outside the rule. Joel&#39;s placeme=
nt rule =E2=80=94 state where the evidence is obtained, not only where it i=
s produced =E2=80=94 lands on this with full force. A verifier handed heads=
 by the executor it is auditing has re-derived at the second placement, and=
 the result object should say so. Mine does not yet distinguish the placeme=
nts; that is the next honest gap.<br><br>Second, floor-eligibility depends =
on retrievability, so the floor&#39;s strength decays with content availabi=
lity. An adversary who cannot forge a floor can still lower one by making a=
nchored content unfetchable. That fails in the right direction =E2=80=94 a =
downgrade rather than honest heads refused =E2=80=94 but it is a downgrade =
an attacker can induce, and the record has to name it, or &quot;no floor&qu=
ot; reads as &quot;nothing was ever anchored&quot;, which is a different cl=
aim.<br><br>Walter</div></div></div><br><div class=3D"gmail_extra"><div>On =
Thu, Aug 20, 2026 07:27 PM, <a href=3D"mailto:e.dogru@conarium.dev" rel=3D"=
noreferrer nofollow noopener" target=3D"_blank">e.dogru@conarium.dev</a> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>All,</div><d=
iv><br></div><div>I said I would come back with the check and what it caugh=
t rather than with a plan. It is written and merged; this is what it caught=
. Walter&#39;s rung 3 question gets a measured answer at the end, because i=
t turned out I could check it rather than argue it.</div><div><br></div><di=
v>The problem is in -05 in my own words: four sentences in the Implementati=
on Status section of -04 were accurate the day they were written 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 were 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 declarations of one fa=
ct exist: the code, the prose, and now a claim table between them, because =
prose cannot be executed. Each behavioural sentence is bound to a run of th=
e shipped CLI over a named fixture, and two directions are enforced. Every =
value a run produced must still appear in the sentence that states it, and =
the number of sentences must equal the number of claims. A sentence with no=
 claim is one nothing measures. A claim with no sentence is a measurement t=
he document dropped.</div><div><br></div><div>The revision it reads is deri=
ved from what is in the repository rather than named in the check, because =
a hard-coded revision is the same class of stale declaration the check exis=
ts to catch.</div><div><br></div><div>I showed it failing three ways before=
 wiring it in, since a check that has only ever been green demonstrates not=
hing:</div><div><br></div><div>    a value edited out of a sentence</div><d=
iv>      -&gt; the sentence no longer contains observed-without-receipt</di=
v><div>    one bullet removed</div><div>      -&gt; states 4 observed behav=
iour(s), the claim table runs 5</div><div>    a fixture changed so the tool=
&#39;s outcome moved, sentence untouched</div><div>      -&gt; item outcome=
s are [&quot;excluded&quot;,&quot;indeterminate&quot;],</div><div>         =
the table says [&quot;excluded&quot;,&quot;observed-without-receipt&quot;]<=
/div><div><br></div><div>The third is the one that matters: the code moved =
and the sentence stood still, which is what happened four times in -04.</di=
v><div><br></div><div>What it caught immediately is a sentence of mine. -05=
 says &quot;The implementation&#39;s test suite contains no check that comp=
ares this section against what the code does.&quot; From the merge commit t=
hat is false, and a posted draft cannot be edited, so it is the first corre=
ction -06 owes.</div><div><br></div><div>Two limits, stated now rather than=
 discovered later. It 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: change the code back, or write the revision that says what t=
he code now does. Editing a posted draft is not one of them, which makes th=
e cost of drift a document rather than a diff.</div><div><br></div><div>Wal=
ter, on rung 3. You put it as: an external anchor is not automatically rung=
 3, an anchor is a claim by whoever paid for it, and a profile that says &q=
uot;anchored&quot; without saying &quot;and re-derived&quot; has described =
rung 2 with extra steps. I went and looked rather than answering from memor=
y, and the implementation agrees with you, which I did not know for certain=
 before you wrote it.</div><div><br></div><div>--anchor-check deserialises =
the timestamp proof, refuses a proof whose digest is not the chain head, wa=
lks the attestations, and where the attestation is Bitcoin it fetches that =
block and compares the digest against the merkle root. So the re-derivation=
 is in the path and not in the prose.</div><div><br></div><div>The part I w=
ould not have thought to defend, and which your framing is the reason to me=
ntion: it separates two answers that a single 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 fetched, exits 15, and 15 is evaluated f=
irst, so &quot;I could not check&quot; never gets swallowed by &quot;it fai=
led&quot;. Returning 0 there would have been the same error in the other di=
rection: the caller has to know the anchor was not verified, not merely tha=
t it was not disproved. That is the weakest-rung rule applied to our own to=
ol, and it was written before anyone asked us for it, which is the only rea=
son I can say it now without it sounding convenient.</div><div><br></div><d=
iv>Emek</div><br><br>
      <div>
        <div>On Fri, Aug 21, 2026 at 2:50 AM Walter Hawkins &lt;<a href=3D"=
mailto:wdhawkins46@gmail.com" rel=3D"noreferrer nofollow noopener" target=
=3D"_blank">wdhawkins46@gmail.com</a>&gt; wrote:</div>

        <blockquote><div dir=3D"auto">Henri, Joel, Emek, 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&#39;s a good rate.<br><br=
>**One.** I used the words &quot;omission-proof&quot; in my own notes and i=
t 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 accounta=
nt carrying a root and a<br>running total. That much I had right =E2=80=94 =
it&#39;s rung 2. What I had wrong was the<br>floor. A verifier arriving for=
 the first time, holding no prior state and doing<br>no anchor lookup, acce=
pts an old validly-signed head together with the prefix<br>that matches it.=
 Monotonic sequence, perfect arithmetic, short set. Henri&#39;s<br>correcti=
on this morning is the same shape as mine, and I&#39;d made mine a day<br>e=
arlier without noticing what it cost.<br><br>Fixed the way Emek&#39;s rule =
says it should be: the freshness floor is now a<br>required argument, and p=
assing nothing is an explicit downgrade whose verdict<br>is labelled tamper=
-evidence rather than completeness. The weakest-rung rule<br>applied to an =
argument I had made optional.<br><br>**Two, and this is the one I think is =
worth the thread&#39;s time, because it&#39;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 h=
ighest sequence as its<br>floor. That is the external anchor the ladder ask=
s for, and two days ago I&#39;d<br>have told you it put us at rung 3.<br><b=
r>Anchoring is permissionless. That property is why it resists censorship a=
nd it<br>is also the attack. Anyone can write that calldata. The key field =
is plaintext,<br>and the accountant&#39;s key is public because it&#39;s na=
med in the grant. So a<br>stranger writes an anchor for my grant at sequenc=
e 999999999, my scanner reads<br>it, and every honest head I produce afterw=
ards is refused as a rollback. The<br>floor is poisonable by anyone willing=
 to pay for one transaction, and the<br>failure mode isn&#39;t a missed omi=
ssion =E2=80=94 it&#39;s an honest record permanently<br>refused. We had tr=
aded a false negative for a false positive against ourselves,<br>which is t=
he worse of the two trades.<br><br>The fix is that an anchored sequence can=
not be read as a fact. It is a pointer.<br>A verifier deriving a floor has =
to fetch the anchored bytes, recompute the<br>digest over them, check the s=
ignature, and check that the head it just verified<br>names this grant and =
this sequence =E2=80=94 and only then let it move the floor. An<br>anchor w=
hose content can&#39;t be retrieved simply isn&#39;t floor-eligible, which =
can<br>only lower the floor toward the tamper-evidence downgrade, never rai=
se it.<br><br>Stated honestly about where we are with it: that rule is writ=
ten into our spec<br>text and our scanner does not yet do it. What the scan=
ner does today is the<br>cheap half =E2=80=94 it ignores anchors that don&#=
39;t name the grant&#39;s accountant, which<br>closes the stranger-with-no-=
key case and leaves the forged-key case open,<br>because that field is unau=
thenticated. So take the paragraph above as a claim<br>about what rung 3 re=
quires, not a claim about what I&#39;ve shipped. The<br>re-derivation is th=
e next thing I write, and I&#39;ll come back with what it caught.<br><br>So=
 for the statement I&#39;d put it this way: an external anchor is not<br>au=
tomatically rung 3. An anchor is a claim by whoever paid for it. Rung 3 is<=
br>an anchor plus the verification that recovers what it points at, and a p=
rofile<br>that says &quot;anchored&quot; without saying &quot;and re-derive=
d&quot; has described rung 2 with<br>extra steps. Nenad, I think this bears=
 directly on precedence =E2=80=94 ordering a<br>revocation strictly against=
 a settlement only means something if both anchored<br>objects are re-deriv=
ed first; otherwise you&#39;ve ordered two assertions.<br><br>**What I owe:=
 the rail enumeration.**<br><br>Every payment under a grant carries a bindi=
ng in the one payer-chosen slot the<br>rail&#39;s own signature covers =E2=
=80=94 the EIP-3009 nonce, the Permit2 nonce, the XRPL<br>InvoiceID. The va=
lue is a domain-separated digest over the grant digest and the<br>payment i=
dentifier, so it&#39;s derivable by anyone holding those two and<br>recompu=
table from the settled transaction by anyone holding that.<br><br>The recei=
ver&#39;s use is the part this thread wants. A payee holding a settled<br>t=
ransaction recovers which grant and which payment it commits to from the<br=
>artefact itself, without asking the executor which authorisation it would =
like<br>to be judged under. And the enumeration runs off the rail rather th=
an off a<br>list: the payee walks settled transactions to their own address=
, not a set the<br>executor 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 th=
e party who cannot be made to<br>un-know it arrived.<br><br>Testnet EVM rai=
l, as promised: Coston2. A head anchored as a real transaction at<br>block =
34259963, the calldata read back off the chain and matched against the<br>s=
igned head, block timestamp doing the ordering.<br><br>With a caveat that b=
elongs in this thread more 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 key segment, so it verifies against the code as of the =
commit<br>that produced it and not against current HEAD. I keep it as evide=
nce that the<br>wiring worked on the day, and as a small lesson I&#39;d pas=
s on: we anchored a shape<br>we were still editing, and permanence is the o=
ne property an anchor has whether<br>or not you were finished. New heads us=
e the hardened shape. I&#39;ll bring both,<br>labelled.<br><br>Two limits I=
&#39;d rather state than have found.<br><br>The rail has to enforce slot un=
iqueness for once-per-payment to come 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 same 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 lean on the rail for it.<br><br>The secon=
d one I had wrong until a review pulled it apart yesterday, and it<br>gener=
alises past payments. The binding identifies the grant; it does not bound<b=
r>the amount. The slot commits to the grant and the payment identifier and<=
br>nothing else, so an agent holding the payer key can settle a million aga=
inst a<br>payment it reports as one. The cap only binds if the verifier rea=
ds amount,<br>recipient and asset out of the settled transaction and compar=
es them back to<br>the grant. I had a document claiming one artefact proved=
 both that money moved<br>and that it moved within authority, and that sent=
ence was doing work the<br>mechanism didn&#39;t do. Identifying which autho=
risation governed an act is not<br>the same as bounding the act performed u=
nder it =E2=80=94 Nenad, that&#39;s your item 2<br>from the other end, and =
I think it&#39;s a second thing the substrate should say<br>outright, becau=
se the failure is invisible and every incentive points at it.<br><br>The ob=
ject model and its vectors are public as of today, as an open PR rather<br>=
than anything settled: specs/extensions/authority.md and<br>authority-vecto=
rs.json in x402-foundation/x402 #3220. If the statement cites<br>components=
 normatively the way Henri suggests, that&#39;s the published home for<br>t=
he rail-binding piece, under the same one-authority rule Nenad named.<br><b=
r>**Nenad&#39;s fourth vantage.**<br><br>I think it&#39;s right and I&#39;d=
 add a note from our side. We have no revocation, and<br>that&#39;s deliber=
ate rather than missing: our grants carry an expiry, and authority<br>decay=
s without anyone needing to deliver anything. A suppressed revocation is<br=
>invisible to a receiver, as you say =E2=80=94 but you can&#39;t suppress t=
he passage of<br>time. It&#39;s a real trade, not a free win: a short expir=
y 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 =
re-issuance is affordable,<br>expiry is revocation you don&#39;t have to de=
liver, and I&#39;d rather the substrate<br>name that as an option than have=
 every profile carry a revocation channel it<br>can&#39;t guarantee reaches=
 anyone.<br><br>**Joel&#39;s fourth item.**<br><br>Same answer as Henri, Pa=
blo and Nenad: we don&#39;t have it. Nothing in our records<br>pins the pub=
lisher-assigned version of any corpus a decision was computed<br>against. F=
our for four is a better argument for lifting it into the substrate<br>than=
 any of us adding a field and then citing ourselves.<br><br>**Willing, and =
here&#39;s what I bring.**<br><br>The rail-enumeration binding above, the C=
oston2 fixtures, and the rung-3<br>refinement =E2=80=94 anchor as pointer, =
not fact. Henri, the completeness component and<br>its rungs stay yours to =
state; Todd, the fraud side is what keeps this attached<br>to a real failur=
e; and if Emek&#39;s ladder is going to carry the structure of the<br>docum=
ent, 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.do=
gru@conarium.dev" rel=3D"noreferrer nofollow noopener" target=3D"_blank">e.=
dogru@conarium.dev</a> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div>Joel, Henri, Pablo, Walter, Todd, Nenad,</div><div><br></div><=
div>Joel, you withdrew two claims in public before making your argument. 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 done, and =
I can show you exactly where the line falls.</div><div><br></div><div>You w=
rote that the vocabulary has to reach the output, and that both our impleme=
ntations skip it. In mine the /2 result carries a bounds object: for each b=
ound the comparison relied on, its source is protocol-defined, measured, op=
erator-declared, or undeclared, and a result whose bounds are operator-decl=
ared states an outcome of that standing and no stronger. Measured against t=
he published package, one fixture, a receipt three seconds outside a two-ho=
ur window:</div><div><br></div><div>- no profile: all three bounds undeclar=
ed, both items indeterminate</div><div>- a profile with no clocks member: m=
ultiplicity and exclusion operator-declared, skew still undeclared</div><di=
v>- clocks.skew declared wider than the offset: operator-declared, and the =
item stays indeterminate. A declaration does not manufacture a match.</div>=
<div>- clocks.skew declared narrower than the offset: the same item becomes=
 observed-without-receipt</div><div><br></div><div>So the vocabulary reache=
s that object. It does not reach the exit codes, which predate it and are s=
till not a mapping of it. Your sentence covers precisely the half I have no=
t done, and I would rather that stayed in the record than get answered 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, clocks.ske=
w, a duration grammar, a rule that an unknown key in clocks is rejected by =
name, and a rule that the same bound declared twice must parse to the same =
milliseconds or the run fails rather than picking one. Written to be borrow=
ed, not restated.</div><div><br></div><div>On placement. The distinction is=
 in -05 as a security consideration (sec-completeness), written against my =
own implementation rather than about two of them: a truncated receipt set v=
erifies, detecting the removal needs a quantity from outside it, and whethe=
r that quantity reached the verifier independently of the Issuer is not vis=
ible in a digest. I support lifting it to the substrate, with one caveat ab=
out how it is worded there. The property that matters is not &quot;in-recor=
d beats argument&quot;. It is that a Consumer cannot tell the two apart fro=
m 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 c=
arrying it; stated as a disclosure obligation it does not.</div><div><br></=
div><div>On the weakest-rung rule. Four documents arriving at it separately=
 is a better argument for the substrate than any one of us restating it, an=
d your verdict-side version is the one I would take as the general form, be=
cause it survives translation to outputs that are not bounds at all. One ca=
ution from the side that has already shipped it: the rule is cheap to write=
 and expensive to keep. indeterminate is only load-bearing while nobody is =
allowed to average it, and the pressure to fold it into a coverage percenta=
ge arrives from outside engineering, after the vocabulary is public and loo=
ks like a scoring system.</div><div><br></div><div>One more thing worth put=
ting in the record. Your sentence from two days ago, that a gaps section go=
ing stale understating an implementation fails the same way as one that ove=
rstates, turned out to apply to mine four times over. Each statement was ac=
curate when written and false within days, always in the direction of claim=
ing less than the code did, and nothing in my test suite compares that sect=
ion against the code. So the corollary reaches further than either of us pu=
t it: the problem is not that our implementations skip the vocabulary. It i=
s that neither of us has a check that would notice if they did. That is the=
 gap I would most like the substrate to make expensive to leave open, and i=
t is the next thing I write on my own side. I will come back with the check=
 and what it caught, rather than with a plan.</div><div><br></div><div>Emek=
 Can Dogru</div><div>Conarium</div><br><br> <div> <div>On Fri, Aug 21, 2026=
 at 12:06 AM Joel Hillier &lt;jhillier=3D<a href=3D"mailto:40certisyn.com@d=
marc.ietf.org" rel=3D"noreferrer nofollow noopener" target=3D"_blank">40cer=
tisyn.com@dmarc.ietf.org</a>&gt; wrote:</div>  <blockquote>     <p style=3D=
"direction:ltr;margin-top:1em;margin-bottom:1em"> Hi Henri, Pablo, Walter, =
Todd,</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Emek=
, I&#39;m adding you to this because the rung ladder is yours and it&#39;s =
been travelling without your name on it. Henri&#39;s message this morning c=
redits you with cloning at <code>befdced</code> and running the three cases=
, which is true, but you&#39;re also the one who wrote the ladder and the r=
ule that goes with it. That rule is the most useful thing in this thread, a=
nd 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>Correctio=
n one. I told you ARP&#39;s sweep chain makes a withdrawn Statement detecta=
ble. That&#39;s true for the middle and false for the tail.</b></p> <p styl=
e=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Each Evaluation Sweep=
 Statement carries the previous Statement&#39;s notarisation, so I had the =
chain doing a job it can&#39;t do. Your 0.2.4 shipped under &quot;a hash ch=
ain is blind to a shorter tail&quot; and it applies to my series exactly as=
 it applies to yours: a truncatedtail of Sweep Statements verifies precisel=
y as it did before.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bot=
tom:1em"> What actually puts ARP at rung 3 is a different mechanism, which =
I&#39;d been crediting to the chain. Each Statement is due inside a bounded=
 interval measured from its trigger, and where the trigger is a public even=
t with a public timestamp, a sanctions list publishinga delta starts a cloc=
k the operator doesn&#39;t own. An operator with no Statement inside the in=
terval hasn&#39;t evaluated in time, and anyone can check that holding none=
 of the set. The chain covers the middle. The deadline covers the tail. Two=
 mechanisms, and I&#39;dhad them credited as one.</p> <p style=3D"direction=
:ltr;margin-top:1em;margin-bottom:1em"> <b>Correction two, and this one is =
worse, because it&#39;s the sentence where I congratulated myself on not ro=
unding up.</b></p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1=
em"> I said the falsifiability argument holds for three of ARP&#39;s four t=
riggers, &quot;stated rather than rounded up.&quot; Only one of those three=
 rested on anything outside the reconciliation server. The other two rested=
 on a transition list published by the server, underthe server&#39;s own ke=
y, in a document with no publication time, no notarisation and no chain. A =
transition simply left out of that array started no clock, and no party cou=
ld date the document well enough to show that it had been. On that footing =
the count wasone in four, and the sentence claiming otherwise was the one p=
lace the document rounded up.</p> <p style=3D"direction:ltr;margin-top:1em;=
margin-bottom:1em"> It&#39;s three in four now because I fixed the mechanis=
m rather than the sentence: the document carries a publication timestamp, i=
s notarised on the ledger-head interval, and has to be republished on that =
interval whether or not anything in it changed. That lastpart is the one th=
at matters, and it&#39;s your placement argument doing the work. Without it=
, an operator that removed a witness entry and an operator that changed not=
hing publish the same thing, and the notarised series has no entry to be mi=
ssing.</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 poli=
cy parameters aren&#39;t anchored that way has one falsifiable trigger, not=
 three. Which is your rule about naming the ground, applied to a count I=
9;d already published.</p> <p style=3D"direction:ltr;margin-top:1em;margin-=
bottom:1em"> <b>One more, since it&#39;s the mechanism I described to Walte=
r yesterday.</b> I said ARP&#39;s witness quorum counts entries under commo=
n control once, because two instances of one observer aren&#39;t two observ=
ers. The distinctness test was written over the operating-partyidentifier a=
lone and said nothing about the keys. Two entries declaring the same key un=
der two different party identifiers satisfied a quorum of two with a single=
 signature. Both entries verify, the identifiers are distinct, and a relyin=
g party doing exactlywhat the document said counted one signer twice. Now f=
ixed by requiring the verification method references to be pairwise distinc=
t as well.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em">=
 Worth separating that from the limit I did state correctly. Whether two na=
med parties are genuinely independent can&#39;t be tested by a verifier and=
 the document concedes it. Whether two entries name one key can always be t=
ested, and wasn&#39;t.</p> <p style=3D"direction:ltr;margin-top:1em;margin-=
bottom:1em"> <b>Now the thing I owe this thread.</b></p> <p style=3D"direct=
ion:ltr;margin-top:1em;margin-bottom:1em"> Henri and Pablo have both said t=
hey&#39;d need to add the fourth item before they could point at one, and H=
enri&#39;s suggested the substrate cite components normatively rather than =
restate them. Together that means the fourth item gets lifted out of ARP. S=
o let mehand it over along with what was wrong with it, rather than after i=
t&#39;s in shared text.</p> <p style=3D"direction:ltr;margin-top:1em;margin=
-bottom:1em"> A Partial Attestation carries a Source-Data Version Identifie=
r Set: one identifier per source consulted in evaluating the predicate. Eac=
h is a tuple of the list name as declared in the bilateral agreement, and t=
he state identifier the list publisher assignsto that state, not a value th=
e answering party made up. It rides in the protected header so it&#39;s cov=
ered by the register&#39;s signature, and it&#39;s carried into the output =
so it&#39;s covered by the sealing signature.</p> <p style=3D"direction:ltr=
;margin-top:1em;margin-bottom:1em"> The reason it&#39;s the publisher&#39;s=
 identifier and not the register&#39;s is the part worth carrying into any =
shared text, because it isn&#39;t obvious and it&#39;s the whole point. A r=
egister-chosen opaque string would be an arbitrary-bandwidth channel from r=
egister to relyingparty, travelling under signature into a sealed and ledge=
red artefact, and the accompanying rule that differing identifiers mustn=
9;t be read as disagreement would normalise it. Taking the identifier from =
the publisher&#39;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 n=
ow repaired:</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em=
"> 1. The Set had no ordering rule. Five other collections in ARP carry an =
explicit bytewise sort. This one was called a Set in its own section headin=
g, was carried into two signatures, and was never sorted, so a register con=
sulting three lists had six conformingencodings of one attestation. Now sor=
ted.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> 2. Th=
e state identifier was disjunctive with no discriminator. &quot;A published=
 version token, or a digest of the published corpus where the publisher ass=
igns none.&quot; Text in one branch, digest bytes in the other, same positi=
on, no algorithm named, and no statementof what the corpus is as a byte seq=
uence. It now carries an explicit form discriminator, and the digest branch=
 is taken over the octets the publisher serves, before any decompression. T=
hat second part is the one I&#39;d have got wrong: a list published as a co=
mpressedarchive has at least two byte sequences with an equal claim to bein=
g the corpus, and two registers choosing differently produce two identifier=
s for one state, which a retroactive sweep then reads as a version change t=
hat never happened.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bot=
tom:1em"> 3. It was carried twice with no equality rule. ARP has exactly th=
e right sentence for this, that a value carried twice with no equality rule=
 is a value an implementation may read either way, and applied it to the tw=
o other duplicated headers and not to thisone.</p> <p style=3D"direction:lt=
r;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&#39;t ye=
sterday.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> <=
b>On placement, Emek, your distinction deserves to be a named property of t=
he substrate rather than a remark about two implementations.</b></p> <p sty=
le=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> You put it as: Henri=
&#39;s seal is a record inside the stream, signed and carried with the evid=
ence, readable by whoever holds the set; Conarium&#39;s pin is an argument =
to the verifier, so a third party handed only the receipt set can&#39;t tel=
l it&#39;s short unless someonestates what it should have been, and the obv=
ious someone is the issuer, the party the audit is about.</p> <p style=3D"d=
irection:ltr;margin-top:1em;margin-bottom:1em"> That&#39;s sharper than the=
 rung number alone, because two mechanisms can sit on the same rung and dif=
fer entirely in who has to be asked. I&#39;d state it as three placements:<=
/p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Inside the=
 evidence. Travels with the set, needs nobody. Henri&#39;s seal.</p> <p sty=
le=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Supplied by the audi=
ted party. The verifier has to be told the expected count or terminal hash,=
 and the party best placed to tell it is the one under audit. Conarium&#39;=
s pin, and you said so yourself rather than letting the symmetry flatter yo=
u.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Supplie=
d by a party with no stake. ARP&#39;s deadline is this one: the clock is st=
arted by a list publisher who&#39;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&#39;t a design ch=
oice you can make freely. Where it exists it should be used, and where it d=
oesn&#39;t the statement should saywhich of the other two you&#39;re on.</p=
> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> The sweep fo=
und a fourth case that the three-way split predicts and I hadn&#39;t looked=
 for: a mechanism sitting at the first placement whose evidence is only obt=
ainable from the second. ARP&#39;s head consistency statements are signed b=
y independent witnesses, whichis the whole point of them, and the document =
specified the artefact, the quorum arithmetic and the freshness window and =
specified no channel by which a relying party obtains one. The obvious impl=
ementation is that the responding service hands them over withits response.=
 Every check passes. The witness signature stops the service forging a stat=
ement and does nothing to stop it choosing which ones to pass on, so under =
exactly the fork the mechanism exists to detect, each branch&#39;s reader g=
ets the witnesses thatbranch was fed. Now fixed by requiring witnesses to p=
ublish on their own origins and forbidding acceptance of one obtained from =
the responding service.</p> <p style=3D"direction:ltr;margin-top:1em;margin=
-bottom:1em"> Worth adding to the substrate as a rule in its own right: <i>=
state where the evidence 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 style=3D"direction:ltr;margin-top:1em;margin-bottom:1em=
"> <b>Your weakest-rung rule already exists in ARP under another name, whic=
h I think argues it&#39;s the right general rule rather than a local conven=
tion.</b></p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> =
You wrote that a result which doesn&#39;t say which rung it stands on has t=
o be read at the weakest one, and that it&#39;s Walter&#39;s completeness l=
adder one level up.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bot=
tom:1em"> ARP arrived at the same rule from the verdict side and calls it v=
erdict re-typing. An answer over a register whose attestation can&#39;t be =
verified doesn&#39;t produce a weaker match, it produces <code>indeterminat=
e</code>. Where a re-notification can&#39;t say whether a change came from =
policy or from the underlying corpus, it has to carry <code>attribution-ind=
eterminate</code> and name which causes were examined and why neither could=
 be excluded, because a bare qualifier is a discretionary escape signed by =
the party that benefits from it. And conformance run records carry a <code>=
does_not_establish</code> field so the things a run didn&#39;t prove are en=
umerated rather than inferred from silence.</p> <p style=3D"direction:ltr;m=
argin-top:1em;margin-bottom:1em"> Four instances, four documents, arrived a=
t separately: bounds in yours, populations in Walter&#39;s, verdicts and co=
nformance claims in mine. Worth stating once in the substrate, roughly as: =
<i>every result names the ground it stands on, and a result that names none=
 is read at the weakest ground available to it.</i></p> <p style=3D"directi=
on:ltr;margin-top:1em;margin-bottom:1em"> The corollary is the one implemen=
tations skip, including both of ours. The vocabulary has to reach the outpu=
t. You say your exit codes predate the vocabulary and still aren&#39;t a ma=
pping of it. I found two of the same shape this week: a verifier told to re=
fusea proof with no defined way to say which of four refusals it made, and =
one reason code carrying five distinct causes because four other sections p=
ointed at it for conditions its own definition never named. Both 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-t=
op:1em;margin-bottom:1em"> <b>On your open question about the boundary decl=
aration.</b></p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em=
"> You framed it well: a boundary inside the record has nothing to drift fr=
om and is the stronger guarantee, but it&#39;s asserted by one party at iss=
ue time; a profile is the weaker binding and the only one that can be agree=
d between parties before a run and pointedat afterwards by both.</p> <p sty=
le=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> ARP&#39;s answer is =
to make the profile a signed bilateral instrument with a hash. The agreemen=
t is settled before any run, both parties compute an agreement hash over it=
s declared items independently and have to get the same value, and every re=
conciliation commitsto that hash. Drift suspends reconciliation rather than=
 producing a weaker answer. So it keeps the agreed-not-asserted property of=
 a profile and gains the nothing-to-drift-from property of an in-record bou=
ndary.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> The=
 cost is that it only works bilaterally. It doesn&#39;t reach a population =
of parties who have never negotiated, which is most of Walter&#39;s setting=
. Worth having in the statement as one of the answers rather than the answe=
r.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> <b>Pabl=
o, your precedence point generalises, and it flips direction depending on w=
hat&#39;s being anchored.</b> Yours is <code>anchoring_precedence</code>: t=
he anchor 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=
 outcome was recorded. ARP&#39;s is the mirror image. The Statement has tof=
all later than the trigger and inside a bounded interval, because what&#39;=
s being proved is that a duty was discharged on time, not that a fact was t=
rue beforehand.</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:=
1em"> Same underlying requirement, that an anchor with no ordering constrai=
nt against the thing it covers is decorative. Two opposite orderings, becau=
se one anchors the proof and the other anchors the duty. I&#39;d say it tha=
t way in the shared text: every external anchordeclares its required orderi=
ng relative to what it covers, and which of the two it is.</p> <p style=3D"=
direction:ltr;margin-top:1em;margin-bottom:1em"> Agreed on normative citati=
on over restatement, with one addition. Where a component is cited rather t=
han restated, the citing statement should also name the rung the component =
reaches. Henri&#39;s correction this morning is the case in point, and so a=
re both ofmine above. None of the three components changed. The claim made =
about each was one rung short. A substrate that cites a component and repea=
ts an over-broad claim about it has moved the error rather than removed it.=
</p> <p style=3D"direction:ltr;margin-top:1em;margin-bottom:1em"> Joel</p> =
  </blockquote> </div> </blockquote></div></div> </blockquote>
      </div>
</blockquote></div></div>

        </blockquote><br>
    </div></blockquote></div>

--000000000000b920d906598b51d0--