This is the post we were most impatient to write, because almost no fund publishes it. Everyone shows you returns. Almost nobody shows you the machine that decides whether those returns are real - the part underneath the chart, where a number is either reconciled to the last unit or quietly fudged.
We think that machine is the actual product. A return you can't reconstruct from first principles is a rumour, not a fact. So this is how the thing is built so that the numbers you see are the numbers that are true.
Return is an outcome. Accounting is the product.
The whole design follows from one rule: the place where money is recorded must be separate from, and more trusted than, every place where money is shown. Get that wrong and your dashboard becomes the truth - which means the truth is editable, which means it isn't truth. Get it right and the dashboard becomes what it should be: a window, not a ledger.
The ledger is the product
Most operations treat the ledger as a tool that records what the fund did - useful, but downstream of the real work. We treat it the other way round: the ledger is the fund, and performance is something that happens on top of it. Start there and a lot of design decisions stop being choices and start being consequences.
Every capital movement - a deposit, a withdrawal, a profit share, a hedge settlement, a redemption, a fee - is one append-only entry, written through a single orchestrator. There is exactly one code path that may add to the record, and it never updates and never deletes. There is no "edit." A mistake is not erased; it is corrected by a new, opposite entry, so the history of the mistake survives alongside its fix. You can replay the entire life of the fund from the first entry to now and arrive at today's balance to the unit.
That single-writer discipline is what lets one short equation hold true at all times. Your stake is denominated in units, not currency. The price of a unit is the pool's net asset value divided by the number of units that exist. Capital and units are two sides of the same entry, so the books must always satisfy:
The reason this matters to you, and not just to us: it is why a new investor cannot dilute you. They arrive, they hand over capital, they are minted units at the prevailing price. The pie gets bigger and your slice keeps its value, because the identity above must still balance the instant their entry is written. It isn't a promise in a deck. It's an equation the orchestrator refuses to break.
Invariants that scream
Writing the ledger correctly once is not enough. Systems drift - a rounding residue here, an interrupted process there. So we don't trust the ledger to stay correct; we check that it has.
An automated verifier runs every hour, on the live books, and asserts a fixed set of invariants - statements that must be true or something is broken:
- units reconcile to capital, to the unit (the identity above);
- the treasury's asset breakdown sums back to NAV, with no silent residual;
- no account, anywhere, holds a negative balance;
- the protection pool is internally consistent - every settled leg accounted, every payout mirrored back into cash;
- redemptions that paid out also burned the matching units, exactly once.
If every invariant holds, the run is silent. If even one breaks, it pages a human - immediately, with the failing invariant named. The fund effectively audits itself, every hour, forever, and the audit has no incentive to be polite. Most accounting fraud and most honest accounting errors share one trait: they need the books to never be fully reconciled, because a full reconciliation is exactly where the gap shows. So we reconcile fully, hourly, and let the gap scream if it ever appears.
Fraud and error need the same thing: unreconciled books.
The point of an invariant isn't to fix problems. It's to make it impossible to not notice one.
There is a humbling version of this we'll admit to: most of the time, the checker's job is to confirm we were boring and correct. That's the goal. A green run is not an absence of work - it's the work, succeeding quietly. The day the checker goes red is the day it earns its entire existence.
This is the whole posture of the system, in two lines:
The system is not trusted because it works.
It is trusted because it continuously proves that it works.
Kill-switches on everything
Every automated behaviour in the system - hedging, harvesting option premium, weather-driven de-risking, rebalancing, redemptions, each experimental engine - sits behind its own independent on/off flag. Not one master switch: a separate, named switch per behaviour, so any single function can be frozen without touching the others.
This sounds obvious and is shockingly rare. It means there is nothing running that can't be stopped in one move - and stopped surgically, without taking the whole fund offline to do it. If the hedge logic does something we don't like, we disarm the hedge and everything else keeps running on the same truthful ledger. New, riskier engines are born with their flag off and have to earn the flip. The default state of anything we're unsure about is: dormant, observable, harmless.
The switches are also how we run things before trusting them. A new engine spends a long time in a shadow mode - computing what it would have done, recording it, marked against real prices - while its flag stays off and not one real coin moves. We get to read its decisions for weeks before they cost anything. Only then does the flag flip.
Recovery as a first-class design goal
Strip the engineering away and an investor is really asking one question, and it isn't about uptime: if the building burns down, is there still a record that the money is mine? Not the server, not the dashboard, not the app - the record of ownership. Kill-switches are common; plenty of funds have them. A guarantee about that record under total loss is much rarer, and it is the thing we built recovery around.
So we don't start from will it break. We assume it will, and design backwards from two questions: when it breaks, how fast and how completely does it come back - and above all, what is the one thing that has to survive no matter what?
So recovery is built in from the start, not bolted on after an incident:
- Idempotent operations. The dangerous moments are the ones that move money - a settlement, a redemption payout. Each is written so that running it twice is identical to running it once. A crash mid-payout, a retry, a duplicated trigger: none of them can double-pay or double-burn, because the operation checks the ledger for its own footprint before it acts.
- Crash-safe windows. Multi-step processes that pay out and then update state are wrapped so that a failure between the two steps is detected and finished cleanly on the next run, never left half-done.
- Off-box, encrypted backups. The books are backed up continuously to storage in a different location from the machine that runs the fund, encrypted before they ever leave, with the recovery key held separately. Losing the server does not mean losing the record.
- A live mirror and full snapshots. The code lives in more than one place. The whole machine is snapshotted on a schedule, so a total-loss event is a restore-and-resume, not a rebuild-from-memory.
None of this makes failure impossible. Nothing does. What it buys is that a failure becomes an inconvenience with a known recovery path instead of an existential event.
Under any single failure, the one thing we will not lose is the truth of who owns what.
That is the line that matters. The server is replaceable. The dashboard is replaceable. The record of ownership is the one asset we treat as irreplaceable, and the entire recovery design exists to make sure it always outlives whatever broke.
Why the shape is the point
Step back and the pattern is one you'll recognise from payments systems, not from funds: a single source of truth that can only be appended to; continuous, adversarial self-checking; the ability to stop any one part without stopping the whole; and a bias toward fast, complete recovery over the fantasy of never failing.
In many funds, the ledger is an operational tool. Here, it is the system of record. Most start with performance and add accounting; we start with accounting, and allow performance to happen on top of it.
Everything above exists so that the honest answer to "how do I know your numbers are real?" is not "trust us" - it's "here is the machine that makes it expensive for them to be anything else." The returns are made at the top, by the engines. But whether you can believe them is decided in the middle, in the plumbing - which is exactly why we wanted to show it to you.
It comes down to one conviction, and most of this Journal is really a long argument for it:
Good investing starts with good accounting. Not a forecast, not alpha, not a model - first an honest record, and then everything else.
This is the architecture at altitude. Future engineering posts will go a level deeper - the exact ledger entry model, the full invariant set and how a breach is handled, and how performance is attributed to each engine without ever touching the source of truth.