Three cases

Three situations where an application gains something it cannot get from the platform on its own. Each one says what the machine does today, what changes, which transcript shows it, and what about it is still unproven. A reader who does not recognise their own situation in one of these should not adopt anything here — the last section says what is missing from all three.

1 · A transfer nobody is watching

The situation. Two programs on one machine want the same multi-gigabyte file. One of them is a plugin inside an application the person closes. A machine on the LAN has the disk and the uptime. The application is Python, the service is Go, and something in the pipeline is C++.

What the machine does today. Each program carries its own downloader, inside itself. Close the application and the transfer dies with it. Two programs asking for the same file fetch it twice, because neither can see the other's partial. Start again and the resume point is the length of the file on disk — bytes that arrived, which is not the same as bytes anything vouched for.

What changes. The record is on disk and the work is not in the process. Whoever holds the lease does the work; when the lease lapses, whatever is running sweeps for stranded records and takes this one over. The checkpoint is the bytes proven — hashed — so a successor never inherits a claim the predecessor could not make. Get(url, path) and Wait is the whole of what the calling application says.

What was measured. A file asked for on a PC was finished and verified by a NAS after every process of ours on the PC was killed (NAS1). Go and Python finish each other's downloads in both directions (XLANG-DOWNLOAD). A transfer killed with SIGKILL resumed from the proven prefix in a separate process, discarding what nothing vouched for (RESUME1). Against a server that answers a resume from the wrong offset with a Content-Range that lies to match, curl -C - writes a complete corrupt file and exits 0 — so does ours without a digest, and that is on the page too. The transfer surviving the ComfyUI node that asked for it is measured, Windows.

What is not proven. The coverage grid carries a red cell for this layer in all three languages, generated from the transcripts rather than asserted, and the reason is on that page. No throughput claim is made anywhere on this site: two of our own benchmarks on one machine disagreed and the tables were withdrawn. Against three other downloaders, ours is the only one that resumes without being told to and it is not the one that resumes best. macOS is UNPROVEN.

2 · A service that is told which binary called

The situation. You run a privileged helper that grants narrow permissions to named applications — this one may hold the machine awake, that one may read the system log. The grant is worth exactly what your ability to recognise the caller is worth.

What the machine does today. The common shape is a named pipe or a unix socket that takes an owner string in the message and verifies nothing, so any process on the machine is any application it cares to name and the permission model is a list nobody checks. The syscalls to do better exist and differ on all three platforms, and none of them tells you what its answer is worth: a service that needs a verified signature discovers per connection, or never, that this operating system cannot give it one. The worked case is on the layer's own page.

What changes. The peer is bound once, at accept, and refused afterwards rather than re-derived. Five attributes — user, process, path, package, code — and each arrives welded to a rung saying how hard it would be to make it lie. There is no API that returns a value without its proof, and none that accepts a value the peer asserted.

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

Three of those nine are the platform's own verdicts on a signature, and they sit below pid: a policy asking for any rung that implies verification refuses a rejected signature by comparison alone, and a service that knowingly admits unverified code has to ask for the low rung by name. Ceiling() reports the best each attribute can reach on the running platform and answers with no connection in hand, so a service whose model rests on a proof this operating system cannot produce fails at startup instead of once per connection.

The three platforms do not agree, and the contract says so rather than averaging them: Windows can tell you which program opened the connection and cannot verify the code it is running; Linux can tell you who the peer is and has no general answer to what it is; macOS can verify the running code and, over a plain socket, cannot firmly bind that code to the connection — every rule of it tagged, per platform, with what was executed on which.

What was measured. An unsigned binary and a tampered copy of a signed one used to satisfy policies asking for verification, on two platforms; the same peers after the ladder changed are admitted only at or below their own rung. Our own supervisor answers nothing until the kernel has named the caller, and a client that opens the pipe anonymously is refused with the reason before its request is read (measured, Windows). Every rule on the contract page now carries a tag and scenarios cite them.

What is not proven. There is no identity conformance driver in any language — no program that applies a scenario to an implementation and prints what an observer saw — so this layer is UNPROVEN against its own scenarios on every platform — the scenarios have been shown to go red on a rule deliberately broken, which proves the scenarios and proves nothing about an implementation. The scenarios reach a minority of the tagged rules and the runner names every unreached rule on each run, with where each one sits; the counts are on Evidence. There is no tagged release. On Linux the code rung is permanently none. Nothing here defends one process from another running as the same user at the same integrity level; that boundary is the platform's, and this layer reports it rather than building one.

3 · A hold somebody can take away

The situation. A long job — a render, a training run, a large fetch — needs the machine to stay awake while it runs, and the person who owns the machine wants to know what is holding it and be able to stop it.

What the machine does today. Every application asks the operating system directly, and the request belongs to the asking process. Nothing on the machine can say which application is holding it on whose authority, and nothing can take a hold away without killing the program. On Windows the one built-in list of what is holding the machine awake needs an elevated prompt.

What changes. The application asks for a right; the request is a question a person answers; the service — not the application — makes the operating-system request and keeps it. So the hold belongs to the service, and revoking the right releases the machine the same second, with the application told its hold is gone. The service never says yes on its own: a grant is a person's act.

The shape is OAuth's and is named that way: registration is the device authorization grant (RFC 8628), a token is a bearer credential (RFC 6750) scoped to one right and one hour, and a resource holder in another process checks one by introspection (RFC 7662). Authority is designation, not identity: the grant's subject is the application designated by its secret, and the identity that registered it is evidence shown to the person once, never consulted for a decision again — so a grant outlives the build that earned it. Every operation binds its caller through case 2 before the request is parsed, and the service refuses to start on a machine that cannot bind at all.

What was measured. The hold follows the lease exactly and is released when the holder is killed, read back from the kernel's own execution-state bit (AWAKE1, Windows; Linux reads systemd-inhibit; macOS UNPROVEN). That transcript measures the hold in the job layer, which is where a lease lives.

What is not proven. No published transcript names this layer. One right, awake, runs end to end on Windows over a named pipe — rightsd, rights, keepawake — held to its own tests and nothing else. There is one implementation and therefore no scenario corpus, which by this project's own bar means it is not conformance (the layer's page says the same). Go only. The unix-socket listener, systemd-inhibit and caffeinate paths are written and have never run: UNPROVEN on Linux and macOS. It holds among programs sharing one kernel and one user account and defends nothing across accounts. It enforces nothing inside a library: awake is enforceable because the operating-system request is held by the service, and a right over a resource the application holds in its own process is a promise the application keeps or does not.

What is missing from all three

The list a reader would otherwise have to assemble from the rest of this site, in one place, because a weakness found rather than stated makes everything beside it worth less.

• Both integrations are ours. The ComfyUI-Manager integration and the Synology package were written here, by the same hand as the layers. No adopter outside this project has taken any of it, and that is the one item on this page that cannot be closed by us writing more code.
• Every module is 0.y.z — under Semantic Versioning §4 the public API may change between releases. Two of the three layers on this page carry no tag at all.
• macOS is UNPROVEN for the download and rights cases, and for identity it is proven in a shape that is weaker than the other two platforms and says so.
• Most cells in the coverage grid carry no verdict attributed to this tree, including green ones the project's own gate exercises on every run — because the gate records no per-cell result, and a run nobody can point at is not evidence.
• Nothing is signed. sum.golang.org proves the bytes are the ones everyone else fetched and says nothing about who wrote them.
• One maintainer. Two organisation owners, and a succession plan that needs nobody's permission (GOVERNANCE.md).

What none of that is: a reason to take our word for any of it. The conformance suite runs against your implementation, not ours — a POSIX shell, no Go, nothing of ours built. If it fails a rule you believe you keep, that is the most useful thing anybody outside this project can send us.