[SCITT] Re: A page for independent runs of the Vaara conformance vectors
Joel Hillier <jhillier@certisyn.com> Fri, 21 August 2026 22:56 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 C559412DA145F for <scitt@mail2.ietf.org>; Fri, 21 Aug 2026 15:56:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787352987; bh=kwktaS+upK3M8EbwMs23MisTD+UiQtxF0ooZnUa+vwI=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=KZjLFgvi1cJZkrHTtLrvVzI1hq9Eno5RGXPDnwK+9x3apZKA4hIFFNBlAq6YNS1R7 vIbwYCPQnCknGshKfVoRc74q2Lz/ZlQPmHkbRmNenlaAiLaf6UA9E8/eOTa478A8PQ uusxojAi8lSwvE9iFQYjh+jgocPBM4mFNslGPZvM=
X-Quarantine-ID: <bZIlKVMyAJdj>
X-Virus-Scanned: amavisd-new at ietf.org
X-Amavis-Alert: BANNED, message contains .txt,draft-hillier-scitt-arp.md
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=certisyn.com
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 bZIlKVMyAJdj for <scitt@mail2.ietf.org>; Fri, 21 Aug 2026 15:56:26 -0700 (PDT)
Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazon11021133.outbound.protection.outlook.com [40.93.194.133]) (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 1629112DA1439 for <scitt@ietf.org>; Fri, 21 Aug 2026 15:56:25 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JId7gncHhvGaDPO26SkPyPpCfZMa1wNr47YfnpbuMDkBAruYU5J5kUEAcHq43D0PqfxQz60lT4T19+bZvp1YejcG9JtVzj+et0+VnHjnUXKlofYujkwkLuih7Ar8YEl0U+wv1a9Cx+nG6nQuQhOzP6enyfJXzA6HKy9asS3W+g/GCrlkcWPpgct4XPrZLGSIKVY0lmkdlxzEhkcElGZtC40UhTo2tqJFBdfIv0qkoIa3JwU/kyhkhhuZMWVba7JO0xuLeTUNmuUCtnn2eBN+4/bATABP1pafgFCTgjS+VXrMQVj8SYGqcfBDVuvdRiHAVPzjHWSzbWqTjtw1h9clxw==
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=44GrHLOTuF9iE3/As/RDVUBXBBLGaSBG+kIHyOe8xpE=; b=QHQ0xZo3JSnzq1KSP1CqTOh/vwnNy7WJxdFLM5aEQHQvx1AYUuHpzhQPQeFuX+YqDLGwOx9UYP4/iOcWzrZA6r99V1wIMpFc7Eb3gKl10QdlBtvYpMh+V5a2rJEmpyP8zTEBy7JqLr+KIhuWjKWE/US0+vQgchx0pfHTQXTLzmy6WXAyn1JARmGrzkLv9QLKUHTfap9iS2PmgeyEXn9DPlFusMQs8TUoyzhQv7xTtN8hxe4gzegQSg+SYN7VwMX/xc5BDJnq8Qe+JM6XA0ndvE0CeUWj6Z++PBUo+RTHM48bUpPfrzrtqJgvvY9a+bGaG50ZppoSOkLu2e8GK4I+gQ==
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
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=certisyn.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=44GrHLOTuF9iE3/As/RDVUBXBBLGaSBG+kIHyOe8xpE=; b=NIzGpSXdzViaHMT7dV7mZCiXwZZzZpf0G7TTotw5psKh+0rYaFPab7Unyfmhfe2ujs5tnYtlPvJ9Ut00HgnxvCR8ZXxswZQEpBZegXEdjiNF8MPs2Ih6Sjp5anC2B+SRfLkC47/3BoE6W8+tXqQAEX37HcTA25hJnMPUbutg5e47sdAESXiqiQIJsFsfLrFHtvGU5W2zdSa1uRr2GR2pwqRhbpc7kCXhNdzp+dzUxbkOHJaVm4gOBm37i6a0+YyPQ9dX0A8nhhVfVlDiBBPfB2FVNOEKf9LyiulG15GYUfGy2wSgqhQi/6F9N8CgKZtjxkc//Ro32nmU4p6e3fA8og==
Received: from BYAPR19MB2806.namprd19.prod.outlook.com (2603:10b6:a03:fa::15) by PH0PR19MB5474.namprd19.prod.outlook.com (2603:10b6:510:fd::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.10; Fri, 21 Aug 2026 22:56:14 +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; Fri, 21 Aug 2026 22:56:14 +0000
From: Joel Hillier <jhillier@certisyn.com>
To: "scitt@ietf.org" <scitt@ietf.org>
Thread-Topic: [SCITT] Re: A page for independent runs of the Vaara conformance vectors
Thread-Index: AQHdMS3WbpdhPlu2BECfbDaFZS4CDran/VKAgAB+KICAAB26gIAAAZiTgAAS1gCAAANjlA==
Date: Fri, 21 Aug 2026 22:56:14 +0000
Message-ID: <BYAPR19MB28068979FB3C9D71AF99653DADA32@BYAPR19MB2806.namprd19.prod.outlook.com>
References: <TpUyxx5ABMjWSmfHKAapGrveJcPcen7ixrikIXT4TPILEwwp7bSORsZTKSCIack7ylQyz7tf_V4p4JiD6Ns0bnUoQ_pliWSJ_CsFLvStQEk=@vaara.io> <BYAPR19MB28069B0FEA3E8F8BB3474D28ADA42@BYAPR19MB2806.namprd19.prod.outlook.com> <Oy1hoH0AG0EmM4SI5S3sqz_u01myZ_S9OTioBGsSUr7AUH6P5FKrt1381rlyQsen-lZ3BoeM_vyodZ-OSpOARE6PSQsBkb8m1oflcrjDOts=@vaara.io> <CAOfgHgp1SQK6hAD49q6HgQKFf-oFTfzb7+TqeRqpXwCrWS28=Q@mail.gmail.com> <jRa8V5Nbs2SJjMUUlI1GVK-lghWHrEUAUjgkDX5Y47lMwAOqbIqeccI4aTggNg_UZ5C2896E5P2m1TCklYar_Rq_npSF6vzYQSX1b98LoxU=@vaara.io> <CAOfgHgq7vOgeqJEY5Gc9Ko65Wwf7Tu+E_VGGd4POUfENT372Nw@mail.gmail.com> <BYAPR19MB280625CA19A9FD936AFDC56EADA32@BYAPR19MB2806.namprd19.prod.outlook.com> <1787328798802386477.1787328798@conarium.dev>
In-Reply-To: <1787328798802386477.1787328798@conarium.dev>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
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_|PH0PR19MB5474:EE_
x-ms-office365-filtering-correlation-id: a3bfc1a6-8916-495b-3a38-08deffd766ed
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|10070799003|1800799024|366016|6049299003|23010399003|18002099003|22082099003|4143699003|56012099006|3023799007|8096899003|4053099003|38070700021|6133799003|5023799004|10067099003|7055299009;
x-microsoft-antispam-message-info: qzQDw6pVlGfyOqBG4B0tNnbylJi/FWWNgu8zF1gF3KD8fYv3D5NTI2coS6D7l1Nc/40diEx2iGJXL2iY98oUvxBaAG7SW6RRnZz93Jkk7oYH/jqpaYygX+6A79VRMU/Qe9GjInJfsA32c80dPEWAloXkCl7E7jMGc+7HnjfDqz1FgtSBQTFVbUuR7phQQSyFY2/OaXjjvY+cjw4G5RZ4arUn+Gkl/qadw+spdx+NSYDIQ2AgZ3KRfWYFCH9vVqPRi4RWcuz9IE9j2bPUywCm34LWIdEyhpi0BBvWWR3cOLqOZflSNjgQrbEMaYCt99X1BIK4rsXEKIKtLQ/SoLeez/m2NoYIPwTRvwOECTRYksNxs3HKvFI8jmHdI3w9c6XoywtXlEWhS2Tm2pQLaKK9D5wTpslHn8ymMbD/kz4gqEaO3Gq3ErF39GerKcfg9/1Sc1TVdQ5pmnfKDEfwTNLq2qgKnULviTXasR2NB8eiUvL+Cc1dYnNt3WLn3i4u3nY6UzHkPdmWPTTULYml3XQvOhiimgkqplVvZ1zA8uPekwpyW4k5Yn/XNAU+CeslkVMO0g0ymJ4S+wCqnFSpQ1+Nqyo6Ynn5ApJ6gMxe1g1MpxfwPSD9pLtGtc4o7JVV/5zoNuafhWKFknHi9EztP0uCHg==
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)(376014)(10070799003)(1800799024)(366016)(6049299003)(23010399003)(18002099003)(22082099003)(4143699003)(56012099006)(3023799007)(8096899003)(4053099003)(38070700021)(6133799003)(5023799004)(10067099003)(7055299009);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0: lRLPeQUZXa3qUXF8xeJBJhVSGXwRJ82whCb1T4wyOQLbdk2XL+/UefJldywYBSc6g+dk36biS+2DJvxpJadz/H1bq0pkV5dZFLKyXe6ueWqQ08Nu9IuLZ2IwDsIi3WlBV/Y5Qjmf2WftXUNjX3Q3Ot0RMgGiAGoTDFIMjNPs2N1OPaxAsSySrkU96O9fU8zYl9jxO/nVd1J1x0atCsOrIMA9NJ3rm3JSArA0ABeJbXh04idqAUuzJDLJL0r00EfktPBswk3qMoZLwqS7MjYHPoC2ugWdbZ1taZ0wG63ngU2a/1Vj/YwrFofQbTAmxjy2vcvwJLtXpGF6BHQdGhihC4OTM8p8lIeAt8KjmtqGP1GspCJ/s1C53HVjv/awyT7JNmfzS8NDjNfhScdUUvjF+7TLirxC3ErwOJAqG5z82sBwATasjliZd3Bph79brNh/0E25ry0kSTa/rEHP8nc256YC/AkWrjXG6lRS61gCD/JfcIAMLqGdRrBqj5ORfOXYypjy6HuABozxPawIF8ZL2r4E2n7et27L5zwk99+oCnxnZyz4+io69pBMKp/4upchw3vn94Ll2e/y31Id+ICzIyyE2oHMmNa4t/SWxjid9DyUoaCp63UROjoRKWCV3fRF3hWvytdVIiWpdGrHZlGr+WgiI8qyKfMkoJF4u/gulrxWV0LaMM3yaH1gRqrH7oTeX4NAhWDmCZT3iRyd+viIq7o4DsZmMHdnjEyVvws4car4QaIDWL9sWH+sM6Tqh8f23kFzZcz9zuqH19mqz8Mi1lKp7yLveJhV/u62h08lsCvS6g0slBHDz+bH8zWCwjshIYj7irSXi/YeMUgwOc4OSjUehVSuQ8nfV1VYgFjcu7v1BQFpQRkJntGpN89//xeoBeCXO8MK4E2nOUjoGrQ+R/7kgYTeN65EvkWu9dVPpsUll7ikShEUVebnH+CWok3eTjjuPw4RFGH7CUBtLLbHYG9uE8Cq/lewxeI7zmC8p+1PHGjCV7gj5ypZqKpBR6/GXdiqy3ZHxh3VpzPV9qrLp1n5MPEn8PCglQKUoYvzAI0fjKRcy0AqAkIidZVf+qxSOVJAnQqPTunALqO6qQsa9b/qxohFS+QMxwrn4dAuMxle2QP+nV/iTh1Ym+MFOxCO4zmcC8eH9dJ39VTyqELAIgWcT52cHAltNvQXQVFjlgmrauNF/jxBes4WMuxzLiimsfsuVutXUrTjbPn4ciPWwBWmKz0K4ZUV2fYG7T4IKBo556RvVkwOJLdHFDqFDjyowWdRmULyo/C6ZjE8O8UHgmG9vOY9YPhJmRHdXdrmg2D5wTpW14VNXZRMkIEevhF4OITGk/2X9MNaLwvWnEk966wk+3PqScFd1C5XkihUifGjt20bvwNkVdwokLA1ZpgZdDAtM/Mu4ZSVMNgKonAZIlH9J5XcdUZcDS0i9gX0lw1hA7tpJsahxPUgnX/M+jDH1sXKB9x2LEqADZOesT0oVNjIi+S3eS0D07SEOYJRZt3HZYvJECdNqXeUHbcfWmLmwBi4aQrLrYtu64lmgdHa8Mxn9GoFKVhbcbg3ZAKT7f2y2Hfmnyi/h3KAE06j9gf22Tj9qUw8rHP6mKi8KJmPUK51Kxpoj+/Ds0532NHmzXs0t52+memtKVF9qPVFY5AJ38yiIP1GFzEjf2qQFD+TEaEa5eJT/X5K0Tcr49s0vtGILVe/yJEJG3wEW/FQoTbojkt37mRfA2t6yxxM+Q21GOeCzzqXk0pDq5oa2oYr4J9J1ytwNonbOM2kKGv2d7Zu1KvekP5D
x-ms-exchange-antispam-messagedata-1: OVLtli5/TiN+Iw==
Content-Type: multipart/mixed; boundary="_004_BYAPR19MB28068979FB3C9D71AF99653DADA32BYAPR19MB2806namp_"
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: a3bfc1a6-8916-495b-3a38-08deffd766ed
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2026 22:56:14.2781 (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: e2yEgwc9/9hfFsLYO0FbVvqm+gKtBDLBtKXKf4p0qCBZES+ydO2ApAcInf226OnlbVlet113Ts5tUX0WSFKdOg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR19MB5474
Message-ID-Hash: 73BBSSMQERQUNEDAP6L5XVGPTUREZRKN
X-Message-ID-Hash: 73BBSSMQERQUNEDAP6L5XVGPTUREZRKN
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: "hello@vaara.io" <hello@vaara.io>, "team@emiliaprotocol.ai" <team@emiliaprotocol.ai>, "wdhawkins46@gmail.com" <wdhawkins46@gmail.com>, "tiago@donttrustverify.pt" <tiago@donttrustverify.pt>, "anton.sokolov@tyche.institute" <anton.sokolov@tyche.institute>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [SCITT] Re: A page for independent runs of the Vaara conformance vectors
List-Id: "Supply Chain Integrity, Transparency, and Trust" <scitt.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/scitt/eIUdjp_Y1DdobB2E7-uAvcT--Qg>
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 Emek, Henri, all,
The row first, because I said I'd file one and a promise isn't a row.
@conarium-ai/core@0.2.41
tarball sha256 3e4f34e679acb84539001a38e084321cc6e45867b9552be85438197987d93314
Node v22.22.2, Linux, extracted into an empty directory
13 of 13 agree with the published manifest.json exit codes
You ran it on Node 24, I ran it on Node 22 on a different operating system, and every case landed on its documented code. No install, no arguments beyond the file, exactly as you said.
Kind: reproduction of the author-supplied checkers and vectors. Your binary over your cases. It establishes that the tarball runs and is exit-stable on a second Node major and a second OS, and it establishes nothing about your wire format, because I didn't implement anything from it. Naming that is cheap now and impossible after somebody cites the row.
Then I probed the thing you disclosed. You named three routes to exit 20. The probe reaches two more, and the second is worse than an exit code.
exit=20 no file argument "missing <file|dir>" named by you
exit=20 unknown flag "unknown flag: --not-a-real-flag" named by you
exit=20 schema-invalid receipt 007-schema-invalid the documented meaning
exit=20 path not found "path not found: does-not-exist.jsonl" not named
exit=20 valid JSON, not JSONL "invalid JSON in <file>:1" not named
That last row is the one I'd fix first, because the message is false and not merely the code. The parser is line-oriented, so a pretty-printed JSON file gets its first line, an opening brace on its own, handed to JSON.parse as though it were a whole document. Isolated by construction rather than inferred from the symptom:
pretty.json {
"a": 1
}
-> exit 20, invalid JSON in pretty.json:1: Expected property name or '}' at position 1
oneline.json {"a":1}
-> parses, treated as a receipt
pretty.json is valid JSON. Python's json.load takes it without complaint. The tool tells a user their file is invalid JSON when it is valid JSON, and the real fact is that it isn't JSONL. Two different things, and the one it reports is the one that isn't true.
Where a user meets it is directory mode. Pointed at test-vectors/ it reaches for expected-hashes.json, one of your own metadata files, and reports it as malformed. Pointed at a directory of receipts it's perfectly happy, so the intended path is fine and the adjacent one isn't.
Exit 13 names two events as well, which I think is worse, because 13 is a claim about cryptography.
exit=13 VALID file, no --pubkey "no --pubkey given (refusing to skip signature checks)"
exit=13 missing file, no --pubkey same message, and the file is never opened
exit=20 missing file, WITH --pubkey "path not found"
The first line is the control that separates the two explanations: 13 for a missing pubkey fires on a perfectly good receipt file, so it isn't an artefact of the missing path. Documented as "signature invalid or missing while a pubkey was supplied", and returned when no pubkey was supplied. The refusal itself is right and I'd keep it, and the message says plainly what happened. It's the code that's wrong, and wrong in the direction that costs, because a caller scripting on exit codes reads 13 as the cryptography having failed and it means a flag is missing.
The second line adds the ordering. The pubkey check fires before the path is resolved, so on an invocation wrong in two ways at once, 13 wins over 20 and the run answers with a signature verdict about a file it never opened. Which of the two a caller sees is a fact about check order rather than about the run, and that's your own short-circuiting finding arriving inside your own CLI.
Two clean results, since a clean result is a result and the probe was built to find failures.
--anchor-check on a chain carrying no anchor returns exit 15, not 0: 0/1 anchored, nothing was compared. That's the rule you described to this list working exactly as described. The probe was written expecting a 0 there and would have reported one.
The empty chain returns 0 with a warning saying in terms that this is not a verification that nothing was deleted. The warning carries what the exit code can't, which is the honest arrangement once a code is published and can't move.
Your drift guard's blind spot is the fourth arrival of one shape this week. It compares the set of codes in the binaries against the set in the table, both directions, and 20 is in both, so it's green. A code naming two events is invisible to a check over the set of codes.
The same shape landed on my side today in a different vocabulary, and you found that one: ABSENT covered a digest that could not be checked and an instruction a recipient cannot follow, and a checker over the set of verdicts couldn't see it. Same defect, same week, two tools, neither author looking for it. A check over the members of a set cannot see a member that means two things. That belongs in the shared text beside the weakest-rung rule, because it's the rule that says why the weakest-rung rule has to be enforced somewhere other than in the enumeration.
________________________________
Now the defect you found in what I shipped, which is the better half of this message.
You're right that runners/verify_manifest.py isn't in the archive while REPRODUCE.md still tells a reader to run it, and right that a reader following the file in order hits it at exactly the step whose stated purpose is catching stale digests in that file.
The part worth reporting is where the check stood at the time. check_reproduce.py did report it, among ten ABSENT invocations, and the packaging step passed it through, because ABSENT was a single verdict covering two unrelated conditions. A pinned digest over a file a subset doesn't contain genuinely could not be checked, which is the case the three-way verdict was built for. An instruction to a recipient naming a file that isn't there is a different condition entirely and belongs to the package, not to the digests. One label, two conditions, and the run gave a reader no way to tell them apart. Which is the finding above, one layer down, in my tree rather than yours.
So: a fourth verdict rather than a note. SUBSET.txt lists every path deliberately excluded from a package with the reason a recipient is owed. An invocation naming a file that isn't present is EXCLUDED if it's declared there and MISSING if it isn't, and MISSING exits non-zero. Silence is no longer an available answer. It carries a mutant: remove verify_manifest.py from the declarations and the run must fail naming it. That mutant is your finding, restored as a test. Six mutants on that runner now, six killed.
Your network correction stands and the wording is repaired. "No network at run time" is wrong. The existence-oracle runner stands up an HTTP server on 127.0.0.1 and connects to it over loopback, because a timing discriminator without a real round trip measures nothing. No connection leaves the machine, which is the narrower and correct claim, and REPRODUCE.md now makes it in both places.
What I'd keep is your method rather than the correction. You read the imports and the call sites before running any of it rather than take the sentence on the word of the person who sent you the archive. That's the only thing that makes such a sentence worth anything.
One thing in your message that doesn't hold. You wrote "Six is what your message listed." It listed eight, checked against the sent bytes rather than from memory:
run_deterministic_encoding_vectors.py
run_existence_oracle_vectors.py --timing-samples 60
ecdsa_malleability_probe.py
merkle_equiv.py
check_self_claims.py
mutate_self_claims.py
check_reproduce.py
(cd runners && mutate_reproduce.py)
Your self-correction is right in substance and you found the two you'd missed without being told, which is the part that counts. The count you attributed it to is the one thing that isn't, and the shape of it is worth a line: a correction about taking a count instead of deriving it took a count instead of deriving it. That's the failure mode being unusually well-behaved as a specimen.
Your kind field, applied back at my own run too. You're right that your ARP run is the first kind, my runners over my vectors, establishing that the archive runs somewhere other than my machine and nothing about the ARP text. What's worth pointing at is that you filed vaaraio/vaara#612 with the kind already named, because Iman's scoping was in front of you. That's the field being used before it exists in any format, which is the strongest evidence it's the right field. Henri, two rows now map cleanly to the first kind with no amendment from either of them.
On your freeze, and the part you don't have. Refusing to write the interpretation notes now is the right call. A note written after reading my concession is a reading that has already met mine, and hashing it would produce an artefact whose whole claimed value is a property it doesn't have. The absence, stated, is worth more than the document. That's the weakest-rung rule applied to a piece of evidence you'd have benefited from producing, which is the hard direction to apply it in. Writing the notes first and hashing them before opening a class nobody has seen is the version that works, and that's the shape I'd take next round rather than the one I proposed.
And on clause three, since both implementations failed it today. Yours carried a sentence removed from your specification hours earlier for being false. Mine said three named fields were in a document where they appeared zero times. Your release gate caught yours in the document and nothing caught it in the mail. My self-claim checker caught mine in the document and nothing caught it in the mail. Same clause, same day, two implementations, no mechanism on either side.
There's one now and it's in the archive, so borrow it or improve it rather than build a second. check_correspondence.py over a claim table, which is your design: one row per claim made to somebody, rows added by hand because deciding which clause is a claim is a judgement a runner would make badly. Nineteen rows, zero failing, five mutants, five killed, and mutant 1 is the clocks defect restored.
Building it produced three results worth more than the runner.
One. It survived its own mutant on the first attempt. PRESENT is satisfied by any mention, so renaming a mechanism's defining occurrence while leaving a cross-reference standing passed. DEFINED was added, and the mutant now kills.
Two. Three rows were added for claims in this message and two failed immediately. They were claims about the tooling being evaluated against the specification, because a row had no way to name the artefact it was about. A claim about one artefact verified against another is not a check. The table now carries a target per row.
Three, and this one only surfaced because the first target assignment was also wrong: REPRODUCE.md documented neither SUBSET.txt nor the MISSING verdict. The mechanism existed and the file a reader is told to follow never mentioned it. Now it does.
The standing gap, stated because it's what will bite next: the table holds the claims somebody wrote down. A claim made and never tabled is invisible, and the runner says so on every run rather than letting a pass imply coverage it doesn't have.
________________________________
New archive, carrying your seventh point. All earlier ones are superseded.
package digest 123710c156a1e0995542c2b97d00a2370719fdeeda189e95a816766f440da6cd
archive fc6db0d463875ef1fd2a0e12896362a8c81db973b083095719a0cd2a46fdd6b0
members 27
root the package root, the directory containing
draft-hillier-scitt-arp.md and conformance/
The root is the first line of MANIFEST.txt and inside the digest, so it travels with the bytes and can't be restated afterwards without moving the value. The working for why it was needed is on the other thread.
self-claims 11 checks, 0 failing 11 mutants, 11 killed
reproduce 43 pins, 0 stale 6 mutants, 6 killed
correspondence 19 claims, 0 failing 5 mutants, 5 killed
section 3 10 runnable, 10 declared excluded, 0 MISSING
Extracted into an empty directory and all ten commands run from there before sending, including the two-minute one, with both pinned run records reproducing byte-identically from that extraction. Stated at that precision deliberately: the previous message said "run from there" on a package where four of the ten had been, so the claim now names the number.
Emek, the Windows note is useful. The runners are clean on a console without forcing UTF-8 because nothing in them prints outside ASCII, which was untested until you named it and is now a rule.
Joel
- [SCITT] A page for independent runs of the Vaara … Henri Sirkkavaara
- [SCITT] Re: A page for independent runs of the Va… Joel Hillier
- [SCITT] Re: A page for independent runs of the Va… Henri Sirkkavaara
- [SCITT] Re: A page for independent runs of the Va… Iman Schrock
- [SCITT] Re: A page for independent runs of the Va… e.dogru
- [SCITT] Re: A page for independent runs of the Va… Henri Sirkkavaara
- [SCITT] Re: A page for independent runs of the Va… Joel Hillier
- [SCITT] Re: A page for independent runs of the Va… e.dogru
- [SCITT] Re: A page for independent runs of the Va… Henri Sirkkavaara
- [SCITT] Re: A page for independent runs of the Va… e.dogru
- [SCITT] Re: A page for independent runs of the Va… Iman Schrock
- [SCITT] Re: A page for independent runs of the Va… Joel Hillier
- [SCITT] Re: A page for independent runs of the Va… e.dogru
- [SCITT] Re: A page for independent runs of the Va… Joel Hillier
- [SCITT] Re: A page for independent runs of the Va… e.dogru
- [SCITT] Re: A page for independent runs of the Va… e.dogru
- [SCITT] Re: A page for independent runs of the Va… Henri Sirkkavaara
- [SCITT] Re: A page for independent runs of the Va… Joel Hillier