Main idea

When a document fits no slot — a translation guide born in the middle of a translation job, which is neither a source, nor a note, nor a chapter, nor a translation — two answers present themselves, and they cost the same effort.

The first names the case: translation guides go in such and such a folder. It settles the problem in seconds, it is accurate, and it leaves the architecture exactly as it found it. The next unforeseen object will call for the same decision, which will be taken the same way, and the list of exceptions will grow without any one of them being justified by the others.

The second looks for the criterion that made the decision possible: does this document produce a result, preserve knowledge, describe the current state, or govern future actions? It takes longer, it often forces you to restate a definition you thought was settled, and it makes decidable cases you haven't met yet.

Why it matters

An architecture rarely degrades through a bad initial carve-up: it degrades through an accumulation of correct exceptions. Each one is defensible in isolation, none of them cost much, and the whole ends up impossible to explain to a newcomer.

This gives an observable signal: when a filing decision is stated by naming the type of object rather than naming its function, the criterion is missing and nobody has gone looking for it.

Nuances and limits

The exception is sometimes still the right answer. An object that will appear only once doesn't warrant revising a definition for it, and hunting for a criterion at all costs produces generalisations built on a single case.

The rule also assumes you can recognise an unforeseen object as such. Many pass for variants of known objects, and get filed without anyone noticing that a slot has been forced.

Open questions

• How many occurrences of an object do you have to have seen before a criterion drawn from it is worth more than an acknowledged exception?