Main idea

Working with an AI assumes you can verify what it produces. That verification is not an intention: it is a reading budget. Thirty or forty files in the directory dedicated to a product opportunity can be reread — in one morning, a Product Manager can open them all, spot what doesn't fit, and sign off on what they are going to defend. Several hundred interconnected notes cannot be reread, and claiming otherwise amounts to no longer verifying at all.

The number is therefore not an implementation detail, it is the parameter that decides whether the audit exists. A setup where the audit is possible in theory but impracticable in practice behaves exactly like a setup with no audit.

The consequence for design is clear: the size of the scope entrusted to an AI is chosen on the basis of human rereading capacity, before it is chosen on the basis of what it would be useful to put in it.

Why it matters

This turns a question of trust into a question of sizing. "Do we trust the model?" has no stable answer; "how many files will we actually reread before deciding?" has one, and it can be measured.

It also explains why growing an AI-assisted base can degrade its value: past the rereading threshold, every file added increases what is no longer under control.

Nuances and limits

Sampling, automated tests, or verification targeted on what carries the decision can extend the threshold without requiring an integral reread — at the price of a risk accepted rather than removed.

And the threshold is not universal: it depends on the density of the files as much as on their number, and forty dense notes can cost more than two hundred lines of facts.

Open questions

• How do you recognize that a scope has just crossed the threshold beyond which nobody rereads it?