The moment
A worker spends a day establishing that the streaming approach cannot meet the ordering guarantee. It is careful work and the conclusion is right. It is also the conclusion somebody reached in April.
Why it happens
Positive results become code, which is durable. Negative results become nothing: the branch is deleted, the session ends, and the only trace is an absence — the approach is not in the codebase, which is indistinguishable from nobody having tried it.
Why a better model does not fix it
The second worker reasoned correctly from the same starting point and reached the same answer. That is the definition of a reproducible negative result, and it is being paid for twice because the first one was not written down.
What it costs
In experimental work, most attempts fail, so most of the output is exactly the kind that is being discarded. The search space is re-explored at full price, and the team's apparent progress rate is lower than its actual understanding.
What Majordomus does
A decision records the alternative that was rejected, not only the one chosen — --rejected
is the field that makes a dead end durable, and --why is refused when empty. A finding
that is not a decision is a knowledge record with a class: lesson is what an earlier
attempt cost, constraint is something outside the repository that limits it. Both are
searchable across handovers, checkpoints, decisions, questions and the ledger, in the order
in which to trust them. Nothing stores the conversation the finding came from.
Before and after
before April: branch deleted. August: the same day, again.
after $ majordomus search "ordering guarantee" --kind decision --kind knowledge
decision t-… rejected: streaming — cannot preserve per-key ordering
across a rebalance; evidence test/cases/58_ordering.shWhat it does not do
It does not decide what is worth recording, and it will not mine an abandoned branch for lessons. It makes recording a negative result a one-line act with a place to put it.