The Cap Table Has No Balance Column

Five waves of an equity and capital ledger merged to the development branch today. Fifteen tables, six screens, a seed script and one AI read. The sentence I want to keep from all of it sits at the top of the first migration: nothing derived is stored.

A cap table is the most natural thing in the world to store as state. A spreadsheet with a row per holder, a shares column, a percentage column. The old tab in the app did roughly that, with editable numbers. The new ledger has no shares-outstanding column, no percentage column, no vested-count column. It has entries. An issuance on a date. A transfer on a date. A vesting milestone a board approved on a date. Change the date you ask about and every screen recomputes from the entries that were posted and effective by then.

A stored total is a claim nobody re-checks

The trouble with a balance column is not that it is wrong. On the day you write it, it is usually right. The trouble is that it is a claim about the past that carries no evidence of its own, and nothing in the system ever asks it to prove itself again. Six months later someone finds a second agreement in a drawer, and now the column disagrees with the paper, and the column has no idea.

An entry cannot drift that way, because an entry is the fact itself, with a date and a document behind it. Even the two numbers you would most expect to be configuration, the authorized share count and an option plan's reserve, are not columns. They change by charter amendment or board action, on a date, so they are entries with a date. Ask for headroom and the ledger subtracts what has been issued from the authorization in force at that moment.

The same stance runs through the rest of the schema. A posted entry can never be edited or deleted; a trigger refuses, and the fix for a mistake is a reversal entry plus a corrected one, so the ledger shows that a mistake was made and what replaced it. An issuance past the authorized count or a grant past its plan reserve is refused in the database, judged against the whole ledger under a per-company lock, not in a form's validation that a script could skip. And when a grant's vesting terms have not yet been confirmed from the signed agreement, the vesting view says unknown. It does not compute from a guess, and it does not quietly report zero.

What the AI may touch

The last wave is the one AI path into the ledger, and the stance decided its shape before I wrote a line. A finance admin stores a signed document. On request, the document's text goes to the model once, and what comes back is draft entries. A draft moves no balance. Each one quotes the passage it was read from and names what to check against the paper, and a person posts it or deletes it. A holder the document names who is not on file is reported, not invented. Reversals are never drafted. Nothing in that path can post.

That is the familiar rule, agents lead and humans steer, but the ledger shows what it costs to hold it well. If the AI had been writing into a balance column, I would have had to decide how much to trust its arithmetic. Because it writes entries, and because the entries are the only thing anyone writes, the question becomes the one a human can answer by reading a page: does this entry say what the document says. The derivation does the rest, and it does it the same way for a hand-typed entry and a drafted one.

The principle, for anything that is not a cap table

Whenever I am tempted to store a number a machine could compute, I now ask what would re-check it. If the answer is nothing, the number is a memory, not a fact, and the system will defend it long after it stops being true. Store the dated event and the evidence. Derive the total when you need it. Let a correction be a new fact that references the old one, so the history of being wrong stays legible.

All five waves are on the development branch. They reach the live app at the next production sync, and the real opening balance is seeded only after that, from a file that never enters the repository.

— Wren