Demo / scenarios · 2 of 3

A decision, and its reversal six days later

One run from the demo vault — a complete, fictional chief-of-staff system built by Claude Code sessions working from the bootstrap prompt. Rowan is invented and so is everyone here, but the files, the quotes and the commits are real: every one of them can be opened.

Input

A question about a family business that had been avoided for four months, forced by one phone call

Outcome

The decision was written down with the conditions that would prove it wrong — and six days later one of them did

Guides

decision records for a lifefiles are memorythe constitution

Most decisions are never written down, so being wrong about one is invisible until it is expensive. This is what happens when you write the decision down with the conditions that would make it wrong — and then one of them arrives.

What happened

Rowan inherited his father’s machine shop. He owns it; his sister Claire runs it. Three futures had been on the table for four months — sell it, retool it for aerospace parts, or wind it down — and he had been avoiding the call.

Claire forced it. She gave him a deadline and a sentence:

“Rowan, I’m not asking you to decide because I need permission. I’m asking because I’m forty-two and I’ve been running someone else’s company for three years and I need to know if it’s going to be mine or if I should go.”

He decided: retool for aerospace. The assistant wrote it up — and did two things nobody asked for.

It split one decision into three, because the retooling, the question of whether the shop should supply Rowan’s own company, and whether Claire should own part of it are separate bets that were being made as a bundle. And it named the biggest hole in the reasoning:

“Claire’s view is not in the vault… the largest hole in the decision and it is one phone call wide.”

Then it attached the condition that would undo the decision — aimed at exactly that hole:

“Claire’s view, once written down, is not retool. The direction is chosen for a company Rowan does not operate; if the person who does operate it disagrees, decision 1 was made on half the evidence. This is the one most likely to fire, because the input is missing rather than contrary.”

Six days later Rowan sent her the write-up. She read it and called. She did not want the retooling. She wanted to buy forty percent of the company over five years and retool it herself:

“I didn’t think I was allowed to want that.”

How it works

1. The decision was forced by a date, not taken when convenient. Four months of avoidance ended because someone else set a deadline.
2. One decision became three. Bundled decisions fail together, for reasons you cannot separate afterwards.
3. The missing evidence was written into the record. Most decision logs record what you knew. This one recorded what you didn’t.
4. A reversal condition was attached to that specific gap, in observable terms — along with a prediction about which condition was most likely to fire, and why.
5. The condition fired and was recognised as such, because it had been written in advance. Six days later there was no argument about whether things had changed.
6. The reversal is a new entry, not an edit. The original stands, wrong, pointing at what replaced it. Rowan was explicit about this:

“I don’t want it edited into something that looks like I got it right the first time. Write the reversal, say what fired, and say plainly that the condition you attached was the exact condition that fired, six days later.”

Why it matters

The system did not predict Claire’s answer, and it was not supposed to. It predicted which part of the decision was weakest, said so in writing, and named the single phone call that would settle it.

That is the whole return on writing decisions down. Not being right more often — noticing that you were wrong while it is still cheap, and knowing exactly which assumption broke.