Main idea

A filing level is justified by the decision it feeds, not by the granularity it adds. In a customer feedback repository, the business stake feeds strategy and segment arbitrations; the work action aimed at feeds discovery; the expected capability feeds the roadmap and design; the situated irritation feeds design and the backlog. Each has a recipient and a moment.

The test reads backwards, and it is severe: a level whose reader you cannot name, nor what it helps them settle, is a decorative level. It will be filled in as long as someone watches the entries, then abandoned — not because it is wrong, but because nothing depends on it.

Symmetrically, removing a level doesn't only remove a label: it takes away the material of a decision. Filing all feedback at the feature level deprives the strategic discussion of its signals, and the decision keeps being taken — without them.

The same rule applies to the kinds of gap noted on a product, and it is what justifies keeping five rather than one: a defect becomes a bug to investigate, a missing piece a backlog item, an inconsistency debt to arbitrate, a friction design debt, a wish an opportunity. Five destinations, five bodies. A typology without that property — "major", "minor" — would classify without triggering anything.

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

Why it matters

This gives a criterion for opening or closing a level, where the discussion usually turns on the correctness of the breakdown. The question is no longer "does this level really exist?" but "which decision would be better taken if it did?".

It also explains why centralizing isn't enough. A well-filled base in which no level is wired to a moment of arbitration produces neatly filed verbatims and decisions that keep being taken elsewhere.

Nuances and limits

The link between a level and its decision isn't fixed: a level that is useless in a team of ten becomes decisive when several teams share out the roadmap. The criterion is replayed when the organization changes, it isn't posed once.

And a level can serve several decisions at once — the expected capability feeds both design and the answer to a tender. The test asks for at least one identifiable decision, not an exclusive match.

Open questions

• Should a level whose decision is taken by someone outside the product team stay in the same repository?