kton — how a question became a protocol tells you where all this came from. This piece is for anyone who wants to know what it does — written for people who work with data and results, not for people who work with distributed systems.

One paragraph to get the names out of the way. The kton protocol keeps a record of how a result came about and who stands behind it — small signed entries that anyone can check. It has two layers. plankton carries what can be recomputed: which files went into a run and which came out. nekton carries what cannot be recomputed, only attested — this was reviewed, this was approved, this is the version that counted. Together they are the kton protocol.

The situation

You see a scientific graphic on the internet. A curve, a bar chart, a scatter with a line through it. You did not make it, and you have to decide what to make of it.

What can you check? Almost nothing. You can hope the text beside it explains how it came about. You can look at who published it. You can see whether other people say the same thing. All of that is about people. None of it is about the graphic.

Because the graphic itself says nothing about where it came from. It is a picture. Everything that gave it meaning — which data, in which version, what was run on it, who checked it and with what result — sits somewhere else and was not sent along.

So one thing is left: belief.

That gap is what the kton protocol is built for.

One transformation at a time

The unit is deliberately small. A foton is a single transformation: some files went in, something ran, some files came out. The name stands for File Only Transfer Over Network — only the data counts.

inputs → command → outputs

The command is whatever did the work — a script, a program, a report. kton does not run it and does not look inside it. What gets kept is what went in, what came out, and which command connected the two. Running things is someone else's job, and leaving that job outside is what keeps a record small enough to travel.

None of that is clever by itself. What carries it is the way the files are named.

Naming a file by what is in it

A file is identified by its content hash: run the bytes through a standard function and you get a short string that changes completely if a single byte changes. The file name, the folder, the system it sits in — none of that counts. The bytes are the identifier. That is what content-addressed means.

This one move is what lets a record cross an organisational boundary. Two groups who have never spoken, who use different tools and different naming conventions, who share no database and want none, can still tell that they are holding the same dataset — because the same bytes produce the same hash everywhere, with nothing agreed in advance.

It also means anyone can check a claim about a file. If a record says "this figure came out of that run", you can hash the figure yourself and see whether it holds. You are not taking anyone's word for the link.

Lineage comes for free with a free protocol

Lineage is the chain that runs up to a result: this figure came out of that run, which used that model and that version of the data, which was assembled from those source files, which came from that study. Where it exists at all, it is usually kept separately, in a system of its own, filled in afterwards.

Here nobody keeps it. If every transformation records which files went in and which came out, and files are identified by their content, the records already are the graph. Lineage is not laid on top — it is what a pile of such records is, read in either direction. Backwards from a result to the raw data. Forwards from one version of a dataset to everything that was ever built on it, which is the question you need the day a dataset turns out to have been wrong.

And there is nothing to buy for it: the protocol is open, and the reference tools are a single binary with no dependencies.

The half that cannot be recomputed

Everything so far can be checked by machine. Run the transformation again, or hash the bytes again, and the answer depends on nobody's good faith. That is the plankton layer.

But much of what matters about a result is not that kind of statement. This was reviewed. This was approved. This supersedes that. This is the version that counted. No amount of repetition produces those — they are asserted, not computed. The most you can have is a note of who asserted them and a signature to back it.

That is the nekton layer, and keeping the two apart is the entire design. One can be recomputed. The other can only be attested — by whoever holds the key. A person, a department, an agent you handed a key to: the layer does not ask who or what is signing, only whether the signature holds and which key it belongs to.

Mix the two and you get a system that looks rigorous and is not, because you can no longer tell which of its statements are proofs and which are promises. Kept apart, you can read a record and see exactly where the mechanical guarantee stops and someone's judgement begins.

Statements like that do not float free. Each one hangs on exactly one transformation, in exactly the state it was in at the time. On the basis of this run I had the idea. Three steps later I arrived at that one. What I checked is this one, not the one before it. And because the transformation is identified by its content, the statement cannot quietly move to something else: change the run and its hash changes, and the old approval visibly no longer applies to the new thing.

Which makes the sequence readable. Not just what came out at the end, but at which point something was asserted, checked or decided — and by whom.

The longer version of that argument — why only logic and mathematics are provable from themselves, and what follows from it — is in kton: how a question became a protocol.

Federated, and what that means

There is no central database. No company holding the records, no service to sign up for, nothing whose access has to be negotiated. Whoever has records has their own kton registry: a person on a laptop, a lab, a university, a company. Nothing separates them but size.

A kton registry is a directory of files, each named after its own hash. What is in yours is your choice — what you made yourself, and whatever others published that you thought worth keeping. There is no server software to install and nothing to negotiate. To give someone your records, you give them the directory — on a web server, in a repository, however it suits.

Anyone holding two such directories sees them as one: wherever both know something about the same bytes, the two fit together, without ever having heard of each other. Taking a copy of someone's registry is not endorsing it — the claims in it keep the signatures they arrived with, and those signatures stay theirs.

Which makes a chain that stops somewhere the normal case rather than a failure. An example from drug development. Whoever works with the data has the anonymised, aggregated data — plus the hashes of the steps before it and the algorithm the anonymisation used. What is missing is the patient data itself. Only those allowed to see it, see it.

An authority auditing the work has both. It can run the anonymisation against the real data again and see whether the same thing comes out. And if it does, it can leave exactly that as a record: checked, reproduced, signed. That record is then visible to everyone — including those who never saw the patient data and never will.

One consequence is worth stating plainly. Because every record is checked against its own hash as it is read, a kton registry cannot forge the records it holds. It can refuse to hand something over. It cannot hand over something false without that showing. Withholding is possible. Lying is not.

So control stays where the data is. You decide what you pass on, to whom, and when. And when reading, you decide which registries you believe — not whoever published. Nothing is forbidden along the way. The protocol does not stop you from disclosing everything, and it does not stop anyone from distrusting your records. It only makes sure that in either case you can see where you stand.

What none of this proves

Worth being exact about, because tools like this are routinely oversold.

That the same run produces the same thing again does not mean it is right. A badly chosen model computes just as reliably as a good one. On the wrong dataset, the same wrong answer comes out every time. That something repeats says something about the arithmetic. About the science it says nothing.

That a record is signed does not mean the statement is true. It means the signature is genuine and you know whose it is. That is worth a great deal — it is the difference between a statement someone stands behind and an anonymous one — but it says nothing about whether the work was good.

And only what someone wrote down is in there. A decision that was never recorded is not recoverable by the best protocol in the world.

One more thing that the clean split tends to hide: a plankton record is a claim too, to begin with. It says these inputs and this command produced these outputs. You can only check that if you can get at the bytes and run it again. If you cannot, it stays a claim — a well-formed one, but a claim.

The example above is exactly that case. Whoever may not see the patient data cannot recompute the anonymisation; for everyone but the authority, that one step is not checked but attested. The split holds — a plankton record is recomputable in principle, a nekton record is not. But whether you can recompute depends on what you can reach. What you can check yourself, you need take from nobody. For everything else you depend on someone having done it and standing behind it.

What you get is narrower and more useful than "trustworthy results": you stop guessing. The chain is either there and checkable, or it is visibly not there. Both are answers. Neither asks you to take my word for it.

Have a look

It is clearest when you use it. Here is an invented paper from drug development in which every figure carries its own chain:

a paper with the kton Lens →

Your browser hashes each figure as the page loads and looks the result up in a kton registry of signed records. If it finds nothing, nothing happens — the figure stays a figure. If it finds something, you can go in.

Then you see how the result was drawn, which analysis it came out of, and which model was behind that. From there you keep going back, down to the data everything rests on. And if that data had already been worked on, you can go further still — as soon as you know the registry it came from.

If you published it yourself, you also see your plot where it belongs: among all the attempts you did not publish.

You can point the page at several registries at once, and they fill each other in. Which sources a figure is checked against is your decision, not that of whoever published it. The page and the registries were never set up for one another. They meet at the bytes.

Where it stands

There are two things. The specification — the contract for how records like these are exchanged, so that programs built independently of one another understand each other. It is at 0.2, and it is a draft.

And the programs that implement it: two small kernels, one per layer, and a cockpit above them that makes the two work together and reimplements none of it. Written in Go, no foreign libraries, for every operating system, free.

That split is the reason for something you saw earlier. The kernels are small enough to run in a browser — which is why a page can hash a figure itself and look it up itself, without asking anyone. Everything that has to touch the network sits in the cockpit, not in the kernel. And you can drop the cockpit: every single operation still works afterwards, just directly against the two kernels.

The code is Apache 2.0; the specification is under the Community Specification License 1.0 — the licence that puts others in a position to build the same thing independently. That is the whole point: something only one program can read is no use as common ground. kton is heading for a foundation of its own for the same reason.

The names

Both words come from marine biology, and they were not picked at random.

Plankton drifts. It does not move under its own power; it is carried — tiny, everywhere, the base of the food chain. That is how a computation behaves: it happens, it wants nothing, and it comes out the same every time.

Nekton swims. Fish, squid, whales — everything that moves under its own power and decides where to go. That is how a statement behaves: someone puts their name to it because they choose to.

And kton is the syllable they share.

The protocol, the specification, and the reference implementation:

kton.dev →