ernster.devOliver Ernster
Principal Python engineer and software architect: APIs, integration and platform modernisation; 28 years at the seams of systems and author of the Decision Architecture series.
I don't just write about architecture. I ship it.
I use and maintain what I build. These are not portfolio exercises or abandoned demos: many are applications I depend on every day. Real use keeps them evolving; bugs get found, workflows get refined, dependencies get updated and every architectural decision is tested against the reality of maintaining software over time.
The work, in depth
Three areas of work, four questions each: what was hard, what was chosen, what it costs and what proved it. The rules the applications share, with the code that holds each one, are on the Engineering Principles page.
Evergence
A research framework for civilisational continuity and open-ended evolution: the survival and evolution of humanity and other life, with human-descended agency preserved and room made for other conscious entities.
The hard problem
Every long-horizon survival argument is tempted to borrow the register of a result: a mathematical elegance stated as physics, a speculative transition stated as a route, a survival objective stated as a licence for any means.
The decision
Label every claim. Each statement is marked normative, definition, mathematical result, empirical evidence, hypothesis or speculation; the documents fence their own constructions with their own cautions. Survival is the ambition; it is never permitted to justify atrocity, domination or compulsory stagnation.
The trade-off accepted
The framework proves nothing about the fate of the universe and says so. It states what it does not propose as plainly as what it does; if its formalism proves unhelpful the survival objective takes precedence over keeping it.
The evidence
The epistemic boundaries are published with the work: established mathematics, established physics, unsettled physics and speculative construction kept in four separate columns, with the red-team questions the framework asks of itself listed first, before any contributor can.
Go to Evergence →The framework, its site and the civic documents beside it
Applications
Shipped applications, led by PigeonPost (email, calendar, contacts) and ClearBudget (solvency forecasting), with Meridian reading feeds over MMSP, the specification written to carry them. Stellody plays a music library it is structurally incapable of writing to.
The hard problem
Webmail wants engagement, Outlook wants a subscription and the successors to RSS monetise attention. In budgeting, a monthly total can look safe while the month itself is structurally unsafe. In music, a player can damage the collection it exists to play: a commercially available one wrote tags back across 33 albums of a real library.
The decision
Local-first, structurally. PigeonPost keeps mail with your provider (no account, no relay, no telemetry); ClearBudget projects the month day by day; Meridian reads a pull-only protocol with calm written into the wire; Stellody puts the tag-writing surface out of reach of every module that can read a tag.
The trade-off accepted
The local cache is not encrypted at rest; the site says so and points to OS disk encryption. MMSP holds a 300-second poll floor, so real-time delivery is impossible on purpose. Stellody describes a damaged tag and never repairs one, so the repair is yours to make in a tagger you chose.
The evidence
A conformance suite written to cover every normative statement in the spec gates publication: a failing run blocks the specification site from publishing. Zero writes to a music file is a structural test rather than a promise. Installers ship for Windows, macOS and Linux, with the core logic held to a coverage gate.
Go to Applications →All applications and the MMSP specification
The hard problem
Organisational theory cannot be run: claims arrive in prose and reorgs get tested on real people.
The decision
Make it executable. Decitect scores structural health 0 to 100 with no randomness: same model, same number, every time.
The trade-off accepted
The units are abstract, not calibrated to your KPIs. And the model never says what to decide, only where decisions can live.
The evidence
Typical archetypes lose roughly 85% of their score as they grow; well-designed ones lose about a third. Falsifiable by design: the exact figures and the test that could break them are on the model page.
Go to Decision Architecture →Decitect, Simquence, the website and the book series