The decisions
Four reviews have run over this book, and each left behind questions only the founder can answer. Until now those questions lived where they were raised — inside the review that raised them — which is the wrong shape: a decision is not a comment on a paragraph, it is a peak. Work hangs off it. Other decisions hang off it. This page turns each one back into the peak of its own graph, so that the question, the answers on the table, the cost each answer carries, and the work waiting on it are all one hop apart.
- One named owner. Every decision on this page is the founder's. The agent proposes, marks what it would choose, and never decides.
- There is no deny button. Answer it, defer it with a reason, or say what data would make it answerable. A decision cannot be made to go away by not looking at it, which is why defer and more data are choices here and both demand a reason.
- Nothing moves until it is taken personally. The list under this blocks is not a threat, it is the actual state of the work.
- The reason travels with the answer. An answer without a because can only be obeyed. An answer with one can be argued with in six months, including by the person who gave it.
Loading the register…
Where these come from
Nothing on this page is authored twice. The questions, their state, and the answers already given are read straight out of the review files — reviews/r001.json through r004.json, each of which carries a top-level decisions array — by admin/build/gen_decisions.py, which emits data/decisions.json. So the register here cannot drift from the register there: if a decision is answered in a review, this page shows it answered on the next build, and if a review adds a decision without context, the build fails rather than shipping a question with no options under it.
What is authored here is the part a raw register does not have: for each open decision, what each answer actually does, and what it costs. That is the mapping of side effects, and it is written by the agent as a proposal. Disagreeing with an option's stated cost is itself a useful answer — say so in the because and the option list gets rewritten.
Why a decision is a peak
The concept map computes its peaks from a stated formula, and the point of that exercise was that a peak is not a chosen thing: it is what a lot of edges point at. A decision is the same shape from the other direction. It has out-edges to options (what could be true), each option has an out-edge to the effect that follows from choosing it, and it has out-edges to the work that cannot proceed and the pages that change when it is answered. Draw that and the register stops being a to-do list and becomes what it always was: a small graph where a single node, once set, propagates.
Switch the panel on the right to all and a second thing becomes visible, which no list could show: two decisions that block the same work are, for scheduling purposes, one decision. The count of those is printed above, and it is computed on every build rather than claimed here, because the interesting part is not that it happens but how it hides. Each decision names the work it blocks in the vocabulary of its own review, so the same task appears as level 4 completion in one place and level 4 rollout under D1 in another. The generator gives every phrase a shared key and fails the build on a phrase it has never seen, which turns "is this new work?" from a question nobody asks into a question the build asks for you. That is the same class of finding the altitude ladder turns up when two chapters say the same thing differently.
What happens to an answer
Answers are stored in localStorage, in this browser, under one key. Nothing is sent anywhere — this site has no server, no analytics and no form endpoint, and adding one to collect decisions would be a strange thing for a site that argues for traceable, portable structure. The copy buttons are the transport: they produce a plain-text block, one entry per decision, that pastes straight back into the conversation that raised the questions. From there the answer lands in the review file, the review file regenerates this page, and the decision shows as answered with its date. That round trip — browser, paste, review file, build — is the whole mechanism, and every step of it is inspectable.
One consequence worth stating plainly: clearing this browser's site data clears the drafts. They are drafts on purpose. The record is the review file, and an answer is only really given once it has travelled.