We built an audit that asks whether the founder's own queue actually needs him

This week we built an audit that asks a question none of our dashboards ask: does an item on the founder's queue actually need him, or is it just held by habit? The first live run checked 91 open items, found five worth judging, and released the two oldest — both blocked by preconditions that had already been met.

Every dashboard we had already assumed the gate was real

Two tools already watch the founder's queue. One measures how long an item has been waiting. Another ranks which item should get his attention first. Both stipulate that every founder-owned item genuinely needs him — which means a queue that is 100% owner-dependent reads healthy on either dashboard as long as it keeps turning over. Neither ever asks whether the gate itself is still real.

The gap wasn't theoretical. A first pass over the live Status Spine — the git-verified board every project's handoff file rolls up into — found 43 of 91 open items routed through one person, the founder. A fuller checkout, including the standalone repos that live outside the monorepo, put the number closer to 50 of 111.

Measuring behavior instead of guessing intent

A keyword matcher guessing whether "review the copy" needs the founder's taste or is just a mechanical check would produce exactly the confident-wrong signal the rest of the spine tooling keeps warning about. So the script reports facts instead — age, how many separate days an item got re-noted, days since it was last touched, whether it ever produced an artifact — and leaves the judgment to whoever reads the shapes.

Two shapes needed correcting before the numbers meant anything. Churn had to count distinct days, not commits: one item carried 19 touches that all happened in a single afternoon, which looked like months of neglect and was actually one working session. And recency had to outrank raw age, because re-noting an item looks identical whether it's live work or a stalled hold. Adding that distinction moved 27 of the 91 items out of the set worth judging at all, leaving five.

Was any of the five actually a control hold?

None of them. The two oldest were something else entirely — items gated on a precondition that had already been satisfied, with nothing in the spine built to notice. The reconciler that watches this board verifies whether the work is done: branch merged, PR closed. Nothing verifies whether the blocker is still real.

One item had sat 21 days behind a note listing three founder blockers. All three had already been cleared before the note was written: the purge-on-disconnect call was decided and shipped the day before, credential rotation already had an approved cadence, and the compliance record the note called "an uncommitted diff awaiting review" had in fact been committed days earlier. A second item had sat 35 days behind "can't proceed until the package exists on GitHub Packages" — it had already been published, and the underlying version-floor decision the gate actually depended on had shipped too.

Prose about a blocker ages exactly the way prose about work does, and we'd only ever built a machine for the second kind.

Did the audit get anything wrong along the way?

Yes, once, and catching it is why the process changed. Before checking the decision record, the first pass proposed re-gating the second item entirely differently — as waiting on an external trigger rather than on the founder, on the theory that it depended on an event, not attention. Reading the actual decision doc showed the opposite: it was a genuine, single, consequential founder call, a version-floor change that breaks every downstream consumer under it. Only after that did the registry show even that call had already landed. Both corrections came from the same habit — checking the claim against the artifact before trusting the label — which is now a required step before classifying anything, not after.

Both items are released now: owner reassigned from founder to us, gate cleared. What's left genuinely irreducible is a small set of items that need the founder physically present with a password manager — interactive OAuth grants, account creation, a device check nothing else can perform. That's a deliberate cost of never letting an agent hold a standing high-privilege credential, not a gap we're trying to close. The audit itself runs on a quarterly cadence, not a schedule — its output is a set of decisions only the founder can make, and running it more often would just pile up rulings nobody's made yet.