CLCTN · WHERE A JUDGMENT EARNS ITS PLACE · SEPTEMBER 2026
SURVEY · 59 FILES READ
NOTHING BUILT YET
The coexistence rules were already yes/no questions.
I went through the project looking for places where the app needs common sense rather than a rule, and the strongest finding was sitting in
One Roof. The seven coexistence rules — does this type have a stable public scale, does it have a corpus, is it a near-duplicate of a type we ship, does its clock describe a real decay — were written as tests for a human moderator to apply by hand, two hundred times, for free, forever.
They are already the right shape. They were just never going to get asked.Eight places in the product where a typed judgment does real work, nine unanswered questions it can stand in front of, and — more important — the list of questions it must not be allowed near. Written against the TypeSafe docs: code owns the workflow, the judgment answers one narrow thing, probabilities decide whether to act or ask.
01 · THE LINE
Code owns the shelf.
A judgment owns the doubt.
WHERE THE APP NEEDS COMMON SENSE
The product rule I would write down first: a judgment may only run where a network lookup already runs.
CLCTN's pitch is a private, local catalogue, and the API is server-side. That tension is resolvable, but only by rule, not by good intentions — see section 06. Barcode lookups, CSV imports, listing publication, type proposals and the feedback form are all already network moments the user has accepted. The shelf at rest is not one, and nothing here asks it to become one.
02 · EIGHT JUDGMENT SITES IN THE PRODUCT
Each one is a single moment in the app, one request, many narrow questions asked in parallel, and code deciding what to do with the answers. Pick a site: the state it sends, the questions, the composition and the offline fallback are all different, but the shape never is.
Ordered by what I would build first. The top two cost nothing to try — they run on a server you already have and never touch a user's shelf.
{{ siteTitle }}
{{ siteMoment }}
{{ siteWhen }}
{{ siteRisk }}
THE QUESTIONS · ONE REQUEST · EVALUATED IN PARALLEL
{{ q.id }}
{{ q.kind }}
SPECULATIVE
{{ q.ask }}
{{ q.crit }}
THE STATE CODE SENDS
{{ siteState }}
WHAT CODE DOES WITH THE ANSWERS
{{ siteCompose }}
WHEN IT IS UNSURE, OR OFFLINE
{{ siteFallback }}
03 · STANDING IN FRONT OF THE UNANSWERED QUESTIONS
It does not decide.
It makes deciding cheap.
I collected every open question still standing across the project — the five in
Video Games, the four in
One Roof, three in
App Store Brief, the nine dated decisions in
Master Plan, and the two loose ends in
decisions.md. Most of them are blocked on the same thing:
evidence nobody has time to gather. That is the gap a judgment fills — not the answer, the evidence.
THE QUESTION, AND WHERE IT SITS
WHAT A JUDGMENT SUPPLIES
WHAT IT MUST NOT DECIDE
{{ g.supply }}
{{ g.never }}
Three of the nine are shaded: those are the ones where I think the honest answer is no judgment, ever — the name, the price, and the slot-order question. They are a trademark problem, a values problem and a measurement problem respectively, and dressing any of them up as an inference would be the worst thing on this page.
04 · THE TYPE BOARD — THE ONE PLACE THIS CHANGES THE BUSINESS
Business Delta flagged moderation as the new cost that arrived with community type proposals, and pulled type-board infrastructure a year earlier than planned. That cost is a queue of free-text proposals that one person has to read. Here is the same queue with the seven coexistence rules asked as questions before a human sees anything.
{{ b.k }}
{{ b.big }}
{{ b.t }}
{{ b.b }}
AND THE RULE THAT WAS UNCOMPUTABLE BECOMES A COUNT
One Roof's second rule says a renderer needs a second customer before it enters the kit — which until now meant waiting for a second type to turn up and argue for it. Ask every proposal in the queue which renderer would this type bind? as a Choice over the kit plus none, and the customer count for every renderer becomes a number you can read off the board at any moment. The set renderer I proposed with eleven customers stops being my assertion and becomes a tally — and a proposed seventh renderer with one customer stays out on evidence instead of on my say-so.
05 · WHERE I WOULD NOT USE IT
Longer than I expected when I started, and the more useful half of the survey. Each of these is somewhere a judgment would technically work and would still be wrong for this product.
06 · THE PRIVACY LINE, WHICH IS YOUR CALL
This is the decision the whole page depends on, and it is a positioning decision rather than a technical one. The API is a server API; the app's pitch is that your collection stays yours. Three ways to hold both, and the one I would sign.
{{ p.k }}
{{ p.verdict }}
07 · WHAT I WOULD DO FIRST
{{ f.k }}
{{ f.t }}
{{ f.b }}
{{ f.cost }}
08 · OPEN QUESTIONS, FOR YOU
{{ o.k }}
{{ o.q }}
{{ o.b }}