Main idea

Some rejections deserve to be written down, because they produce dated knowledge: we turned this topic down for a cost, a strategy, a feasibility, a missing skill, demand too weak, bad timing. A year later, the business has evolved, the product's position has changed, AI has made feasible what was too expensive, the team has hired a data analyst — and knowing the original reason is what lets you tell whether the decision should change.

The trace only has value, though, if it stays a past decision. The moment it keeps a pending status, it reconstitutes under another name the very queue you wanted to remove. The difference isn't in where you write, but in what you write: a reason and a context, not an intent.

Not all rejections deserve that work. Plenty of weak ideas disappear without a trace. A structural, recurring or cross-cutting rejection justifies a documented decision — reason, context, alternatives set aside, and the conditions that could make it change.

Refusing to translate a product into every language prospects ask for is the textbook case: the trace doesn't keep the topic "translate into Italian", it keeps the rule that led to not doing it — a French-English base, a signed revenue threshold beyond which it changes, and translation cost as the condition for reassessment. A year later, the salesperson who comes back with an Italian prospect doesn't reopen a queue: they come up against a rule, or else they demonstrate that its exit condition is met. The trace therefore separates two things language conflates, the rejection of a case and the rule that rejection follows from; it is the second that gets preserved.

Layer added by "Product Decision Record: tracing the product choices that shape the company" (2026-06-03).

Layer added by "The Art of Capture" (2026-06-16). Two precisions come from individual practice, where the rule hardens. The first names the form pending status takes here: a second space for "maybe later" sources. It removed nothing, it moved the problem to a less visible place — that is how a system fills up with quiet graveyards.

The second lowers the threshold below which nothing at all should be traced. On a personal queue of captures, keeping a detailed history of rejections ends up costing more than it returns: the system exists to help you think, not to administer your own abandonments. Sorting between traceable rejections and silent ones, optional in a collective setting where revision can be argued, becomes there the condition for the record to exist at all.

The rule extends to the rejection of a finding, not only of a topic. A gap noted on a product then disproved after verification — the link between two objects was in fact correctly described, contrary to what had been recorded — stays in the card, marked as rejected, with the reason for rejection. It no longer carries any work to be done, so it doesn't clutter; and it prevents the same mistake being made again in six months by someone else, who would set off from the same clue. Being wrong is part of the work, provided the mistake leaves a usable trace.

Layer added by "I wrote a product's ontology. Three times, I thought I was done." (2026-08-11).

Why it matters

This lifts the objection that stops you closing things: "if we throw it out, we'll lose the reason". You can keep the reason without keeping the topic.

It also gives the selection criterion most decision records lack: you trace what is plausibly revisable, not everything that has been turned down.

Nuances and limits

The line between a reason and an intent blurs fast: "turned down for now, to be revisited if demand comes back" has the shape of a decision and the function of a pending item.

And a trace is only useful if someone finds it again at the moment the question returns — which presupposes filing by topic, not by date of rejection.

Open questions

• How do you retrieve an old rejection at the exact moment the same request comes back through another channel?