The Work the Checklist Cannot See

A design system can specify spacing, typography, component states, and responsive breakpoints. It cannot fully explain why one sidebar feels stable across five workspaces while another makes the product feel assembled from unrelated pages.

I learned this while trying to make an AI-assisted productivity application consistent. The obvious work was codifiable: share components, align controls, standardize navigation, and remove duplicated patterns. The difficult work appeared in exceptions. A workspace needed a different emphasis because its primary action changed. A mobile control needed to move because the desktop hierarchy did not survive a narrow screen. A technically reusable component carried the wrong visual weight in one context.

The decisions were not mystical. They were grounded in cases. But the cases could not be compressed into one rule without losing the judgment that made the rule useful.

That residue is the untranslatable part of work: knowledge that can be demonstrated, compared, and cultivated, yet resists complete conversion into instructions.

Rules describe the center; craft lives near the edges

Procedures are most reliable when the environment is stable and the relevant variables are known. Craft becomes visible when a case resembles the rule but differs in one consequential way.

A novice often treats the rule as the work. An experienced practitioner notices when applying it literally would damage the outcome.

This does not mean expertise is mysterious intuition. Much of it consists of remembered cases, perceptual distinctions, and compressed causal knowledge. The expert sees a pattern sooner because prior consequences have made certain signals salient.

Work on tacit knowledge and organizational learning is useful background here. It describes forms of knowledge that are difficult to articulate completely and are often transferred through shared practice, observation, and repeated interaction. It does not prove that AI cannot represent any particular skill. The stronger claim would be unsupported. The practical claim is narrower: a specification usually omits some of the case history that taught a person when the specification should bend.

Automation can remove the practice that preserves recovery

Lisanne Bainbridge’s “Ironies of Automation” remains relevant because automation can leave people responsible for abnormal situations while reducing their routine involvement in the process. When the system fails, the human may be asked to intervene after losing the continual contact that built situational understanding.

Generative AI creates a related risk in knowledge work. It can produce the standard case so well that a person encounters fewer of the near-misses from which judgment develops. The output improves while the operator’s ability to detect a wrong-but-plausible variation remains uncertain.

The danger is not automatic completion itself. It is removing both execution and observation. A person who delegates a task but reviews the assumptions, tests edge cases, and records failures may still deepen judgment. A person who accepts fluent output without contact with the underlying cases may inherit responsibility without the perception needed to exercise it.

Build an exception library

Instead of trying to encode every lesson as another universal rule, I use an exception record. It keeps the case attached to the judgment.

Field	Record
Situation	What was being attempted, for whom, and under which constraints?
Default rule	What normal procedure or design principle applied?
Anomaly	Which detail made the default unsafe, misleading, or ineffective?
Decision	What was changed?
Consequence	What improved, failed, or remained uncertain?
Reuse condition	In what future situation should this case be recalled?

Worked example: the shared sidebar

Situation: Several product workspaces used the same navigation shell.

Default rule: Reuse one component to preserve consistency and reduce maintenance cost.

Anomaly: The workspaces did not have identical primary actions, and the mobile layout changed which controls remained visible.

Decision: Keep the structural shell shared while allowing a small, typed configuration for workspace-specific labels and actions. Do not fork the entire component.

Consequence: The interface remained coherent without pretending that every workspace had the same hierarchy.

Reuse condition: Apply this pattern when structure is stable but the task context changes a limited set of visible choices.

The record contains more training value than “prefer reusable components.” It shows where reuse stopped and why.

Let AI propose rules; require cases

AI is good at turning scattered examples into candidate principles. That can accelerate documentation. The principle should remain provisional until it survives the cases that produced it.

A useful review asks:

• Which examples support this rule?
• Which example almost violates it?
• What variable changed the decision?
• What failure would reveal that the rule was applied too broadly?
• Who has seen the consequences directly?

This process gives the model a productive role without pretending that verbal compression equals operational mastery.

It also improves prompts. Instead of asking for “best practices,” provide two successful cases and one failure. Ask the system to identify the decision boundary. The response may still be wrong, but it becomes easier to test because it is attached to observable differences.

Deliberate practice needs feedback on perception

Research on deliberate practice emphasizes focused work, feedback, and tasks designed to improve performance. It does not imply that repetition alone creates expertise. Repeating a task with no information about errors can stabilize bad habits.

For tacit work, feedback must address what the practitioner noticed, not only whether the final artifact passed. After a review, ask:

• Which signal led you to inspect this part?
• What alternative did you reject?
• At what point did the standard procedure stop fitting?
• What would a beginner likely miss?

These questions turn an expert’s action into a partial teaching artifact. The result will never capture everything, but partial articulation is better than romanticizing intuition.

Some knowledge should become explicit

An argument for tacit knowledge can become an excuse for gatekeeping. “You will understand with experience” is sometimes true and often lazy.

Safety rules, accessibility requirements, data-handling constraints, and repeatable operating procedures should be documented wherever possible. People should not be forced to acquire preventable injuries or social humiliation as tuition. Experts have a responsibility to translate what can be translated.

The remaining residue should be demonstrated through supervised cases, simulations, reviews, and postmortems. Calling knowledge tacit should increase the obligation to design better exposure, not end the conversation.

Preserve contact with consequences

The most valuable part of work is often not the visible motion. It is the changing sensitivity to what might go wrong.

AI can reduce routine labor and make high-quality examples widely available. Those are real gains. To retain craft, the workflow must preserve contact with consequences: review the edge case, inspect the failure, compare alternatives, and record why the rule bent.

A prompt can translate an instruction. It cannot automatically supply the history that made one detail matter more than another. That history has to remain somewhere in the practice.

The goal is not to protect inefficiency. It is to make sure that when the standard answer fails, someone still knows what to look at next.