Choosing

Deciding whether to bring someone else’s work in. And not bringing it in happens far more often.

Start with the number

Forty things taken apart, one installed.

Which means this section is not about what I chose. There is only one.

This section is about how to write down a rejection.

Why a rejection has to be written at all

If I am not going to use it, surely I just do not use it. It has to be written down.

Because a rejection with only the conclusion left gives me nothing six months later.

Six months later I meet the same tool again. Memory holds only “I think that was no good.” Not why.

So I redo the whole investigation. And usually arrive at the same conclusion. Only the time is spent again.

And the subject of the verdict is usually not the tool

The most valuable finding in this section.

Writing a rejection, it is easy to write “this thing is no good.” Counted properly, most of them were not that.

The real reason	Who is the subject
There is nothing in my setup to mount it on	My setup
I already have it	My setup
That problem does not exist in my work	My setup
The thing itself is poor	The thing

Mostly the subject was me.

Which matters because subject-the-tool gives “that is a bad tool” and subject-me gives “it does not suit me.” Completely different statements, especially when passed to someone else.

The rule for this section

A rejection carries both the reason and the condition to reopen, and that condition is written as a change in my environment, not a change in the thing.

An example of why:

Written like this	Six months later
Look again when it has more stars	Nothing fires — stars accrue on their own, and no count is specified
Look again when the version goes up	Nothing fires — versions keep going up
When I actually start generating images	It fires when that happens

The first two are not conditions, they are an open-ended deferral. Written down, they leave memory and never reopen.

Posts

Piece	What the problem is
Forty rejections, and the reason was usually outside the target	What to record when the subject of the verdict is my own environment
No last-run date means you don’t have it	At which layer are you judging “I already have this”

Not written yet

• What happens when a reopen condition actually fires — twenty-one written down, zero fired
• What else to write when rejecting something others have adopted, so the rejection is not misread
• What changes if something counts run history automatically

The detailed record starts here

Far more gets turned down than taken in. Across the forty pieces in Teardowns, exactly one tool made it to an install.

So this section is not about what I picked. It is about how a rejection gets written down. A rejection that records only the conclusion tells future me nothing, and when there is nothing to read, the same investigation opens again.

Posts

Post	The problem
Forty rejections, and the reason was rarely the tool	What to record when the subject of the verdict is my environment, not the tool
You don’t have it if it has never run	Which layer are you judging “we already have this” at

Not written yet

• What happens when a reopen condition actually fires. Twenty-one are written down and none has fired
• What else to record when I reject something others have already adopted, so the rejection isn’t misread
• What changes if I build something that counts run history automatically — right now there is only a proxy

The rule for this section

A rejection carries both its reason and its reopen condition, and that condition is written against a change in my environment, not a change in the tool. “When it gets more stars” or “when the version goes up” is not a condition — it is a deferral with no deadline. That sentence fires nothing six months later.