Excess technical detail does not produce understanding

What it is

A loan applicant opens “explanation” and sees forty layers, residual connections, embedding dimensions. The words are there; the meaning is not. Excess technical detail does not produce understanding: understanding is being able to restate, in one’s own words, the layer that concerns oneself — not the thickness of the packet.

Miller stresses that explanation is selected and constrained by the audience. Dumping every intermediate from the lab is a refusal to select.

Why it happens

Working memory will not hold the symbols in an architecture diagram. People grab the first words they recognise — “neural network,” “deep learning” — and spend them in place of understanding; what they get is a label, not a mechanism. More detail, more chances to grab the wrong word, and false understanding rises with it. The sentence actually missing (“this time it used your cashflow, not your degree”) is buried under the symbols.

Detail also wears an authority costume. When people do not understand, they often do not say so; they switch to “anyway, it is professional.” Professionalism substitutes for understanding, and the next decision idles.

Studying it

Pair the same decision with a short account and a long one packed with implementation detail. Have people restate “the grounds that concern me” in their own words, and complete one application (which material to change). Independent variables: amount of detail, whether they may look back, whether the audience has a machine-learning background. Dependent variables: accuracy of restatement, correctness of application, gap between confidence and accuracy (false understanding).

Confidence up and restatement down is this entry happening. Do not use reading time as understanding.

Where it stops holding

If the audience is the engineer who must fix the model, implementation detail is the material of understanding, and this entry flips. Oversight archives need a full technical appendix; the appendix is not for the applicant to read on the spot. This entry does not treat whether detail crowds out a key sentence — that is a fight for attention, not whether detail itself produces understanding.

Applying it

• Default the account for the person concerned to a few restatable grounds. Implementation detail goes in an expandable “technical appendix,” collapsed by default.
• After writing, pass it through “can a non-practitioner restate the part that concerns them.” If not, cut, do not add.
• Do not open an account with layer counts, parameter counts, or paper titles.
• Check: cover the original and ask them to say “on what grounds it treated me this way.” If they cannot, detail did not become understanding; if what they say is “because it is deep learning,” false understanding has already formed.

Related

• Same group: L5.05.2 Transparency must serve the user's next decision · L5.05.3 Information that cannot be acted on is noise · L5.05.4 Transparency is sufficient only if the user can change the next action from it · L5.05.5 Excess detail crowds out attention needed for key information · L5.05.6 Transparency and usability are in tension; full disclosure makes the interface unusable · L5.05.7 Transparency does not necessarily produce trust; exposing complexity can lower it · L5.05.8 Different roles should receive different depths of explanation, not the same text
• Nearby: L5.01 Types of Explainability · L5.02 Local and Global Explanations · L5.08 Counterfactual Explanations
• Search terms: excess detail · understanding versus information · selected explanation