Thoughtware

The ladder of cognitive work

“The AI handles it” can conceal several distinct kinds of work. The ladder identifies them so each receives the right evidence, owner, and authority boundary.

7 min read

Cover for The ladder of cognitive work

“The AI will understand the request, decide which meals fit the week, and calculate portions.” It sounds like one capability. It is actually several kinds of work joined in one sentence, and each kind fails differently.

The calculation is either right or wrong. Understanding depends on context. Choosing a meal means weighing competing goals. Completing a purchase introduces authority. The ladder of cognitive work separates these acts because the kind of work determines what evidence, ownership, and safeguards it needs. Without that separation, a team tests the wrong thing and calls every failure an AI problem.

Helpful context: What is judgment defines the open-work boundary. Meaning, knowledge, and authority explains why the highest rung requires a separate permission decision; evaluation as engineering develops the corresponding evidence.

One request can span the whole ladder

Consider: “Plan dinners for four this week. Tuesday and Thursday are busy. Use the spinach before Wednesday, and avoid meals we ate last week.” A capable product can perform at least six different kinds of work in response.

RungThe workMeal-planning exampleWhat demonstrates quality
CalculationApply known operationsScale rice for four peopleExact expected result
PredictionEstimate an unknownEstimate spinach freshnessCalibration across cases
ClassificationAssign a fixed categoryNew request or plan correctionLabelled examples
InterpretationEstablish meaning in contextRead “busy this week” correctlyReviewer or grader acceptance
RecommendationWeigh options against goalsSelect a suitable Tuesday mealTrade-off evaluation
Consequential judgmentCommit someone to an outcomeSubmit a grocery orderExplicit authority

The rungs may occur in one flow, but they should not be treated as one uniform operation. A recommendation may rely on a prediction and calculation, and an interpretation may precede classification. The point is not to create a pipeline for its own sake; it is to retain the different contracts each act requires.

The upper rungs require more than better output

As work rises on the ladder, the system must handle more context, ambiguity, competing goals, consequence, and responsibility. The evaluation method must rise with it.

Calculation needs deterministic code and tests. Prediction needs evidence that estimates are calibrated across a distribution, not merely plausible in one example, while classification needs known labels and attention to systematic confusion. Interpretation and recommendation need graders because there may be no single expected output; the question is whether a competent reviewer accepts the reading or the trade-off.

At the final rung, quality alone is insufficient: a system may recommend a grocery order extremely well and still have no right to submit it. Consequential judgment therefore introduces authority—an explicit grant to create a commitment, spend money, or affect someone beyond the system.

The value of the ladder lies in helping a team recognise that the software is no longer performing one uniform type of work.

Introduction to Thoughtware · Ch. 2

Mislabeling creates predictable design failures

Calling candidate generation a recommendation makes the product look more helpful than it is. Ten recipes that contain spinach do not settle which one belongs on Tuesday; the household is still doing the weighing. Calling a recommendation calculation creates the opposite error: a team turns “fits a busy evening” into a single threshold, then adds exceptions as reality escapes it. Because the trade-off remains unnamed, the rules therefore grow without giving the system an explicit place to hold it.

Calling consequential judgment execution is the most serious mistake. A recommendation becomes an action merely because the system can carry it out. The missing element is not a stronger model or a higher evaluation score; it is permission.

Use the ladder before choosing the mechanism

When a feature request contains a broad verb—understand, assess, decide, handle—place that verb on the ladder before discussing prompts, retrieval, or models. The placement tells the team what it must build to know the step is working.

For the meal planner, InterpretWeek should be evaluated for fidelity to the household's meaning, whereas AssessMealPracticality should be evaluated for the defensibility of its trade-offs. Portion calculation should be exact code, and purchase completion should be gated by authority. They are different components because they are different kinds of work.

The benefit appears most sharply during an incident. A wrong quantity points to code, a missed constraint to interpretation or retrieval, a poor plan to a recommendation standard, and an unauthorised order to an authority breach. The ladder therefore turns “the AI got it wrong” into a diagnosis that can actually lead somewhere.

Read next: Where does a decision live? gives an open decision a primary home in the architecture.

The ladder is a design conversation, not a ranking

Higher rungs are not better or more sophisticated. A precise calculation is often more valuable than a clever recommendation, and an authority boundary should stop an otherwise capable system. The ladder only says that each kind of work makes a different claim and must therefore earn trust differently.

Use it during planning, not only after a failure. If a ticket says “AI handles scheduling,” ask which verbs it hides and place each on a rung. The result often reveals work that should be deterministic, a judgment that needs a contract, and an action that should remain with a person. That earlier separation prevents a demo from quietly becoming an architecture.

It also makes cross-functional review more concrete: engineering, product, and governance can discuss the same bounded claim.