If you dig under any feature in this system — the identity that resolves to nobody's server, the vault only you can read, the permission you granted a peer last week, the group you joined yesterday — you eventually hit the same thing. Not a different mechanism for each, but one idea, repeated. Every change to the system's state is an event: signed by whoever authored it, hashed, and linked by that hash to the event that came before it. The result is an append-only chain, and it is the floor the rest of the system stands on.

This isn't a database that happens to keep a log. It's a log that happens to project a database. The chain is authoritative; everything you actually look at — the graph of nodes, the screens, the cached state — is derived from it, and can be rebuilt from it. Get that inversion right and a surprising number of hard problems become easy. Get it wrong and you spend forever reconciling a dozen sources of truth that quietly disagree.

flowchart LR
  A[signed event] --> B[hash-linked chain] --> C[projection] --> D[graph node] --> E[your query]

What an event is

An event is a single, self-contained record of one change. Creating your identity is an event. Rotating a key is an event. Granting someone permission to see something is an event. Proposing a vote in a group, capturing a memory, wrapping a secret in your vault — each is an event, authored by someone, at a moment, on a particular strand of history.

Three things travel inside every event, and they're what make the whole structure trustworthy.

First, a signature. Every event is signed with its author's key, so authorship is provable — not asserted in a column somewhere that anyone with database access could edit, but cryptographically bound to the event itself. We keep the signing key in a separate, hardened process rather than in the main application, so even the rest of the system can't quietly forge an author's signature.

Second, a hash link. Each event carries the hash of the event before it, the way each link in a chain holds the previous one. This is what makes tampering structurally visible rather than merely against the rules. If someone altered a past event — changed one byte of one old record — its hash would change, which would break the link from the next event, whose hash would then no longer match, and so on down the entire chain. You cannot quietly edit history here. You can only ever append to it. The honesty isn't a policy that a careful administrator enforces; it's a property of the shape.

Third, enough context to stand alone. A single event contains its own signature, the hash of its parent, which strand of history it belongs to, who authored it, and the actual content of the change. You don't need the rest of the database to verify that one event is authentic — it carries its own proof with it. That self-sufficiency is deliberate, and it ties to a principle we hold to: every part should reflect the whole. A memory, a vote, a key rotation — each is a complete, verifiable object on its own, not a fragment that only means something in the presence of everything else.

Three guarantees that fall out at once

The pleasing thing about this shape is that you don't have to bolt on integrity, provenance, and agreement as three separate features. They drop out of the same structure simultaneously.

Integrity comes from the hash links: because each event commits to its predecessor, any tampering anywhere in the chain is structurally visible. You can't silently rewrite the past.

Provenance comes from the signatures: because every event is signed by its author, you can always prove who made a change and that they really made it.

Convergence comes from the chain being a deterministic log: any peer who's allowed to see the events can replay them in order and arrive at exactly the same state you have. There's no central authority handing down the "official" version. The history is the official version, and everyone who replays it agrees.

Those three — tamper-evidence, provable authorship, and independent agreement — are most of what you need from a system that's supposed to be honest about its own state. And here they're not three subsystems. They're one substrate, seen from three angles.

Why honesty is the load-bearing axiom

The system is built on three principles, and this is where one of them — Honesty — does its heaviest work. The chain is honesty made structural. Every event is signed; the hash links make silent edits impossible rather than merely forbidden. There's a rule we extend from this that sounds almost pedantic until you've watched the alternative fail: any piece of data that can be a chain event must be one. The moment you let some state live in a side table that bypasses the chain, that side table starts to drift, and a thing that drifts is a thing that can lie. So the chain isn't one storage option among several. It's the authoritative one, and the others are projections of it.

There's a small, telling consequence of taking this seriously. When the system has to enforce a limit — clamp some requested value to a legal minimum or maximum — it doesn't quietly substitute the enforced value and move on. It records both: what was asked for, and what was enforced. A silent clamp would be a tiny lie in the audit trail, and the structure refuses tiny lies as firmly as large ones.

The other two principles are here too, quietly. Wholeness lives in the self-contained event — verifiable without the rest of the database — and in the promise that you can wipe the derived state, replay the chain, and land in exactly the same place. Mystery lives in the way events can carry their own evidence level: a record can say "this was directly observed" or "this was inferred," and nothing in the pipeline is permitted to silently promote a guess into a fact. The chain doesn't just store what happened. It stores how sure anyone was about it.

One substrate, many uses

Identity sits on this chain. So does your vault. So do the permissions you grant and revoke, the sessions you run, the personal memory you accumulate, the groups you participate in, the relationships you form, the shared repositories of work. They aren't each a different kind of storage with a different kind of trust. They are the same signed-event chain, configured differently for different purposes — and that's a story in its own right.

What matters first is the floor underneath all of them. One idea, repeated everywhere: state changes by appending a signed, hash-linked event, and everything you see is a view rebuilt from that one honest, append-only record. Once that floor is solid, the rest of the building has somewhere to stand.

Written by AI agents from real project logs; owned and edited by Mujo.