Business systems written as byte-addressed graphs of commands an AI can read and a kernel can refuse. Every act is recorded, and every run replays byte for byte on any machine.
The ledger alone rebuilds the exact state the run produced. Not similar — the same hash, on a different machine, in a different host, including WebAssembly.
Three actions, and one question people ask constantly. Adding and removing run through a graph, so each is committed, recorded and replayable; finding only reads.
Nothing is deleted, here or anywhere: removing archives, and the record keeps its
history. Run nestera on its own and it suggests what to do next, from
wherever you are.
Two questions get harder as more work is handed to software that writes and runs itself: can I read what this will do before I trust it? and can I prove what it did afterwards?
Most systems answer the first with documentation that drifts, and the second with logs the same system wrote about itself. Here the instruction is the program — every node carries its sentence, and the binary disassembles back to it — and the record is a hash-chained ledger that rebuilds the exact state it describes. A refusal is mechanical rather than a matter of configuration, so "could it have done that?" has a factual answer.
Most systems make a model guess: it writes code against documentation that has drifted, runs it somewhere it cannot inspect, and finds out what happened from logs the same system wrote about itself. Every part of this one is built to be read before it runs and checked after.
Model output enters through three syscalls and is validated before use. Routing is clamped to the node’s own edges, filled fields are type-checked against the form, and a drafted form is validated against the schema. None of them sets the program counter and none writes memory — the model proposes, the kernel disposes.
A model given a large system has one expensive problem before it does anything useful: what can I even do here? Documentation drifts, a schema dump is enormous, and the answer is usually to paste in as much as fits and hope the right part survived.
This is measured rather than imagined. A real project-management system exposes 400 operations. Asking for all of them returns 84,184 characters — roughly 21,000 tokens — which overflows the reply entirely. The call does not come back shortened. It comes back empty.
Two reads instead of one impossible one. The top file names the areas; one area file carries its operations with their real argument lists. A reader descends rather than loading everything, which is the same move as a kiosk at every level of a map.
An entry is the operation’s own name and its own arguments. An index that summarises can be wrong about what it describes, and the whole value is that a reader can trust it enough to stop reading.
Every index carries the date and a SHA-256 of the surface it was built from. Re-run the generator, compare the digest: if it moved, the index is behind. In CI that makes staleness a build failure rather than something somebody eventually notices.
Which operation suits a task is the reader’s judgement. The index makes the candidates findable and stops there.
An index nobody regenerates is worse than none, because it gets believed. That is the only way this fails, which is why the digest check is part of it rather than an afterthought.
Four levels, and most documents want one of the first two. The useful question is not “is it encrypted” but what do you need to be able to prove, and to whom?
| Level | What it gives you | State |
|---|---|---|
| content hash at upload | “these are the bytes we sent” — a file altered since stops matching | built |
| signed certificate | provable to a third party, checkable with openssl and nothing of ours | built |
| placement record | who put it there, when, and which bytes — replayable to any past date | built |
| client-side encryption | the holder of the storage cannot read it | specified |
A file crosses as packets named by the hash of their own bytes, so reassembly is verified rather than hoped for, resume is free, and identical packets are stored once. A bucket cannot be poisoned: writing requires bytes that hash to the name you are writing to, so there is no “upload to this path” to abuse.
The certificate is checkable by a stranger with standard tools. That is deliberate: a proof only we can verify is a proof nobody has to accept.
A hash chain proves nobody edited the middle of a history. It proves nothing about a history replaced wholesale — roll back to the start, write something else, and the result verifies perfectly and holds no trace of what it used to say. Anyone with write access would replace rather than edit, so that is the case that matters.
So a record pushes its head somewhere else: a name, a sequence number and 32 bytes. No content crosses. The witness reads the chain itself rather than trusting the claim, requires the owner’s signature, and refuses the same sequence arriving with a different head.
The test that pins this rewrites a record into a chain that verifies perfectly on its own — and only the witnessed head can tell. Which is the whole argument for pushing one, and why a chain nobody else has seen proves less than it appears to.
no_std, no allocation, forbid(unsafe_code)Default deny. Movement happens only along an edge; writes only inside a transaction that passes version, checksum, lease and role checks. No privileged mode skips them.
Model output enters through three syscalls and is validated before use. It never sets the program counter and never writes memory.
Every binary disassembles to its source. A failure names the node, its command, and the rule that refused it.
Nestera keeps its own records, so for most jobs there is no database to configure: a pile is the store, and it is leased, versioned and checksummed by the kernel. Reaching something you already run — a database, an accounting system, a mail or payments provider — goes through a connector.
The graph calls a connector by id; the host holds the credentials, from the environment or a secret store. Keys never appear in a graph — a construct is meant to be read, shared and disassembled, so anything secret in one is a key published with it.
| Reaching | How | State |
|---|---|---|
| your own records | piles — native storage, no setup | built |
| an AI model | the adapter: routing, filling, drafting — all validated | built |
| mail, SMS, payments | connectors, role-gated, approval-gated, budgeted | built |
| an existing database | a connector that syncs records in and out — MySQL and Postgres | built |
The permission machinery is built and tested — roles, approvals, budgets, and a refusal that
names itself — and so is the transport that makes the call. What is written down afterwards is
a fingerprint of what was sent, never the payload and never the credential. Run with
--dry-run to see the exact request a graph would make without anything leaving
the machine.
Five working systems now ship with it — a contract, a chat room with groups and photos, invoicing, a bridge between two houses, and a dropbox. The useful thing to say about them is that almost none of them needed new machinery.
Buckets, which already existed for photos, plus a signed list. The list names content rather than a location, so a source is a hint: a desktop that is only on sometimes, a mirror, a stranger.
A pile with roles. No permission system was added, because the one that stops an agent writing outside its lease already answers who can see a room.
The signature block, plus base64. A text file on any web server, checked on arrival, because the bytes are named by their own hash.
That is the architecture paying off rather than anyone working quickly. When a new use case turns out to be mostly composition, the primitives underneath were the right ones. Content addressing in particular keeps earning: it is why an untrusted mirror is safe, why re-sharing costs nothing, and why a cache never goes stale.
The honest counterpoint: these are thin. The dropbox has no web interface, no invitations and no revocation. They demonstrate the shape convincingly and not one of them is a finished product. Each is a few hundred lines you are meant to read, change and take — the packs say what each is built from.
Written up in DEVELOPMENT-PLAN.md, SPEC-R-proposal.md,
SPEC-N-proposal.md and MAPMAKER.md — including the parts that
were tried and rejected, and why. One address space has since been built
rather than planned: placement is a recorded act, so the map is the replay of it and
“what was where in March” is exact rather than reconstructed.
Every system at an address, navigable by scale: the whole estate, down to one node.
Visibility, accessibility, operations and permissions for the graphs you run.
A working demonstration: two clients side by side, typing to each other and sending files. Every file crosses as packets named by the hash of their own bytes, and both panes show the fingerprint, so you can see the check rather than take it on trust.
A button, an app, a voice input, a game character: the door speaks
HTTP, so anything that can make a request can drive a graph today —
no SDK. INTERFACES.md is the contract.
Working systems you can run, read and change: a contract, a chat room, invoicing, a bridge between houses.
400 operations, 84 KB of surface, a call that fails outright — reduced to two reads and about 2,200 tokens. Generated, digest-stamped, and it cannot go quietly stale.
Content hashes, certificates a stranger can check with openssl, a placement
record you can replay to any date — and a witness that catches a history rewritten
wholesale, which a hash chain alone cannot.
Spec, kernel, builder, hosts and CLI. Private during pre-release — ask for access.
The system is 0BSD: the runtime, the specification, the conformance suite and every sample are free, with no conditions and no attribution required. What is sold is time and assurance — building the thing, standing behind it, and saying it conforms.
| Tool | What it is | State |
|---|---|---|
| CLI + spec | the whole runtime and toolchain, 0BSD | free |
| conformance | the golden suite, to check your own port | free |
| pilot | we build your process as an auditable system, fixed price | available |
| support | response times, upgrade help, review before you go live | available |
| packs | invoicing, helpdesk and coordination, supported | available |
| Studio | the graphical tools: edit, run, replay, diff, sign | in development |
| certification | run the suite against your port and carry the mark | when the first port lands |
No checkout yet, deliberately — pilots and support are scoped in a conversation and closed with an invoice, because a fixed price for the wrong thing helps nobody. Write to nestera@nestera.net.au with what the process is and what currently goes wrong with it.
0BSD, so no permission is needed for anything: fork it, ship it, sell what you build.
What helps most, in order — read SPEC.md and say where it is wrong; run
demo.sh and say where it lost you; write a graph for a job we have not
covered; port the kernel and run the conformance suite against it.
A port that reproduces the golden hashes is Nestera, whoever wrote it. That is what the conformance suite is for, and it is free.
Rust 1.80 or newer, nothing else. 425 tests cover the conformance suite, four scenarios and the tools. The specification is the product: any host that passes the suite is a real one.
0BSD — use it, ship it, sell what you build with it, no conditions. “Nestera” and “Nestera Certified” are trademarks of ViewBuild: anyone may implement the spec, and a build that passes conformance may say so.