[SCITT] Re: Closing omission from the receiver's vantage — what a record must carry
Joel Hillier <jhillier@certisyn.com> Thu, 20 August 2026 21:06 UTC
Return-Path: <jhillier@certisyn.com>
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 080C812D0F102 for <scitt@mail2.ietf.org>; Thu, 20 Aug 2026 14:06:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787260014; bh=x4lJoW2rUAQtKqSPcN788uxLrSC6jp+FRddBgGTuG3E=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=WmpP36OJCeunogLGpIx/96tMN1h2ni4EwzFlxX4KEFbCpwFFD5Fxf1XT4FrG0VUGP 9GDpHaSxWTZ2uQ4RwKO/MKJQNgb4oo8kQsAwYK/jvuYH5R4jvUEOfK40GgK4XJtu68 a+oKUmzie5KdrPVc0PcWQcsD9a/AHTVegOzQqaCU=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 40IOOrgSy17f for <scitt@mail2.ietf.org>; Thu, 20 Aug 2026 14:06:53 -0700 (PDT)
Received: from MW6PR02CU001.outbound.protection.outlook.com (mail-westus2azon11022099.outbound.protection.outlook.com [52.101.48.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B77CC12D0F0FB for <scitt@ietf.org>; Thu, 20 Aug 2026 14:06:52 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=biS8zxEGTJOLEWNnGwqGlS3wNmCIPvvO/EdKjTIJG0e/t3id1vEnlgj5k9RNem4zZifgH69dux1QvzrgX7/frg8uwk/lNjl6pip+oGIe29hxlaJYP8QQEhU48ANy5CX1ynzAapXgHBLl2pGWAclc+wU9hMEv1+ftOdCmX/Fkmv6P5qYg8pbYenYCprq2HCbwA9Cd0AMd8EgaH53uZcwWu8Zw07WvU+wb8fl3DcNEgSCuxORJAxxjM7NH3F4W14eZTzRsDW2BfBv2DKFC8RXVzl9KuCaSZkZ9OcQqd6sQMCsoFr1XaF6vE8uLtE0dpwBkmPhkYGYzEaXusHdE+bH5Xg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=x4lJoW2rUAQtKqSPcN788uxLrSC6jp+FRddBgGTuG3E=; b=y6AzymbuqF0lj/qx5hQ+1kvJxPCVgUe6SqkgCN6Gpynlq1Df4bDgCRh2bL71nGaSFx6oe8fHRnhnjmu6sFf+nttgkvL+EBnTpxh5DrTSYKXJ13tWcnLHjHRl8NBnQv0UEnmhIm+3SBT9xRzhQl7nveGMk6ljOcAJgNe1ZObcaPk6JilohZQ6oEUQvAd81f8i+3lS382FLlma77efe8e5i5tk97B90JRoQUO6m94wRuSYrgzRzZSz7iSXcbEJzpcT1kFG4VIm9ZLVh70VKBiDwyA2xWDJ2uMtEX84mBdsfXg/cU+J0zKBpr0woIQUndXw3RyUaPyuoCDFyyAg9gFsSQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=certisyn.com; dmarc=pass action=none header.from=certisyn.com; dkim=pass header.d=certisyn.com; arc=none
Received: from BYAPR19MB2806.namprd19.prod.outlook.com (2603:10b6:a03:fa::15) by DM3PR19MB8475.namprd19.prod.outlook.com (2603:10b6:0:40::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Thu, 20 Aug 2026 21:06:45 +0000
Received: from BYAPR19MB2806.namprd19.prod.outlook.com ([fe80::6c0f:94c8:c4c8:3fbb]) by BYAPR19MB2806.namprd19.prod.outlook.com ([fe80::6c0f:94c8:c4c8:3fbb%6]) with mapi id 15.21.0339.007; Thu, 20 Aug 2026 21:06:45 +0000
From: Joel Hillier <jhillier@certisyn.com>
To: "scitt@ietf.org" <scitt@ietf.org>
Thread-Topic: [SCITT] Re: Closing omission from the receiver's vantage — what a record must carry
Thread-Index: AQHdMGViABUjjjemH0SDtlQL6xyroLamtE8AgAAOQYCAAAtOgIAAMMq2
Date: Thu, 20 Aug 2026 21:06:45 +0000
Message-ID: <BYAPR19MB2806AE6655C5EE704644533AADA42@BYAPR19MB2806.namprd19.prod.outlook.com>
References: <CALc05oEEg_BVvy6UCDBBgyrV8ASvLuJYWxNoES3k9jgE22mccA@mail.gmail.com> <G291Rgu5pZ2v3GWOaxuoG0PVYvTTzkjdx8Yg6w_RncBbuBGYX1PvhYtIHg-IuMS9yf1uUKC7mf8KlXd-fE1f0yJkCUZo1jzx4vNYode61o8=@vaara.io> <CANWAHpo0YsdaFc+Z5HAWZ5wF0T3H20bMzzCodyP6nxraGDmHuQ@mail.gmail.com> <6Ou4Q9Hvpbvr_x0cwKj2fksHZL98ZgeEFTdi7ZYFtUtOVt6KbcMZBG4CElMgsyvA9wMCop_xCro6VFxyHhjg2s-8gR8a5PklRMPJAMijpS0=@vaara.io> <CANWAHppD4COT3gkb73Y8no=oFbb5YpAOapRqAUoF3F4BxKburA@mail.gmail.com>
In-Reply-To: <CANWAHppD4COT3gkb73Y8no=oFbb5YpAOapRqAUoF3F4BxKburA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
drawingcanvaselements: []
x-ai-generated: mcp-office365
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=certisyn.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BYAPR19MB2806:EE_|DM3PR19MB8475:EE_
x-ms-office365-filtering-correlation-id: 46141465-2d76-491c-1951-08defefef107
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|56012099006|7055299009|10067099003|3023799007|6133799003|18002099003|22082099003|8096899003|5023799004|4143699003|38070700021;
x-microsoft-antispam-message-info: GvtWf+i8DVYlS/2zzbeq1f9yphqQWUgIOcBkKV8Ey23Kv2ijmWzwUrrekKTDenE9NrAzbrpJ8IqYOyeuyjE8vdwQj+Rw0D7KmIL/iLSeu2EmJRnxxkiiS9H/Xk+6rh94yZ/1ZWbuVWLIxlnVbKqT3J1VUjtT6AtReweDLziTI1o/anS2IsgA5qzlbF/tRqMU3pSxaNS5XZ16PVXB6NclwxCGPJL0KWJxLboTwgJcGBwFzlIJs5y0jyPveuJoBSCH/faPN+9LLRC4d777aHf9EzBW5ZipWkNdPDDXct3m5HXKSUBgXIfkJeL91/DUe1w1WLc+XvTnUptGz2rBlPFKxlvwiKWInEH9DmGWAWJKL/1uRmy53tyim+1EwxQiKzK3MjRtl4tvhVF/iQo4ugRKdAysVr68q3bPd2h6+ZR+M9Iiw1bMuXla7jYN6579XYsSuSn+HMnD1UZdDRDthnqVftJVaRzHN8JzUD+97sc/1aK+seVIv4KnxDos7BykRV5w2LJAmZCHfRr2Lj5PWmu5z/eVnyh+PAqYvZ558zdp5XiZy+SrrfOzjEt7t61mVp2Y0Bzgcgnnjgah8LJuocBxxucXhznCpEdglSBA9o5OXvHjIvBI37v5d3KelfyWu/h3MLL4hbkiFoQ5sPjnHBw4grBNJEINRGZHaZxAJq9B70VAi2Ml5sWAPlXbJ17KfmoIFiAnA99RIrUsfblBkXwoL8lMWpNvXqLDeGceFMscJOeCjoE42FSNMzZN7GlmKDyW
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR19MB2806.namprd19.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(56012099006)(7055299009)(10067099003)(3023799007)(6133799003)(18002099003)(22082099003)(8096899003)(5023799004)(4143699003)(38070700021);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: PeGdA8M9U4wbrSEyZ/+VExA3Lzvyxv7aQlAG7Ah7pMv0yRlL6T4EpNVcXXFMheN5XbtFSLcDwUi1mA+fv69A7sBZVXRjDjmZU+6IrOAEhIjxJM5oce1FC6f1FJ0QMg94XkulB/+pimaloYM6n46eqM0z6EsUb5hqwT1JYGpjyIAeKqpvF2ZhiA2YN7pDoP7prxInwrdPCwRpenNnOlmZZQ2JdzZba+jP1uiKBzVKZz6TaFogb5H6wZffnss7U2YZ8iHUkCneBflWSQF6YJ21n4FEkeosxLUZjz6VZgzJfHUYXXVSYBJmmDXmjPAh/6l/Suw1hoViWPN6wsUxLE/AJjGd+FSOM6JDkopyYGMnQGS9eAU+GfHY4BhxyGq5olenU2fGlOnM1CqDoResSoaltL7Zhs/FBt9W9KT8nCnVmU6fp7EHm7eI2ppWtzMN/2q+wicSBl4pPdBtaaF1swwu8Flvbg9uy7XG1NmjE9b5Gg9UH9dXwQOedb0WVfTM9s3LstDsRZFNKKY4RApEQOHmHRomE9fliFT7FlZ5rD11Xhw9axprSMpDtoKqWiPT2tICfF3WPlK6e0fi7bOj86TJzo+0POGzf6FIPj/NbJYXo7HXat2eBhvD7hRiqzpx7wTNYqf7lWRAevdLVbJUlImeet7/xNc2hpG/tBzG39n2YpsE4nEf/U0ZiJZPBMIwmMwuQJuMJxELb7c2Qd8FPGVKneMSNpI8ujaMS5jUijNkCM1JF/sKZj71Ohx/ZfgrxpLiNlpfGpI85raXOwZShu2wHlWDk4oAy1572Xxb1Mj5p/Va8Avb5lCeKXotn9j/ahAYC17tGgcEVRPmiYalX/beU78zQAtqFtG7sHdWLxMurMwFKmlg1Ec0wm1FFsO4DYrVN3iiMvLA+UB0sOvrlzpl0nIfTPj+5OkbupKxp2DCnseNDYLxXaRbQxO4RxUfE23tpUHrtAvoa3DCl5l8Ht3nOq7q/aEtxIshIyjgzTHuDJo/smhUV77ycRtbx2+/WwEKOiirGrKWZ9I45E3CRL688YuiWHtOYA5IouTkQLjRbF2Qoh0/0lZK2l3dmqNZjptB7r/7RraAOdEv+sidyfbn/XgBb/MQmlVdfmKBLpTWtAxUg/uhMnWHr2+jST9+N2wW2lp4S6KsPwFx1IOxbhde5eQQ2qvnVwgOjOQEiTIvrsleLWFa1+rcLjBiMs9hHdMPKPBwr2ZUsDo8jzPoRJW0tECO8OOYopMtPkREZjBXcBA8AkyFXVmeWdUD0aE9GF85+2exoEUUOZcdJGjduJnp1AZNenwQnOiWQklpasgvLj9MCCsodg47VSOwU8rw+JSvdngR+tQA3dFqkn/tVs4v8YPWwHmwlmbHy/KIrVMANYssTnmut80aNaCWK2sZfvafruaSWQ0APfbrg7oQk5pyu2F6GVOjNb9+Coz+tgj4FeejgyjI0OWASYlqDDhokPKCCCSCjqFuoGlgpWpRNeAbCusTMQWch7RbCj+c2uegVoxI7Ss61h9+N42KMfsJgrIFKMeXAU3/j/FNkFFPy1oZoMZ7S/0+NSoJ+v/jhS0YNcySqG4RED/N+fS5nD6ufU2GfnBb5aZ0gqAnRC7bxBC5M37qWK+GkjBwVl9dIhVreDMRgYhdO16sZax51NL9dElWYfEUb2I4h7Xoem+vWIwiK7LZHif46Tqvowg7Fg9BLYUXEF+aDWOysxI2I1NSf/Ml
Content-Type: multipart/alternative; boundary="_000_BYAPR19MB2806AE6655C5EE704644533AADA42BYAPR19MB2806namp_"
MIME-Version: 1.0
X-OriginatorOrg: certisyn.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR19MB2806.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 46141465-2d76-491c-1951-08defefef107
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2026 21:06:45.1573 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 539494d9-b23d-4e5a-bc74-62613e2403f0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tXSIk2sCo8YnS1RaeBzjqRvjFNG+erRjjDJwAye//NImumh88Wv/JEiktGeYdkdTI7eYkKTvZBUrCS5FX+Wgeg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR19MB8475
Message-ID-Hash: P3Y2AQK3IUXMGODSU4V4CBAP3YOHJY5N
X-Message-ID-Hash: P3Y2AQK3IUXMGODSU4V4CBAP3YOHJY5N
X-MailFrom: jhillier@certisyn.com
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: Pablo Play <playplay2736@gmail.com>, "hello@vaara.io" <hello@vaara.io>, "wdhawkins46@gmail.com" <wdhawkins46@gmail.com>, "Todd.Gibson@t-mobile.com" <Todd.Gibson@t-mobile.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [SCITT] Re: Closing omission from the receiver's vantage — 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/WqjuPVK3SAYIDJ-6sFb4YJUeg88>
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>
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 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. 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 truncated tail 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 event with a public timestamp, a sanctions list publishing a delta starts a clock the operator doesn't own. An operator with 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 deadline covers the tail. Two mechanisms, and I'd had 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 rested on anything outside the reconciliation server. The other two rested on a transition list published by the server, under the 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 was one in four, and the sentence claiming otherwise was 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 whether or not anything in it changed. That last part 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 the 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, because two instances of one observer aren't two observers. The distinctness test was written over the operating-party identifier alone and said nothing about the keys. Two entries declaring the same key under two different party identifiers satisfied a quorum of two with a single signature. Both entries 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 and the document concedes it. Whether two entries name one key can always be 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 before they could point at one, and Henri's suggested the substrate cite components normatively rather than restate them. Together that means the fourth item gets lifted out of ARP. So let me hand it over along with what 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 assigns to that state, not a value the answering party made up. It rides in the protected header so it's covered 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 the 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 relying party, travelling under signature into a sealed and ledgered artefact, 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 evidence instead 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 conforming encodings 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 statement of what the corpus is 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 compressed archive has at least two byte sequences with an equal claim to being the corpus, and two registers choosing differently produce two identifiers for one state, which a retroactive sweep then reads as a version change that never happened. 3. It was carried twice 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 may read either way, and applied it to the two other duplicated headers and not to this one. 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 of 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 someone states what it should have been, and the obvious someone is the issuer, the party the audit is about. 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 state 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 letting the symmetry flatter you. Supplied by a party with no stake. ARP's deadline is this one: the clock 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 where 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, and where it doesn't the statement should say which 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, which is 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 implementation is that the responding service hands them over with its response. Every check passes. The witness signature stops the service forging a statement and does nothing to stop it choosing which ones to pass on, so under exactly the fork the 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 origins and forbidding 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 convention. You wrote that a result which 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. 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 verified 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 benefits 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 from 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 weakest 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 shape this week: a verifier told to refuse a 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 pointed at it for conditions its own definition never named. Both now split. Defining the distinction and giving the implementation no way to express it is a document agreeing with 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 issue time; a profile is the weaker binding and the only one that can be agreed between parties before a run and pointed at 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 the same value, and every reconciliation commits to 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 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 Walter's setting. Worth having in the statement as one of the answers rather than 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 an 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 to fall later than 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. Same underlying 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 anchor declares 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 of mine above. None 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. Joel
- [SCITT] Closing omission from the receiver's vant… Walter Hawkins
- [SCITT] Re: Closing omission from the receiver's … Joel Hillier
- [SCITT] Re: Closing omission from the receiver's … Pablo Play
- [SCITT] Re: Closing omission from the receiver's … Henri Sirkkavaara
- [SCITT] Re: Closing omission from the receiver's … Pablo Play
- [SCITT] Re: Closing omission from the receiver's … Henri Sirkkavaara
- [SCITT] Re: Closing omission from the receiver's … Pablo Play
- [SCITT] Re: Closing omission from the receiver's … Nenad Vasic
- [SCITT] Re: Closing omission from the receiver's … Joel Hillier
- [SCITT] Re: Closing omission from the receiver's … Pablo Play
- [SCITT] Re: Closing omission from the receiver's … e.dogru
- [SCITT] Re: Closing omission from the receiver's … Walter Hawkins
- [SCITT] Re: Closing omission from the receiver's … e.dogru
- [SCITT] Re: Closing omission from the receiver's … Walter Hawkins
- [SCITT] Re: Closing omission from the receiver's … Walter Hawkins
- [SCITT] Re: Closing omission from the receiver's … Henri Sirkkavaara
- [SCITT] Re: Closing omission from the receiver's … Pablo Play
- [SCITT] Re: Closing omission from the receiver's … e.dogru
- [SCITT] Re: Closing omission from the receiver's … Pablo Play
- [SCITT] Re: Closing omission from the receiver's … e.dogru
- [SCITT] Re: Closing omission from the receiver's … Pablo Play
- [SCITT] Re: Closing omission from the receiver's … Joel Hillier
- [SCITT] Re: Closing omission from the receiver's … Joel Hillier
- [SCITT] Re: Closing omission from the receiver's … Nenad Vasic
- [SCITT] Re: Closing omission from the receiver's … Walter Hawkins
- [SCITT] Re: Closing omission from the receiver's … Vernon Wharff
- [SCITT] Re: Closing omission from the receiver's … Walter Hawkins
- [SCITT] Re: Closing omission from the receiver's … Vernon Wharff
- [SCITT] Re: Closing omission from the receiver's … Henri Sirkkavaara
- [SCITT] Re: Closing omission from the receiver's … e.dogru
- [SCITT] Re: Closing omission from the receiver's … Nenad Vasic
- [SCITT] Re: Closing omission from the receiver's … Nenad Vasic