Everything on the portfolio-architecture board that no engineer and no agent can move — collapsed from row ids into the actual acts, so it can be worked down in a sitting.
Derived from the board — measurement date below.
Most of what is left is not engineering. It is a short list of production runs, answers and presses, and almost all of it is owed by two people. The board cannot show that, because a board shows rows and a row cannot say “this is yours.”
Everything else on this page is read off the board, by matching the words a row happens to use. This section is not. The decider writes a receipt every time it decides a question is a person’s to settle, and raising it to a founder is a separate act a session has to remember — the raise stamps the receipt’s id onto the question it opens. So the two records join, and a receipt that no question names is an escalation that reached nobody. What is below is there because the join found it, not because somebody retyped it onto a row.
What this count is, and the two ways it is wrong. A receipt counts as asked if its id appears anywhere at all inside any raised question — the loosest possible match — so the orphan figure is the low estimate and the true one is at or above it. Against that, both records are local to the machine that derived this page: a question raised from a different machine would read here as never asked. The raise writes its record before it publishes anything, deliberately, so a question raised on this machine is in the store whether or not the publish worked — which is what makes an absence mean something. And this counts questions, not decisions owed: the same question asked twice is two receipts.
Why this and the cap above must be read together. A session may hold three open question sets. When all three are full of genuinely unanswered questions, the next escalation it makes has nowhere to go at all — the receipt is written, the raise is refused, and the queue simply does not grow. So a short queue is ambiguous: it can mean little is blocked, or it can mean the sessions that would tell you are full. The orphan count is the half of that picture the queue cannot show, which is why it is on this page and not a different one.
This page raises none of them, deliberately: raising is a session’s act with its own rules, and firing a few hundred escalations because a page can finally see them would be a worse version of the same mistake. Seeing them is the whole point. To pull one lane’s own out of a list the whole machine writes into: bin/board-founder-queue --task <name>.
It could not be raised, and the reason is mechanical rather than anyone's oversight. A session may hold three open question sets at a time; a fourth is refused. That cap is deliberate and it is a good rule — it exists so nobody opens a wall of separate pages — but it has a consequence nothing surfaces: when a session's three slots are full of genuinely unanswered questions, every further finding it makes is stuck inside it. Four separate rows on this board record exactly that, each in its own words: “this session holds the ledger's maximum of three open blocks, all genuinely unanswered” · “one of this session's three ledger slots, all three full, so nothing further can be raised from here” · “it was never carded because the open-decision cap of 3 is full” · “raised as soon as a decision slot frees.”
What a founder can do about it: answering any one open set frees a slot and unsticks whatever is queued behind it. The slowest-moving sets are the ones to clear first, not the newest.
Where the number above comes from, and what it is not. It walks the escalation store with the same predicate the cap itself uses — a block whose state is open and which is not a waiting row — because that is literally the expression the refusal is computed from, which makes the store the authority for “is the queue full”. It is not the authority for “was this block ever raised”; the tool's own header says that is the published record, and the two questions have different answers. A store that cannot be read reports unknown and never zero: “nothing is queued for you” and “I could not look” are the same silence, and this page exists because that silence already cost a live escalation. The 48-hour figure is there because an abandoned session's unanswered question still sits in the store without holding anybody up.
The board has no field that says “this waits on a human.” So each open row's title, its context and its newest attachment reason are matched against the phrases rows actually use — “a human must run”, “Fede must arm”, “NEEDS HUMAN”, “a production read”, “hold-for-review applied” and about forty others. That is a signal, not a census, and it is wrong in both directions:
And one ruling has to come off every number, not just the headline. Until 16 October the total was taken after the rulings while the per-kind counts, the every-reason check and the phase-only count were all taken before them — so a row already ruled dead still sat inside “a write against production data”. Two populations behind one table is the same defect as a figure quoted with no method, one level down, and a founder reading two numbers that disagree has no way to tell which one to act on. Every figure in the table below is now drawn from the same rows; the single figure that is not says so in its own row, and wherever a count moved it prints what it was.
An empty result is evidence about the search, not about the board. So named rows are asserted on every run — two that must be found and two that must not be — and the derivation exits non-zero if any of them disagrees. A control that could not be evaluated is reported separately from one that disagreed, and the line below says which happened. Each control is pinned to a board row, and a row closes when somebody ships it, so every control here expires by success on a schedule nobody sets. Folding “this control has closed, nothing ran it” into “this control ran and disagreed” froze this page once: the single negative control merged on 2026-10-15, the re-derive refused to write, and the page stayed at its last good build while reading exactly like a current one.
An earlier pass of this count said “46 of 53” and this one does not reproduce it. The closest denominator it could have meant — the twelve phase groups on their own — is the last row of the table above, and both halves differ. The board also moved in between. The gap is recorded rather than smoothed over, because the useful thing here is not which number is right: it is that a figure of this shape can move by a fifth on a differently-drawn question, which is the whole argument for printing the method beside it.
This page is generated, not maintained. One command re-reads the board and rewrites everything above:
bin/board-founder-queue --write
The acts themselves — the collapse from row ids into “run this”, “answer this”, “flip these in this order” — are the one hand-written part, in artifacts/founder-queue/acts.json, because a founder cannot act on a list of row ids. That hand half cannot rot quietly: every run joins it against the live board and refuses to go silent about a mismatch, printing UNMAPPED for a flagged row in no act and STALE for an act naming a row that has closed. A drifted map is a failed run, not a page that went slowly wrong.