A verdict can be kept, not re-run.

As designed, a per-judge record, a content-keyed cache and a separate scoring plane let the operator take an aggregate apart, replay identical output and keep the rubric from workers. None of the three gives a reader of the feed anything to check them with: a cached verdict is repeatable, not reproducible, and the public feed carries values and none of what they were made from.

§1Keeping each member's verdict makes the panel legible

The design these notes draw on, named at the end, scores free-form output with a panel of judges whose shape and limits are the subject of Paper 001; this paper follows what happens to a verdict after it. The design persists each aggregate with its members. Per member it stores the judge identity, pinned to an exact model string; its quality and reasoning scores; whether it was rejected; its latency and its token counts. Panel composition carries a version, and a verdict names the composition that produced it. A rubric is bound to a test version: changing how a test scores requires a version bump, so, where the rule is followed, a verdict stays attributed to the rubric it was made under. A rule records the changes someone remembers to bump, and the cache key below names a path by which it could be bypassed.

one verdict, as the design describes its fields · no rows are published
aggregate     quality, reasoning
composition   version
test          id, version        the rubric is bound to it
member[ ]     model             an exact model string
              quality           integer, 0–100
              reasoning         integer, 0–100
              rejected          true | false
              latencyMs, tokens

Keeping the members is a storage decision, and without it nothing below is possible: an aggregate stored without its members cannot be taken apart later. It is also a record for the party holding the store. The record is the operator's own account of its own panel, the position The Delegation Record calls self-attestation, where labelling "does not lift the record out of that position; it makes the position legible".^[1] A store its operator can edit or truncate says nothing about rows no longer in it; of a verified chain, The Project Handshake puts it as "the one attack it structurally cannot see is omission".^[2] The design describes no commitment of verdict rows to anything the operator cannot rewrite.

Versioning has a boundary of the same kind. A version bump records a change the operator makes to a rubric. It cannot record a change in a judge's own behaviour under an unchanged model string, because the field naming the model is filled in at the far end, by the party serving it, and nothing between that party and the record checks it;^[3] a judge that drifts under a pinned name moves scores while no version moves. And a version shows that something changed, not that the rubric measures what its name says. An unpublished rubric is as uncheckable at a late version as at its first.

§2A cached verdict is repeatable, not reproducible

The design keys verdicts on content. A verdict is stored under panel composition, task hash and output hash, and, as described, the cache is consulted before a judge is called. When an endpoint returns output byte-identical to output already judged for the same task by the same composition, the stored verdict comes back and no judging runs. That saves inference on repeated output, and it keeps the record consistent: identical output, identical verdict, for as long as the entry exists.

It does not make the judges deterministic. Atil and colleagues report that "outputs can vary for the same inputs under settings expected to be deterministic", and that among the models they tested "none of the LLMs consistently delivers repeatable accuracy across all tasks, much less identical output strings".^[4] Their experiments measure task accuracy on five models, not rubric scoring, so they establish that the variance exists and say nothing of its size in a judge. What the cache holds is one draw from a judge that might have drawn otherwise. Served again, it hides the spread a second judgement would have shown, and a wrong first verdict is replayed to each later identical output. Re-judging a sample of cached keys, and publishing how often a fresh panel disagrees, would size this; no such check is described.

The key is also only as current as its fields. Composition is in it, so a changed panel judges afresh. The rubric version is not among the fields as described, and whether the task hash covers the rubric, the judge prompt template, the decoding settings or the rejection rule is unstated. If it covers none of them, a scoring change that leaves composition alone could be answered with a verdict made under the old scoring. That is an open question about the design, not a defect found in it; nothing available to these notes settles it.

§3A worker holds no rubric and still writes what is judged

The design runs judging only in a central scoring plane, apart from the fleet that measures. A probe worker submits a raw transcript and its timings; as designed, it holds no rubric and no scoring authority, and cannot edit a stored verdict or the rule that produced one. The fleet, and the checks a result passes before it reaches the panel, are the subject of Paper 004.

Isolation narrows what a dishonest worker can do; it does not take the worker out of the score. The worker supplies the thing that is judged. It can fabricate a transcript, truncate one, or add text addressed to the judges rather than to the task, and a judge reading the transcript reads that too. The endpoint's provider is outside the isolation as well, since the output is its to shape. The worker also supplies the timings, which no judge reads. For a partner worker's result, what the design puts between a dishonest submission and a score is admission, not isolation. In the design, a first-party result is the baseline others are checked against and is not staged, so a compromised first-party key is covered by neither. Paper 003 treats a measurement as a signed claim and says what a signature does not prove.

Isolation also moves trust rather than removing it: the party that can change a rubric, a panel, a threshold or a cache entry is the operator, in one plane, and nothing published shows a change made there.

§4What a reader cannot check today, conceded first

These notes describe an architecture. They publish no rubric, no prompt set, no panel composition, no test suite, no aggregation or rejection rule and no calculation for any published field. The Delegation Record's Paper 007 names what would make a score's soundness answerable, "a published method someone other than its author can re-run, or … outcomes measured on a named corpus",^[5] and nothing here meets it.

What a reader can check is the public delayed feed, and it shows little. Read 14 September 2026, /v1/scores lists 18 model series from five providers — anthropic, deepseek, google, openai and xai — each on access path api, delayed one hour at hourly resolution; /v1/history holds the same 18 series as 2,938 hourly points over seven days.^[6]

/v1/scores · one of 18 series · read 14 September 2026
printed for its fields: identity and score values withheld
{"provider":"<provider>","modelId":"<model id>",
 "version":"<model id>","accessPath":"api",
 "overall":<number>,"quality":<one decimal>,"reasoning":<one decimal>,
 "speedTps":294.3,"status":"healthy","samples":371,
 "asOf":"2026-09-14T13:26:32.133Z"}

absent   member scores · rejection flags · composition
         rubric or test version · region · signature
version names the model's version, not the test's

1. Withholding prompts cuts both ways. A published prompt set can reach a newer model's training data; a private one cannot be re-run by anyone else. The current case is the private one; these notes say so and take no position on the choice.
2. Publication would not reproduce integers. Even with a method published, judging again is a fresh draw, so a re-run means running the method and comparing distributions, not reproducing each score.