Most AI scoping fails because “how much should the AI do?” feels like a single question when it is really three, and a client who answers one of them in his head walks away believing he has specified the whole system. The classic wreck follows directly from this. A client says “handle my decisions,” meaning nothing more than take the labor off me, and a consultant who has not separated the three questions hears own my decisions and builds accordingly. In a demo the two systems are indistinguishable. They diverge only later, when something goes wrong and it turns out no one can say where the responsibility for it lives. The entire value of the framework below is that it forces that ambiguity into the open before anything gets built, so a client can point and say that one, not that one, at the exact place where a misunderstanding would otherwise have hidden until it was expensive.
The first cut is between delegation and relegation, and its question is who holds responsibility for the result. This is a cut about the transfer itself, not about the task being transferred. Relegation hands off execution while responsibility stays with you; delegation hands off the responsibility along with the work. The way to tell which one you are looking at is to ask where the buck stops when the thing goes wrong. If the honest answer is “the tool failed, I own that, I will go fix the tool,” then what happened was relegation, and you never left the position of the one accountable. If the answer is “the AI decided,” then it was delegation, and something uncomfortable has happened underneath the phrasing, because the machine cannot actually hold the responsibility that was passed to it. It has nowhere to put it. So delegation of responsibility to an AI is not really a transfer at all; it is an evaporation, a buck that now stops nowhere. This is the axis a client feels most sharply and names least often, because it is invisible in a demonstration and only surfaces at the first failure. It is also, almost always, the real content of the angry-client story: what he wanted was for the labor to move and the responsibility to stay, and what he got was the reverse.
The second cut is between decision and derivation, and its question is whether the task even has an answer, or whether someone has to posit one. This cut is about the nature of the work, independently of who performs it or who is accountable for it. A derivation is any task where, once the frame is fixed, the answer follows: by logic, by lookup, or by the trained weights of a model, it makes no difference. Scoring an email for spam, computing a tax, ranking vendors by price, these are derivations, and the answer is in some real sense already sitting there waiting to be surfaced. A decision is different in kind. No frame is given, and the act of committing to one is groundless, in the precise sense that nothing underneath it justifies it. Whether the brand should feel authoritative or approachable is not a question with a discoverable answer that better research would eventually reveal; it is a question someone has to legislate. The test that separates the two is simply whether enough research would settle it. If it would, the task is a derivation, and it is fully relegable no matter how much apparent judgment it seems to involve, because sophistication of pattern-matching does not change the fact that an answer was there to be found. If no amount of research converges, because the answer does not exist prior to the choice that makes it, then the task is a decision, and it has to stay with a human who owns the criteria. The reason is not that the machine would decide badly. It is that “deciding it for you” is incoherent when there is no fact of the matter, because all the phrase can actually mean is relocating whose criteria govern, and criteria that are not yours are no longer a stand-in for your judgment. They are a replacement of it.
The third cut is the finest, between generation and resonance, and its question is whether the system is proposing or selecting. Generation is the throwing-up of candidates: options, drafts, analogies, variants, as many as you like. Resonance is the involuntary registering that this particular one is right, the sense of THIS is it that you undergo rather than perform. These two come apart cleanly, and clients fuse them constantly, which matters because a machine sits on opposite sides of them. It is genuinely excellent at generation, capable of more valid candidates, faster and across more domains, than any person; that fecundity is real and worth paying for. It is structurally incapable of resonance, and structurally is the right word, not merely currently, because resonance is your own particular sensibility recognizing its own output, and a general-purpose model has no particular sensibility. It carries the averaged sensibility of everyone it was trained on, which is exactly why its output resonates faintly with all and intensely with no one; it lands in the center of the distribution, where the merely competent lives. The proof is already in your own hands every time you use such a tool: it gives you twelve options, you keep two, and the two you keep are not the two it would have scored highest. They are the two that fired in you. The picking is the tell, and the picking is yours.
The reason these have to be held as three cuts rather than collapsed into one is that they are genuinely independent, and the proof is that every combination of them occurs in practice. You can relegate a derivation, which is what a spam filter is: execution moved off you, no decision anywhere in it, and you still own the configuration. You can relegate the generation while keeping the resonance, which is what omakase is, and what good AI-assisted drafting is: the chef or the model proposes, you register which dish or which sentence lands, and the verdict stays yours. You can delegate a decision, which is the disaster case, where the machine posits the criteria and you are left holding an outcome that no one actually authored. And you can relegate all the derivations that surround a decision while keeping the decision itself, which is precisely what a well-built decision-support system does. Because the combinations are all real, the three questions cannot be the same question. Who owns the result, whether the task has a findable answer, and whether the machine is proposing or picking are three axes, and a system is only specified once all three have been answered. The conflation that causes the failure is answering one of them and believing the system is now defined.
This is why, in the engagement itself, you never ask the client how much AI he wants, since that is the very question that produces the fatal fuzzy answer. You ask three separate things instead. What should the AI be responsible for, and what stays with you, which settles where the buck lives. Which of these questions have right answers we can compute, and which are yours to define, which fences off what the machine may settle outright from what it may only ever inform. And where do you want the AI generating options versus making the final call, which makes the difference between support and making explicit rather than leaving it to be discovered. Run the angry-client case through those three and it cannot happen: he wanted the derivations and the generation around his decision moved off him, and the resonance and the responsibility kept with him, and asking the three questions separately surfaces that instead of burying it.
That gives the clean definition of the thing he actually wanted. A decision-support system derives whatever is derivable, generates the options, surfaces the forks including the ones his own knowledge would never have revealed to him, and then stops at the stake. Responsibility stays with him, resonance stays with him, and the machine handles everything upstream of the commitment. A decision-making system crosses exactly one line: it takes the resonance and the responsibility. Naming the line that precisely means you can point at it in advance, in the room, rather than discovering it in a demo at the moment the client realizes his life has been decided by something that cannot answer for it.
One caution keeps the whole thing honest, and it is the reason the framework is a set of questions rather than a form. Which register a task belongs to is frequently not obvious, and sometimes not derivable at all. “Just pick the cheapest vendor” looks epistemic, a plain derivation, until you notice it conceals a constitutive fork, because what counts as cheapest depends on what you are optimizing for, and that is a decision wearing a derivation’s clothes. So the three questions are not asked once and filed. They are what you keep asking as forks surface through the work, and locating a given task correctly on the three axes is itself the judgment being sold. It is the part that cannot be systematized, because if a form could answer it, the consultant who wrote the form would be relegable too. The framework tells you what to ask. It does not answer for you, and that refusal is not a gap in it. It is the point of it.