Evidence

Transcripts first, then the measurements whose transcripts are not yet public, then a reading exercise that ran nothing. Each measurement opens with the state of the machine it ran on. A platform not reached is UNPROVEN.

Published transcripts

In docs/results/, one run per file, each opening with what it measures, the machine's state, how to re-run it, and which platforms it leaves unproven. Usernames, machine names and addresses are replaced with placeholders; nothing else is edited.

Also there: what incumbent tools do with a damaged model file (G1–G3, C2, C3), and the cost of hashing on write and on read over 8 GiB (B1, H1), from the content-addressed store that preceded abstraction-storage.

Interrupted transfers, four tools

2026-09-07. A laptop-class Windows 11 machine on mains; the tools under test ran in WSL2 Ubuntu on ext4, other work ran on the machine throughout, and loopback runs with visible spread were repeated. dl built from that day's tree. Transcript not yet public.

8 GiB from a local origin, killed with SIGKILL at 3 GiB, restarted with the same command. The origin logs the bytes it serves, so what a tool re-fetched is counted at the server and needs no cooperation from the tool.

dl is the only tool that resumes without being told to, and it is not the one that resumes best. curl and wget with no flags re-fetch the whole 8 GiB. aria2c re-fetches the whole 8 GiB even with -c, because its control file is written on a sixty-second timer and a kill inside that window loses it; told to save every second it still wastes 300 MB. With explicit resume flags, curl and wget waste 4 KB and 7 KB against our 11.6 MB, because they append to a single stream and have no ranges to lose. dl resumed with one request where aria2c used thirteen: a resumed dl drops to a single stream and does not re-partition the remainder.

What survives the kill differs in kind. dl leaves the partial file and a job record naming the artifact, its size, its source and its progress; dl list afterwards prints the transfer as a thing on the machine, not a thing inside a dead process. curl and wget leave a file and nothing that says what it is or where it came from. aria2c leaves a preallocated file whose size on disk is not what it holds.

The server that lies

2026-09-08. The same class of machine on mains, native Windows rather than WSL, other work running and not quiesced. Origin on loopback, 512 MiB held in RAM, deterministic. wget and aria2c were not on this machine and were not installed for this. Transcript not yet public.

The run above measured against an honest origin, where every final file is correct because a server that answers Range correctly cannot produce anything else. This asks what lands on disk when the server answers a resume badly. Each tool was killed at about 135 MB as counted by the origin, then restarted; the result was hashed against the artifact's digest. Two batches, sixteen rows, identical verdicts in both.

The two corrupt rows: a 512 MB file of the right length, the wrong content, and an exit code of zero; nothing downstream can tell. curl has no option that would have caught it — there is no digest to give it — so for curl this is the ceiling of what the tool can do. dl has the option and does not apply it unless asked: dl without --digest corrupts exactly as curl does, and the behaviour that justifies this layer is opt-in today.

On misplaced the origin logged two requests from dl: a ranged one, then a plain one. dl read Content-Range, saw bytes 0-, threw the response away and re-fetched the whole artifact. It cost 149 MB and it was correct; curl -C - refuses the same case, which is also safe and needs a person to notice and retry. That is rule DL-R7 of the download contract firing over real HTTP; every rule on a contract page carries a tag like that, and every scenario cites the tag it tests.

Two downloaders, one vocabulary, no shared engine

2026-09-08. The same class of machine on mains; run in WSL2 Ubuntu, kernel 6.18, everything on tmpfs, other work running, rounds interleaved so any drift lands under every tool. g++ 15.2.0 at -O2, Go 1.26.0, curl 8.18.0. The origin counts every response where it leaves. Transcript not yet public; the second tool, dlc, is an implementation of the download vocabulary over curl — one C++ header, no dependency — and is not yet published either.

Every other agreement on this site is between implementations written from one design. dl drives our own fetcher; dlc drives curl. They take the same flags, answer in the same five words — delivered, working, unavailable, forbidden, unknown — and share not one line of transfer code. They are the first pair here that could genuinely disagree.

The wire: 54 cases, both tools, one fixture. Fifty end with the same verdict and the same bytes on disk. The eighteen HTTP statuses in the contract's list — ten permanent, eight not now — were classified independently, from a status table in Go and from curl's exit codes, and agree on every entry. Our own Go and Python had disagreed on four of them for as long as both existed. Both tools refuse an unasked Content-Encoding, both stop on a truncated body and keep the prefix, both drop bytes past Content-Length, both follow a redirect, and on twenty-two resume rows — eleven origin behaviours, each with a prefix from the right and from a different version of the artifact — both deliver correct bytes on all forty-four.

The four that differ are one thing: a partial on disk that nothing can vouch for and no digest to check it against. dl re-fetches from zero and delivers, which is what rules DL-R1 and DL-R3 say; dlc refuses, permanently, and keeps the partial. The contract does not say which is right.

Resumption — 2 GiB, SIGKILL near 700 MiB, bytes counted at the origin

dl's 5,242,880 is exactly one checkpoint interval: it resumes from what it proved, and the proof lags the disk by up to 5 MiB. dlc resumes from the file's length, which is exact and unproven, and buys the proof back by hashing the whole artifact at the end — a second full pass over the 2 GiB that dl, hashing as it writes, never makes. Same decision, two sides. The last row is an answer neither curl nor dl gives: asked to resume something it cannot prove, dlc fetched nothing, delivered nothing, exited non-zero and left the partial where it was.

Two things the pair found that neither tool could have alone. <tool> <url> --digest <d>: does it name a location or an artifact? Fetch once, then ask for the same digest from a URL that now returns 404. dl exits 0 with the correct file and makes zero requests, because its store has already proven those bytes (DL-R28); dlc exits 1. Both are defensible and the contract page never says which meaning is the layer's. And the two endings — try later against never — are invisible from a shell: both tools exit 1, one keeping the distinction in a record, the other in an English word on stderr. The contract specifies the distinction and no way to observe it from outside the process. The same run found that dl accepted an unknown flag and its value silently and ignored the last argument on its command line — dl <url> --verify sha256:… downloaded, verified nothing, exited 0. Both are refused at go/v0.3.0, measured 2026-09-09 on Windows: --verify and a bare --digest each print the refusal, exit 2, and fetch nothing.

One application, three providers, nine situations

2026-09-08. Windows, native. One binary, fetch, written once against the download.Client interface and never naming a provider; a 6 MB payload from a loopback origin. Transcript not yet public.

Three implementations of the same five methods: curl is our vocabulary over the engine the machine already had; here is the native Go implementation in the calling process; service is the same code with the supervisor jobd watching the store, so the work outlives the caller. The answer is one of delivered, working, unavailable, forbidden, unknown.

* the application read this answer out of an error string, because the class the layer computed does not survive the Client boundary. A defect, described beside the demo's source.

The last row is the point of the middle column: here and service are one layer over one store, differing in a single argument, and a job submitted through either appears to both. The first row is the other point: a provider that cannot give what was asked says unavailable rather than quietly doing the work somewhere else.

The downloader and the supervisor, over one identified connection

2026-09-09. A desktop-class Windows 11 machine on mains, other work building and testing on the same disk. Every number is a latency on a rate-limited local origin or a local pipe, never the network. Transcript not yet public; the code is in the tree and in no published tag.

download and jobd talk over the identity layer's own listener — the one asks and rights already use — and the supervisor answers nothing until the kernel has named the caller and the name meets the listener's stated need. The store stays the truth: the connection carries a request to sweep now, or a question, and no job. The supervisor's heartbeat names the connection; the heartbeat predicts and the connection decides, so a supervisor killed between two beats attracts no work.

Eight rules, each with a Go and a Python scenario, each shown red when its rule is deliberately broken and green again with the break reverted. What stayed file-based, on purpose: a supervisor announced on another host — a NAS supervising its export — and one whose kernel cannot name a caller are reached through the store alone, as before. Linux and macOS did not run: UNPROVEN. C++ has a runner and no client, so nothing there makes this call.

A download that outlives the process that asked

2026-09-09. The same machine and state as above; a 4 MiB file from a local origin held to 256 KiB/s; jobd running under the same account as the requester. Transcript not yet public.

The requester is the ComfyUI node's two calls — submit a download to an absolute destination, then wait for delivery — made by a process that is then killed by PID mid-transfer, its child verified gone by PID. Sampled every few seconds: who holds the lease and how many bytes are proven.

What was wrong is stated because it was the headline claim: the Python facade, which is the one ComfyUI runs, handed no supervisor an absolute destination, so the transfer was worked in the requesting process however local the supervisor was. The rule now: a supervisor on this machine under this account is handed it; one under another account, one that does not say its account, or one on another machine is not, and the NAS still refuses a destination only the submitter's machine has. Five rules, pinned in Go and in Python, each shown red when broken. Windows only; UNPROVEN elsewhere.

A rejected signature is not a verified one

2026-09-09. An Apple silicon laptop, macOS 15.7.4, on mains and in interactive use throughout; and a laptop-class Windows 11 machine on mains, other work running. No timing was taken on either. Transcripts not yet public; in the tree, not yet in the identity tag.

Each thing identity says about a peer — user, path, package, code signature — carries a rung saying how it was established. The ladder was six rungs, and a signature the platform rejected sat on the rung the peer had earned: on macOS an ad-hoc binary that failed anchor apple passed a policy asking for pid; on Windows an unsigned binary passed one asking for bound. A boolean said untrusted beside it, and nothing read the boolean.

none < claimed < invalid < unsigned < unmet < pid < bound < kernel < signed

Three verdict rungs sit below pid: a policy that asks for any rung implying verification refuses them by comparison alone, and a service that knowingly admits unverified code asks for the lower rung by name. The same peers, after: refused at pid and bound, admitted only at or below their own rung. A copy of node.exe with one byte changed lands at invalid; node.exe as shipped verifies at bound; /usr/bin/nc against anchor apple verifies at pid while the ad-hoc binary against the same requirement lands at unmet.

Found on the way: under WTD_SAFER_FLAG, Windows reports a modified signed file as no signature in both the return value and GetLastError, so every tampered binary had been worded as unsigned since the verifier was written; without the flag the same file is TRUST_E_BAD_DIGEST. The flag is gone. Verified for one Windows build and one tampered file; the revocation path was not exercised. On Apple silicon no unsigned or tampered arm64 process can run to connect, so those two rungs are mapped by reading the SDK's error codes and are UNPROVEN as running peers there; on Linux the code rung is permanently none.

The identity contract, tagged and tried

2026-09-09. A desktop-class Windows 11 machine on mains; every number is a count. No implementation was changed. The tags are in the tree's contract page and not yet in the published one.

Every rule on identity's contract page now carries a tag, the way job's and download's do, and six scenarios cite them: the ladder in order, an attribute refused rather than built at claimed, a policy that names every shortfall and not the first, a listening end and a client end that each answer, a claim in the payload that never reaches the identity, and a signature the platform rejected that meets no policy asking for verification. Of 45 tagged rules the scenarios reach 17; the other 28 the runner names on every run, and where each sits is a fact about the rule: reachable by a conformance driver — the small program that applies a scenario to an implementation and prints what an observer saw — alone, needing a hostile peer that hands off, pre-forks or recycles a pid, or measurable only on a platform this machine is not — an installed MSIX package, a Developer ID in an unlocked keychain, two kernels either side of Linux 6.5, an enforcing LSM, a second machine.

Each cited rule was broken deliberately and the run went red on that rule and nothing else — against a script replaying the contract's own answers, which proves the scenarios can fail and proves nothing about an implementation. There is no identity conformance driver in any language, so abstraction-identity is UNPROVEN against its own scenarios on every platform. The scenario written red that morning — a rejected signature meeting a policy that asks for verification — was green by evening, once the ladder above landed. Found on the way: the runner compared an expectation's tokens as a set, so a rule about an order asserted nothing until the order was spelled as one token.

Speed — withdrawn, no claim

The throughput tables that stood here came from one machine and no other platform: WSL2 for the wide-area run, native Windows for the loopback one. Two of our own loopback benchmarks on that machine disagree with each other by 2.7×, both are ours, and neither has been reconciled — so those numbers describe the benchmarks and not the tools. They are withdrawn. A per-platform comparison across Windows, Linux and macOS is in progress; until it lands this site makes no throughput claim, and nothing else on these pages rests on one.

Two facts from those same runs are kept, because neither is a throughput number. Twenty-five wide-area transfers of a 386 MB file from huggingface.co all verified byte-identical against the digest Hugging Face publishes for it. And dl has a repeatable slowdown triggered by a 256 KiB write size at the origin — a defect, mechanism not diagnosed, held open until the per-platform run lands.

Read, not run: five languages

2026-09-08. No toolchain for Rust, C#, Java, TypeScript or Swift was on the machine and none was installed. Every specimen is hand-written and judged by reading against each language's published rules and standard library. Nothing was compiled, nothing was run, no bytes were produced or compared. The five specimens are not yet public.

The belief tested: the vocabulary is language-neutral, so a native implementation in a new language is a naming exercise over the same shapes. The record from job.thrift and the three answers were written out as a native speaker of each language would expect to be handed them. The record's shapes travel. Two of its mechanisms do not, and both were invisible while the implementations were Go, Python and C++ — three languages that happen to agree about the two things the other five disagree about.

Sorting the map keys

extensions is a map and its wire order is UTF-8 byte order. Go, Python, C++ and Rust compare strings by their bytes, and UTF-8 is order-preserving, so nobody had to think about it.

The UTF-16 rows are a wrong order: above U+FFFF, code-unit order and byte order disagree. C#'s default is the current culture, so the same program writes different bytes under tr-TR than under en-US. Swift's String equality is canonical equivalence: "e\u{301}" and "é" are ==, so a Dictionary<String, _> silently merges two extension keys the contract says are two keys — not a wrong order but another participant's data lost. None of this is a fault in the languages; it is a fault in a contract page that is proven over bytes and did not say so.

The opaque fields

spec and checkpoint are carried verbatim, and the compare-and-set on update is a byte comparison over them. The three shipped implementations type them as a string, correct in exactly those three.

The three answers, and whether a compiler can insist on them

The guarantee the contract most cares about — that unavailable, forbidden and unknown never collapse — is enforceable by the compiler in two languages we have not built and in none of the three we ship.

Not yet public

Linked nowhere above, because the files are not yet in a public repository: the four-tool interruption run, the server that lies, the two downloaders with the dlc implementation they measure, the nine-situation provider transcript, the five specimens, and the four 2026-09-09 runs — the identified connection, the download that outlives its requester, the ladder before and after, the identity scenarios. When they are, the links go here.