The Anatomy of a Framework

Part IWhat a Framework Actually Is

A framework is a compression algorithm for a domain. Reality gives us too many variables to hold at once. A framework claims that a small subset of them carries most of the weight, and offers a structure for how they relate. That is the whole thing. Porter’s Five Forces claims industry profitability is mostly explained by five pressures. The scientific method claims reliable knowledge mostly comes from a particular loop of conjecture and test. Maslow’s hierarchy claims human motivation is mostly ordered by a stack of needs.

That definition already separates a framework from its neighbors, which we conflate constantly. A theory makes causal, falsifiable claims about how the world works. A model is a simplified representation you can actually run. A methodology sequences actions. A checklist enumerates without structure. A taxonomy sorts without implying the categories relate. The table below shows where the boundaries fall. Read the test-of-quality column first, because that is where the confusion does real damage. We judge frameworks by a theory’s standard. Is it true? But the right question is a tool’s standard. Does it change decisions for the better?

A framework sits between all of these. It tells you where to look. It tells you how the places you look relate to each other. It does not tell you what you will find when you get there. It is a structure for attention, and that is both the power and the danger. The power is transferability. Because it carries no case-specific conclusions, it travels. The danger is that using one feels like understanding, while quietly smuggling in assumptions about what matters and, more importantly, what does not.

A framework’s omissions are its real content. Every framework asserts two things at once: these variables matter, and everything left out matters less.

When a framework is the wrong tool entirely

A framework is one tool among five, and it wins only under specific conditions. Is the decision recurring, with known failure modes? Then a checklist beats a framework. Aviation and surgery worked this out decades ago, and richer thinking is precisely what you do not want at 3 a.m. in a cockpit. Are the key variables quantifiable, with stable relationships? Then build a model and compute the answer instead of framing it. Do you need prediction or explanation? Borrow a theory. Does the domain give fast, unambiguous feedback to a practiced individual? Firefighting, chess, trauma triage. Then trained intuition beats explicit structure, and imposing a framework only slows the expert down. A framework earns its place in what is left. Many variables. Mostly qualitative. Judgment that has to transfer across people and cases.

Part IIThe Six Elements Every Framework Contains

The diagram below shows how they fit together. The unstated ones, usually the boundary conditions and the mechanism, are where frameworks quietly fail.

1 · A scoped question and unit of analysis. What decision or understanding is this for, and about what kind of object. A firm, a product, a team, a person's week? Frameworks fail most often right here, applied with confidence to units they were never built for. Five Forces analyzes an industry. Pointed at a single product line, it produces fluent nonsense.

2 · The dimensions. The handful of variables the framework claims matter. The assertion is always double-sided. These matter, and everything left out matters less. A framework naming customer, competitor and capability is also asserting that regulation, timing and luck are second-order. Is that true? It is an empirical question. Almost nobody using the framework ever asks it.

3 · The structure. How the dimensions relate. This should mirror the domain’s actual topology, which is Part III. A large share of bad design is topology mismatch. Forcing a feedback loop into a linear pipeline. Carving a smooth continuum into four tidy quadrants, because quadrants present well on a slide.

4 · Boundary conditions. Where it applies, and where it breaks. Almost always left implicit, which is exactly how frameworks get misused. Lean-startup logic breaks where experiments are expensive and irreversible. Agile breaks where requirements genuinely are fixed. The framework is not wrong. It is out of bounds.

5 · Decision logic. What you do differently afterwards. If running a case through the framework changes no action and no belief, you do not have a tool. You have an elaborate way of restating what you already thought.

6 · A mechanism. The deepest element. Why these dimensions and not others? Five Forces works because it is microeconomics in a business suit. Bargaining power, entry barriers, substitution. A consultant’s ad-hoc two-by-two usually has nothing underneath, which is why it can never tell you when it is wrong. A framework without a mechanism can be pattern-matched. It can never be reasoned with.

It is worth practicing this on frameworks you already use. Here are three familiar ones taken apart along the six elements. Watch how much of each one’s real content sits in the two rows the popular version never mentions.

Part IIIA Field Catalog of Shapes

Structure deserves its own section, because structure is where a framework makes its strongest hidden claim. That the domain has a shape, and that this is it. Seven shapes cover most frameworks in circulation. Hybrids are common and legitimate. And a shape I have not seen yet is always possible. Each entry asserts something different about how the world works. Each lies in a characteristic way when it is misapplied.

Hybrids are not a special case. Among frameworks that survive, they are the norm. Cynefin is a tree crossed with a loop. A taxonomy of domains, and situations migrating between them, with the response strategy feeding back into which domain you are in. The Business Model Canvas is a hub with an implied flow through it. When you meet a hybrid, dissect each shape’s claim separately. The tree part of Cynefin says the domains are distinct. The loop part says they are transient. Both claims can be checked. They fail independently.

The catalog is diagnostic in both directions. When you are designing, ask which shape the domain really has before you draw anything. The honest answer is very often a loop, and loops are the shape we resist most, because they present badly. When you are reading someone else’s framework, ask what the chosen shape is asserting, and whether the domain agrees. The growth world’s shift from the AARRR funnel to flywheel models was exactly this correction. Retention feeds acquisition through referral. So the domain was a loop all along, and the funnel shape was actively hiding the most important link.

Every shape is a claim. A pipeline claims the stages do not feed back. A 2×2 claims the axes are independent. A stack claims the lower levels are prerequisites. Check the claim, not the diagram.

Part IVTwo Routes to Designing One

Porter deduced 5 forces from industrial organization economics, a body of theory about bargaining power and entry barriers, and then checked it against industries. The correction matters. There are two legitimate routes into a framework, they fail differently, and the strongest frameworks run both.

The inductive route starts from cases. Gather instances, including the failures, and extract dimensions from the variance between good and bad outcomes. Its strength is contact with reality. Its characteristic failure is overfitting. Small samples. Hindsight-labeled outcomes. Dimensions that describe your last twenty cases rather than the domain. The deductive route starts from a theory you already trust. Derive what should matter from the mechanism, then check that the derived dimensions actually discriminate among real cases. Its strength is that element six comes free. Its characteristic failure is elegance without traction. Dimensions that follow beautifully from the theory and move no real decision. Triangulation is the discipline. The dimensions both routes produce independently are the ones to trust.

Whichever route supplies the dimensions, the shared pipeline runs in six steps, and the order matters. Each step constrains the next, and each has a characteristic failure when you skip it.

Part VHow to Pressure Test One

The master question is falsifiability-in-use. Does the framework ever say no? Run live cases through it and see whether it can produce the verdicts “do not do this” or “this case does not belong here.” A framework that blesses every option it is shown is not an analytical tool. It is a rationalization engine with a diagram. Past the master question, seven tests do most of the work. Each is aimed at a specific way frameworks fake competence.

Run the battery in roughly that order, because it is sequenced cheapest to most expensive. The says-no test costs an afternoon with old cases. The inter-rater test costs two colleagues and an hour. The Goodhart test only pays off once the framework has users who did not build it. Which is also exactly when it becomes dangerous.

A framework you cannot locate the breaking point of is not robust. It is unexamined.

Part VIHow Frameworks Die

The subtlest failure mode is that frameworks shape perception, not just analysis. Once we adopt one, we stop seeing the variables it omits, and the framework quietly becomes the territory. Which is why pressure testing cannot be a one-time gate. Frameworks are instruments, and instruments drift. The world changes under them. Their users learn to game them. Their boundary conditions move without telling anyone. A framework’s life is a loop, and the loop has an exit nobody plans for.

Death, when it comes, arrives through a small number of recognizable routes. Each has a symptom you can watch for, a root cause in one of the six elements, and a repair. Which is the practical payoff of the anatomy in Part II. Knowing which element failed tells you what to fix, instead of throwing the whole tool away.

So the final discipline is periodic and uncomfortable. Go hunting for the cases where the framework pointed confidently one way and reality went the other. Treat each one not as an exception to wave off, but as data about the boundary conditions. The organizations that get lasting value from frameworks are not the ones with the best frameworks. They are the ones with a working recalibration loop.