codalume.com

ai orchestration · operating record

I operate crews of AI agents
the way a company operates engineers.

Isolated workers, a visible board, a supervisor who can watch, speak to and stop each one — and an operating record where every session ends in a verdict. This site is that record: live dashboards, published post-mortems, and the notes behind both. The evidence is the product.

What is being built Three case studies How I work
server-rendered no trackers every claim points at an artefact the door is a puzzle

Anti-abuse: before a machine gets into the network, it solves a cuckoo puzzle. Admission by proof, not by promise.

Built and operated by Maciej Mionskowski — programming since 2012, 5408 days and counting.

supervisor@codalume — session 
$ supervisor status
coordinator ... one per session
workers ....... isolated — one worktree, one branch
control ....... watch · speak · interrupt · stop
board ......... every finding becomes an item

$ tail -f operating-record
✓ lane closed   verdict PASS — changed / verified / remaining
! lane blocked  verdict BLOCK — what was refused, and why
  audit sweep   read-only · one written verdict per host

$ _
illustration, not telemetry — live figures on /stats

origin

My first real program was chess: I wrote it in C++ and worked on it every day for a few weeks — five thousand lines by the end, the rules enforced with pointers, the figures drawn in the console. It was a significant achievement at the time, my first proper journey with coding, and the counter above has been counting from it since.

the big projects

What is being built

Seven multi-repository projects, published under codenames. Each one gets a line about the problem it is built around and an honest status — and nothing else until it is finished.

references when complete
MERIDIAN in preparation
A layered architecture where each layer is enforced by machinery rather than agreed by convention — including admission that proves work before it grants access.
UMBRA in preparation
Distributed storage where the hard part is not storing but agreeing: versioned protocol evolution across peers that fail as silence, not as errors.
TROUPE operational
Many autonomous workers, isolated from each other and observable while they run — the supervisor's view has to stay truthful when a worker lies about its own state.
MISE in preparation
One business logic core behind several very different front doors, where the shared data model decides whether the platform holds together or quietly becomes several products in one process.
ABACUS research
A research engine where a wrong default is expensive immediately, so the pipeline is built around evaluation gates and kill-switches rather than cleverness.
LATTICE research
Mathematical research run as engineering — the difference between a proof that convinces you and a computation that convinces someone else.
KEEL operational
The operations story underneath everything else: reproducible provisioning, configuration as a repository, and a small fleet made to behave like a large one.

Status is a word, not a roadmap: operational means the system runs my own work today, in preparation means the build is underway, research means the work is still exploratory. No links yet, deliberately — a project earns a public reference when it is complete, not when it is announced.

Three of these codenames — ABACUS, UMBRA, KEEL — are written up in full, with what was decided and what the decision cost: read the case studies →

for investors the record is the material

If you are evaluating this as an investment

The diligence material is not a deck. It is this site, already written, and it is arranged to be tested rather than admired. Four places, in order:

01 / proof
The case studies ask the same four questions of every system — what made it hard, what was decided, what the decision cost, what it proves — because a decision and its price are harder to invent than an outcome.
02 / method
How I work names six mechanisms, each one with the failure it exists to prevent. If the method does not survive that reading, nothing else here matters.
03 / behaviour
Post-mortems and the open board show how failure is handled when nobody is watching — including the items that are still open.
04 / outside check
Contributions is the one claim that does not rest on my word: code in a public repository, reviewed and merged by its maintainers, with commit hashes checked against git history.

There are no projections on this site. A projection is a claim about the future; everything here is a claim about the past that you can check. What is on offer is the method and the record it produces — not a forecast.

method

How I work

The unit of work is not a prompt: a worker with a scope, a crew with a coordinator, a verdict at the end. Six mechanisms hold that shape in place — a thing in the repository each time, never a principle on a slide.

the full method →
verdicts
Every session ends in a verdict — what changed, what was verified, what remains, and the artefact behind it. “Done” is not a status a worker can award itself.
gates
Two mechanical gates between work and publication: one refuses identifiers, real names, money claims and hype in the prose, the other fails if a repository is readable from outside.
freeze
The published tree is frozen by hash. A lane that changes it proves the hash moved; the check fails loudly instead of trusting a diff review.

The other three, in full on the method page: board — every finding is an item with a state, and the open ones stay visible on now; lanes — one coordinator per session, every worker isolated so a bad one is cheap to abandon and nothing it does is invisible to the supervisor, the merge the only place two lanes meet; audits — read-only sweeps on a cadence, each with a verdict.

field notes

The writing

Short notes from real engineering work, published under codenames: one decision, one incident, one reversal, one hard-won invariant at a time. They are written for a reader who wants to know what was hard — not what was launched.

read the notes →

one idea

A note is a decision

Not a changelog entry and not a repo summary: the problem's shape, the tension, the call that was made, and what it cost.

codename only

No real names

Every system appears under a codename. What it actually implements is withheld by design — the reader should finish knowing what kind of engineer this is, and still be unable to rebuild anything.

verifiable

No claim without a mechanism

A mechanical gate refuses identifiers, real names, money claims and hype vocabulary before a note can be published. A clean run is necessary, never sufficient — judgement still writes the note.

post-mortems

What broke, and what changed

4 published notes, written after the fact, not during. Each one ends in a change — and in a line about what the failure taught the method, not just the system.

all post-mortems →
· 4 min read

The day the mesh died from an expired certificate

Two certificates on the host that terminates the mesh were failing to renew. One had already expired, so the machine could no longer authenticate to its own cluster. The other expired in October and took the control plane with it: every agent that reconnected was refused until the certificate on the wire was fixed.

taught the method “we have a timer” is not a control. Every claim of renewal has to name the thing that reads the renewed artefact, and prove it on the wire.

netbirdtlsacmednspostmortem
· 4 min read

The zombie handshake storm

Four hosts with expired client certificates retried against three cluster voters, indefinitely — two of them several times a second. The servers were right to reject them; the failure was that our alerting turned a certificate-hygiene bug into a leader-flap panic.

taught the method an alert that fires constantly is not monitoring, it is noise with a rota. The audit cadence checks the credential behind a timer, not the timer's status — an enabled unit failing every run looks identical to a healthy one.

nomadconsultlsalertingpostmortem
· 4 min read

The cert that killed 215 allocations

A daily renewal that never told Vault to re-read the file it replaced. Hours later, 215 gitea allocations and 216 traefik allocations had failed on a TLS handshake the cluster could no longer complete — and six days later the same blast radius returned through DNS.

taught the method a lane's report separates “changed” from “verified”. A renewal is not done when the file changes; it is done when the consumer proves it read the new file.

vaultpkinomaddnspostmortem

trust chapter

What the record runs on

Security and operations are not the headline here; they are why the record can be trusted. Declared layers, reviewed changes, alerts with an owner, restores rehearsed rather than assumed — and public dashboards that keep updating whether or not anyone is watching.

layers + live dashboards →

declared

Nothing clicked into place

If a change cannot be reviewed as a diff it is not done. A manual fix in an incident is expected to be written back the same week.

observable

Alerts with an owner

Pages are for things a person can act on. Everything else is a dashboard, a ticket, or a note — and a channel nobody reads is not a control.

recoverable

Restore is the test

A backup counts once it has been restored and verified. Until then it is an unverified copy, and the audit treats it that way.

cadence

The operation, counted

One recorded dataset, read by the server: how much was built, across how many systems, at what cadence. Volume is the least interesting number on that page — the shape over time is the operation.

the numbers →

contributions

Work in code I did not write

Two capabilities in code someone else built: one that landed upstream under its maintainers' review, and one that hardened a fork for my own fleet — deliberately not upstreamed. The page says which is which, because the difference is the honesty.

the contributions page →

upstream · reviewed

A lifecycle record for agent runtimes

Turn start, completion, failure, stall and session boundaries, emitted as one line per event — off by default, bounded and pre-redacted, and recovered from a torn file rather than corrupted by it. Reviewed and merged by the project's maintainers.

internal fork · not upstreamed

A safer self-update path

Four changes to a tool my own fleet runs, one of which makes the update path's own trust anchor explicit — because a self-updating tool that cannot verify what it fetched is a remote-code path with a version number.

One of these is checkable without trusting me: the upstream history is public and somebody else's review gate had to accept it. The other runs my fleet and was never submitted — the page says so instead of blurring them.

contact operators and investors

Two reasons people write

If a system you run has to stay up, describe it and the failure you are worried about. If you are doing diligence, name the claim you want tested and I will point at the artefact — or say plainly that it is not there.

Get in touch Read a post-mortem first