field notes
Short notes from real engineering work: one decision, one incident, one reversal at a time. Each one names the shape of the problem, the tension that made it hard, the decision, and what it cost. The internals stay out — the codename is the hint.
If you have five minutes rather than an afternoon: the three case studies condense this material to one problem, one decision and what the decision cost. The notes below are the record those studies cite — and the projects the codenames belong to are on the front page.
From its first round, this cluster carries a place for the ethical and philosophical claims the design rests on, written in prose and revised alongside the technical record. It is not a rulebook for participants and not a statement of…
There is a dedicated artifact in this cluster for the founding identity, built with the same participant model as anyone else: a self-describing manifest, owned artifacts, and agreements that express what it may do.
The record describes participants as actors. That framing is familiar and it arrives with baggage: an actor needs mutable state and an inbox, which this same design forbids storing, because its records are immutable. One half of the design…
Documentation for a late prototype in this cluster opens with a map of what it replaces. It lists what came forward from earlier rounds, what is new, and what has been set aside for a later one, and it names its predecessors explicitly…
Once there are many independent lineages, the question of whether two of them are compatible stops being answerable by comparison. They will never share a label, so there is nothing obvious to compare. The record answers by giving…
The obvious build is a relationship service: a table of who is bound to whom, a query surface, a component that can answer membership questions on behalf of everything else. The record refuses it. Ties between identities are agreements made…
Work that stops being true is usually deleted, or quietly left where it falls. This record does neither. Deprecated material was imported into a place of its own with its history attached, and later the pieces nested inside it were…
One entry in this cluster is a subtraction. The status marks were removed from the decision headers and replaced with timestamps. A record of decisions had been labelling each one with where it stood; afterwards it records only what was…
A fork is usually treated as a failure: a community that could not agree, a codebase now living twice, a project that split and lost. This record treats it as an operation with a name and a place in the design. Anyone may begin an…
A stack this tall invites a bespoke mechanism at each level. The record refuses that too, and the refusal is visible in the words: one vocabulary is applied across the whole cluster in a single round, and one pattern repeats at every level…
The catalog at the root of this design had an easy option: name a unit of account and be done. The record declines. The platform is described as currency-agnostic — payment is declared by contract, so one catalog carries many payment…
The first economics in this cluster charged for staying. An identity that remained present carried a continuing price for remaining present, and one that fell quiet was eventually wound down — existence as a subscription. The record…
A catalog cannot prove itself. Whatever sits at the root of authority has to be named, and the honest options are to name something external — which this design cannot supply — or to name itself, which is a statement about bootstrapping…
The most useful single change in this cluster is a documentation edit. A document describing a layered infrastructure design — entry points, hubs, data plane, topology, control — had been written as the architecture of the network. The…
The failure that drove this decision is worth stating in its own terms. A record points at another record by its content identity, and identity looks like proof. It is not. Anyone can build a registry of their own and assert that a given…
Moving live state between two foundations is the part of distributed design that usually happens once, badly, at an unsociable hour. This record treats it as a standing role instead of an incident.
This cluster contains a clean reversal. An earlier model had worlds evolving by version: a world produces a new version, consumers migrate across, the old one eventually falls away. The decision that replaced it says the opposite — worlds…
The most thorough early design for keeping history was also the one that could not be paid for. The pruning record says it plainly: an archival scheme where old state is kept cold and revived on demand requires someone to maintain that…
The recurring bug here is that an object is told who owns it. A field on the account says "owner: that identity there." The owner says nothing, so nothing cross-checks the claim. Half a binding looks exactly like a binding, which is why so…
Delegation is where most systems quietly become custodial. You grant someone authority to act for you, and the record of that grant ends up in whatever store the delegate controls. You find out how it was used afterwards, if at all.
method
Not a changelog entry and not a repository summary. One decision, one incident, one reversal, or one hard-won invariant — the thing an engineer would tell you at a whiteboard.
Prefer records with dates and root causes? Those are on incidents. Live numbers are on stats.