field notes codename

MERIDIAN

24 notes filed under MERIDIAN, newest first. Same rules as the rest of the pile: a codename, a theme, and no internals.

codename MERIDIAN · 24 notes · 24 themes · all codenames

MERIDIAN notes

behaviour as a lens over the record

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…

read

the successor publishes what it drops

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…

read

compatibility on its own axis

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…

read

a tie is a contract, not a feature

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…

read

an archive, not a rewrite

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…

read

the ledger that stopped saying accepted

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…

read

a fork is a genesis, not a rupture

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…

read

the base does not choose your money

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…

read

the meter moved from existing to doing

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…

read

the anchor it drew itself, and said so

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…

read

a reference is not a claim

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…

read

the version fork that was replaced by addition

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…

read

elsewhere

Other codenames

Each codename is a project. The theme is the class of problem the note is about — the same theme recurs across projects, which is usually the interesting part.