A measurement is a signed claim.

A probe fleet that signs its results can say which enrolled key signed a measurement and that the signed bytes have not changed since. It cannot say the measurement is true: a signature binds bytes to a key, not to the world. These notes set out what signing establishes in such a fleet — the encoding, the bundles, the keys — and where the signed chain stops before it reaches a reader.

§1A signature binds bytes to a key, not to the world

A probe fleet is distributed for a conditional reason: if an endpoint behaves differently depending on the network it is reached from, one measuring machine cannot see the difference. The condition is stated here, not found: these notes hold no measurement of endpoint behaviour by region. A fleet spread across networks, some of them run by parties other than the operator, is also an attack surface, and the design these notes draw on answers with signatures: each worker enrols an Ed25519 keypair and signs each result it submits, detached, over a canonical JSON encoding.

What that buys is exact and narrow. RFC 8032 gives Ed25519 deterministic signing, and signatures that "are not malleable due to the verification check that decoded S is smaller than l".^[1] A valid signature establishes that the holder of an enrolled private key signed these bytes and that they have not changed since. It establishes nothing about whether the probe ran, whether the endpoint returned the transcript inside them, whether the timings are true, or when. A worker that fabricates a latency signs the fabrication as validly as a worker that measured one.

Signatures do change what agreement can achieve. Lamport, Shostak and Pease showed that "With unforgeable written messages, the problem is solvable for any number of generals and possible traitors".^[2] That is agreement on one value. Colluding workers reporting the same false figure agree in exactly that sense, which is why Paper 004 treats consensus as agreement, not accuracy.

§2Where the signing starts, and where it stops

The design names three signed objects: the test bundle a worker runs, the worker's own code, and each result it submits. What happens after submission happens in central planes and carries no worker signature. Judging of quality-scored output is done by the panel of Paper 001, which holds the rubric the worker does not,^[3] and the aggregate is computed from what survived. Whether the operator signs those steps for its own use is not described; nothing in the two feed endpoints read on 14 September 2026 carries such a signature.

The design's own description speaks of "a chain of custody from test definition to published score"; these notes cannot use the phrase. The chain stops at ingestion; to reach a reader, each aggregate would have to commit to the signed results it used, under keys a reader can obtain. A signature also cannot see what was never submitted or never promoted — in The Project Handshake's words, "the one attack it structurally cannot see is omission".^[4]

publicapi.frontierscore.ai/v1/scores · models[0] · generatedAt 2026-09-14T14:28:00.505Z
{ "provider": "openai", "modelId": "<model id>", "version": "<model id>",
  "accessPath": "api", "overall": <integer>, "quality": <one decimal>, "reasoning": <one decimal>,
  "speedTps": 294.3, "status": "healthy", "samples": 371,
  "asOf": "2026-09-14T13:26:32.133Z" }
identity and score values withheld: the method that produced them is unpublished, see §5
"version" is the model's version: it equals modelId outside the six anthropic series

absent from each of the 18 records: signature · key id · worker id or tier
                                   bundle or test version · region
                                   commitment to the results aggregated

§3Canonical JSON is more than one encoding

The design's description says "Detached signatures over canonical JSON", which reads as a specification and is one name short of being one. A verifier has to rebuild the signed bytes exactly, and at least two documented schemes carry the name. RFC 8785, the JSON Canonicalization Scheme, says JSON numbers "MUST be expressible as IEEE 754 [IEEE754] double-precision values".^[6] The dialect linked from The Update Framework specification, documented on the OLPC wiki, forbids what JCS admits: "Floating point numbers are not allowed in canonical JSON."^[7]

That matters for this kind of record. The feed's records carry fractions — a speedTps of 294.3 in the record printed above, and scores given to one decimal place.^[5] If signed results carry numbers like those, the scheme decides whether they are signed as numbers or must first be re-encoded as strings or scaled integers, and a verifier has to know which. The design names none, and that is a gap to state, not to fill.

What goes inside the signed bytes is a second choice. A result that does not bind its worker, bundle version, target, sequence and time window can be resubmitted into another window and still verify. The Project Handshake chooses its signed fields by enumerating the replay attacks and letting each one add exactly one field;^[8] the design lists no signed-field set.

§4A signed bundle stops substitution and little else

Tests reach workers as signed, versioned bundles, and worker code updates are signed and pulled from a pinned registry. Signing an artefact stops one attack: a substitute delivered in its place. The Update Framework specification, version 1.0.36, lists what an update system is meant to resist beyond that,^[9] among them "Rollback attacks", "Indefinite freeze attacks" and "Mix-and-match attacks", and key compromise, which it answers with thresholds and separate signing roles.

Mapped onto a fleet — the mapping is these notes' reasoning, and nothing available to them shows the design implements TUF or part of it — each is a concrete failure. A worker held on an older bundle runs an older test and signs its results validly; that is caught only if results bind the bundle version and the centre refuses stale ones, and neither is described. A bundle at one version beside code at another may be a pair that never shipped together. If one online key signs bundles and code, it is one compromise away from signing for the fleet, which is why the specification keeps automated keys out of the roles clients trust for installation.^[9] And pinning a registry pins where an update comes from, not which bytes it holds. A digest pins bytes.

Signing offers no secrecy. A bundle on a host a partner administers can be read by whoever administers it. The worker holds no rubric. If, as a test definition implies, the bundle carries the prompts, a partner host can read them, and a prompt set known outside the operator can be special-cased. The same exposure follows from publishing a prompt set so a method can be re-run; these notes do not resolve that tension.

§5What a signature cannot carry, stated first

These notes describe an architecture. For this paper they publish no signed-field list, no encoding and no worker keys. The Delegation Record Paper 007 made a published method someone other than its author can re-run, or outcomes measured on a named corpus, the condition for calling a score sound, and recorded that frontierscore.ai's public pages, read 12 September 2026, link no methodology.^[10] That condition is still unmet.

1. A signature is as good as the key's custody. On a host a partner administers, whoever administers it can read a software key and sign valid results with it. Binding a key to a measured environment is remote attestation, which the design does not describe.
2. Past signatures outlive a compromise. A result signed before a compromise was noticed still verifies. No revocation is described, and the record's account of what a revocation cannot recall applies.^[11]

None of these is a reason not to sign results. They are the reasons to call a signed result what it is: a claim someone can be held to, not yet evidence someone else can check.