Datum: parts, checks, code
A founder's side project: Datum, a tool that ties code to a tree of parts and checks, and only counts a check as proof once it has watched it fail.
Datum is a side project of our founder, Enaho Murphy. It isn’t a Henaho Labs product. We write about it here because the ideas behind it shape how the studio works.
When code gets written fast, with AI tools in the loop, the slow part becomes knowing that the code is right. Tests help, but a test only says something if it can fail. And a test that passed last month says little about code that changed this morning.
Datum is an attempt to make that knowledge explicit. It is in active development. This post covers the principles, not the implementation.
Parts
Datum starts with a tree of parts. A part is a piece of what you are building, described in plain words: “a buyer can cancel before the seller confirms”, or “a recording folder is complete or clearly unfinished”.
Big parts split into smaller ones. Each leaf has one obligation, and that obligation must be testable. If you can’t say how you would check it, it isn’t small enough yet.
The tree is the shared picture. Engineers read it to understand the product. Our tools read it too, so they work from the same picture.
Checks
Each part has checks: the tests and other probes that show the obligation holds.
Here is the first rule. A check doesn’t count as proof until Datum has seen it fail. Datum breaks the code on purpose, in a way the check should catch, and watches. If the check still passes, it wasn’t proving anything, and Datum says so.
This is the same idea as writing a test first and watching it go red. Datum just makes it routine, and keeps doing it after the first day.
Code
Code links back to the parts it serves. Datum knows which checks cover which code, and which part each check proves.
That link gives the second rule. Proof expires when the code under it changes. If someone edits code that a check covers, the proof for that part is stale until the check runs again and still does its job. Stale proof blocks a merge.
This catches a quiet failure that is common with fast teams: a change that passes every test because none of the tests looked at what changed.
Who approves
AI tools can speed up a lot of the work around Datum: proposing parts, drafting checks, drafting code. Engineers decide which parts exist and review what lands.
But a model can’t approve its own work, and can’t grade it. The thing that decides whether proof holds has no model inside it. It is a plain program that runs the checks, breaks the code, and records what happened. People approve changes to the tree.
We think that split is important. If the same model writes the code, writes the test and judges the result, nothing has been checked. It has only been agreed with.
Local first
Datum is meant to run where the code is: on your machine, from the command line or a desktop app, and in CI. It doesn’t need a service to tell you whether your own code is proven.
What it borrows from the studio, and what it gives back
Our engineering discipline already has pieces of this. Tickets list the exact tests that prove them. Tests are written first and must fail before they count. Frozen tests can’t be quietly rewritten. Every guard has a test that makes it fail.
Datum asks what happens if you take those habits all the way:
- What if every requirement had a home in one tree?
- What if “this test can fail” were checked by a machine, not trusted?
- What if proof had a shelf life?
We don’t have final answers. That is why it is a side project and not a product.
What we won’t say yet
Datum is in active development. We aren’t sharing code, numbers or dates. We will write again when there is something you can try.
If the ideas here are useful to you, you don’t need Datum to use them. Write down what each part must do. Make every check fail once before you trust it. Treat old proof as old. And don’t let the thing that wrote the code be the thing that grades it.