Frame check

Most failed work is not a wrong answer. It is a right answer to the wrong question. Kimball named this the error of the third kind in 1957 and Mitroff built a practice on it. The work is rigorous, the execution is clean, and it is aimed at something that was never the problem.

Catch it before the work commits.

What you are looking for

A problem statement arrives sounding like an observation. "Onboarding is too slow." "Users are confused." "It's a race condition." None of those are observations. Someone watched something, selected part of it, decided what it meant, and concluded — and the sentence you received is the last link with the chain removed. Your job is to put the chain back and ask what else the bottom of it supports.

Two different failures produce a wrong problem, and they need different tools.

The conclusion outran the evidence. What was observed supports several readings, and one got picked without anyone noticing a choice was made. Argyris's ladder of inference is the tool here: walk back down to what a camera would have recorded.

The evidence is sound and the goal is wrong. The diagnosis holds up and is aimed at an objective nobody has examined. Climbing down the ladder will never find this, because the goal never entered as evidence. Argyris's double-loop learning is the tool: ask which governing goal makes this count as a problem at all.

Check the first. Check the second before you finish.

1. Get rung one before you say anything

The bottom rung is observable data — what a recording device would have captured, before anyone interpreted it. Go find it. An assertion about the evidence that you did not actually check is the same error you are here to catch.

Where rung one usually hides:

• A recurring bug. git log the file. Has this been "fixed" before, and what did each fix assume? Three fixes to one symptom is strong evidence the frame is wrong, not that the engineers were careless.
• An incident or failure. The raw stack trace and log lines, not the summary of them. Summaries are already rung three.
• A metric. How the dashboard actually computes it, in the query or the event definition. Metric names drift from metric definitions constantly, and a problem stated in terms of a name is often a problem about something else.
• A user complaint. The verbatim, not the paraphrase in the ticket title.
• A "slow" or "flaky" claim. The actual numbers and their distribution. "Slow" is never rung one.

When you genuinely cannot reach any of it, say so plainly and name the smallest thing that would produce it. "There is nothing at rung one here; the fastest way to get some is X" is a legitimate and useful answer. Inventing an analysis on top of an empty bottom rung is not.

2. Separate what was seen from what was concluded

Do not produce a rung-by-rung table. The canonical ladder has seven rungs and several of them do not separate cleanly under pressure, so filling in all seven yields a worksheet rather than a finding. Use it as a lens and report only the catches.

Ask, in order, and keep the answers to yourself:

• What would a camera have recorded?
• Which part of that got attended to, and what got dropped?
• What was it taken to mean?
• What was concluded, and what is being done about it?

The catch is wherever an answer is larger than the answer beneath it. That is the leap. Name it in one sentence, quoting the stated problem and the observation it actually rests on.

3. Generate frames the evidence supports

Three or so, no more. Every frame must be consistent with rung one — a fabricated alternative is worse than no alternative, because it costs the user attention and teaches them to distrust the exercise.

Always include the null frame: this is not a problem, or not one worth solving. Maybe the signal is noise, maybe the cost of the fix exceeds the cost of living with it, maybe the population you are worried about was never going to convert. Solving a non-problem is a Type III error too, and it is the one nobody checks for.

For the generative moves — changing the actor, changing the level, looking outside the boundary, bright spots, inversion, Ackoff's dissolve — read references/frame-moves.md. It also carries the canonical ladder and worked examples across a bug, a product metric, and an org problem.

4. Land a discriminating test

Argyris cared about making inferences testable, not merely visible. A frame check that ends in doubt has made the user worse off: they now have less confidence and no more information. Always land the next observation.

A good test is cheap (minutes or hours), decisive (the frames predict different results), and available (the data exists or can be got today). State which result supports which frame before it runs. Predicting in advance is what stops the result from being absorbed into whichever frame someone already preferred.

If no cheap test discriminates, say that too, and name the expensive one. That is still more useful than a list of possibilities.

5. Double-loop check

Before you finish, ask once: what goal makes this a problem? Then ask whether that goal is the right goal.

Some signals that the goal is the rotten part rather than the diagnosis — the same problem keeps recurring in different clothes, the fix always trades against something nobody will name, or the honest answer to "what happens if we just don't solve this?" is "not much."

If the goal survives, do not mention it. If it does not, that is the finding, and it outranks everything above it.

Output

STATED   <the problem as given, quoted>

LEAP     <what rung one actually is, and where the statement outran it>

FRAMES   A. <frame> — requires <assumption>
         B. <frame> — requires <assumption>
         C. <null frame, when live>

TEST     <the observation> — <cost>.
         <result X> supports A; <result Y> supports B.

Add a GOAL block only when the double-loop check fires. Keep the whole thing short enough to read in under a minute; this is a redirect, not a report.

Asking questions

Analyze first, then ask only what is load-bearing. A question is load-bearing when the two answers lead to different work — if both roads end at the same next step, the question is curiosity and it costs the user time.

Cap it at three. Give your best guess alongside each one so the user can correct you rather than compose an essay.

When to stand down

Say the frame holds, in two sentences, and stop. Do it when rung one is present, the stated problem is a fair reading of it, and the alternatives you considered are ruled out by the evidence.

Manufacturing a reframe when the frame is sound is itself an error of the third kind — you would be solving a framing problem that does not exist. The skill is worth having only if it can return "this is right, go" and mean it.

What goes wrong

• Worksheet theater. Seven labelled rungs, no finding. The rungs are for you.
• Doubt with no exit. Alternatives listed, no test named, user now stuck.
• Invented frames. Alternatives rung one does not actually support.
• Hobby-horse reframing. Every problem turns out to be the thing you already wanted to talk about. Frames must come from the evidence, not from you.
• Firing on small tasks. A well-specified two-hour job does not need this. The cost of a frame check should scale with the cost of being wrong.