Consultancy as code: not a consulting report, but a decision recipe

A classic consulting report follows a familiar pattern: a comprehensive analysis, a set of insights, a few high-level recommendations and, at the end, the message “adapt these to your own context.” The report is impressive, neutral and often correct. But it does not do one thing: it does not tell the reader exactly what to do.

There is a reason for this. A large consulting report is written by many people and has to be neutral. Saying a clear “do this” means taking responsibility; so reports usually give direction but not a recipe. The reader is left alone with the analysis and has to fill the “what to do” gap themselves.

This Lab aims to do something different. Each piece here tries to be, more than an analysis, an executable decision recipe. Not an idea, but a framework. Not “this trend matters” but “here is how you build this decision.” We call this “consultancy as code”: presenting consulting not as an abstract opinion but as an applicable structure.

The right question is not “what do we think about this?” It is:

After reading this piece, does the reader know how to concretely build a decision, or did they just hear an opinion?

A report analyzes, a recipe is applied

The difference between a consulting report and a decision recipe is the difference between an analysis and a structure.

A report explains the situation: “AI investments do not produce ROI, because of these structural reasons.” This is valuable — it diagnoses the problem correctly. But it leaves the reader alone with the question “so what do I do?”

A recipe gives a structure: “to measure ROI, first build a counter-scenario; connect these three layers like this; ask these questions in this order.” A recipe turns the idea into an applicable framework. The reader learns not only what is wrong but also how to fix it.

The “Lab note” and “diagram idea” sections of every piece in this Lab exist precisely for this: to move the piece from an opinion to a recipe, from an analysis to a structure.

Being open and opinionated is an advantage

The fact that large consulting reports have to be neutral is a constraint. Ours is an advantage: we can take a clear position, prefer one approach over another, say “do not do this.”

A founder and expert team’s perspective is different from a report on which 50 people agreed. When we try something, we can honestly say what worked and what did not. We can draw the limit of an approach with a conviction that comes from our own experience. This is far more useful than a report that stays vague in the name of neutrality.

But this openness has a responsibility: being opinionated is not making unproven claims. Stating a clear opinion and promising a result we cannot guarantee are different things. Our recipe is clear, but its limits are also clear: we say openly what we guarantee and what we do not. (↔ 37 honest selling)

Being real-time: not an annual report, but a current recipe

Classic consulting publishes an annual report every six months. By the time that report comes out, some of what it describes has already changed. Technology, especially on the AI side, moves far faster than the report cycle.

A Lab’s advantage is being able to be real-time. We can write tomorrow how a method released yesterday, a new version of a tool or a new approach plugs into a decision framework. A recipe is not a frozen annual document but a structure that stays current.

This takes the content out of being a “report” and turns it into a living working notebook. The name “Lab” reflects exactly this: not a finished report, but a laboratory worked on, updated, experimented with.

A recipe is not an instruction to be applied blindly

A misunderstanding should be prevented: “consultancy as code” does not mean every reader will copy the recipe exactly. A recipe is a starting structure; it needs to be adapted to each context.

The goal is not to take over thinking, but to give thinking a solid ground. A decision framework shows how the reader should ask what in their own context; but the decision is still made by the reader, with their own data and judgement. The recipe gives the question and the structure; the context fills the answer.

This is consistent with GDP’s general stance: AI prepares, the human judges. In the same way, the recipe sets the framework, the reader makes the decision. The difference is that the reader now starts not with a blank page but with an executable structure.

Closing

A classic consulting report offers a comprehensive analysis but leaves the reader alone with the “what to do” gap — because it has to be multi-author and neutral. This Lab aims for something different: each piece is not an analysis but an executable decision recipe.

“Consultancy as code” is presenting consulting not as an opinion but as an applicable structure: a framework instead of an idea, a clear (and clearly bounded) opinion instead of neutrality, a recipe that stays current instead of an annual report. A recipe is not an instruction to be applied blindly; it gives the framework, and the reader makes the decision with their own context and judgement.

The right question is:

Are we stating an opinion on a topic, or giving an executable framework with which the reader can concretely build a decision?