The Anatomy of a Framework

Part IWhat a Framework Actually Is

At bottom, a framework is a compression algorithm for a domain. Reality presents too many variables to hold at once; a framework is a claim that a small subset of those variables carries most of the explanatory or decision-relevant weight, together with a structure for how they relate. That is the whole thing. Porter's Five Forces is a claim that industry profitability is mostly explained by five pressures. The scientific method is a claim that reliable knowledge mostly emerges from a particular loop of conjecture and test. Maslow's hierarchy is a claim that human motivation is mostly ordered by a stack of needs.

This definition immediately separates a framework from its neighbors — terms people constantly conflate. A theory makes causal, falsifiable claims about how the world works. A model is a simplified, often formal representation you can run. A methodology sequences actions; a checklist enumerates without structure; a taxonomy sorts without implying relationships between the categories. The table below is the fastest way to see where the boundaries fall — read the "test of quality" column especially, because that is where the confusion does real damage: people routinely judge frameworks by a theory's standard (is it true?) when 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 and how the places you look relate to each other — but not what you will find when you get there. It is a structure for attention. That is both its power and its danger. The power is transferability: because a framework carries no case-specific conclusions, it travels across situations. The danger is that using one feels like understanding while quietly smuggling in unexamined assumptions about what matters and, more importantly, what doesn't.

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

An earlier edition of this essay skipped a question its own method demands: it told you how to build frameworks without ever saying when not to. That is a says-no failure at the top level — the same flaw it accuses bad frameworks of. So, before the anatomy: a framework is one tool among five, and it wins only under specific conditions. If the decision is recurring and the failure modes are known, a checklist beats a framework — aviation and surgery figured this out decades ago, and "richer thinking" is exactly what you don't want at 3 a.m. in a cockpit. If the key variables are quantifiable and their relationships are stable, build a model and compute the answer instead of framing it. If what you need is prediction or explanation, borrow a theory. And if the domain gives fast, unambiguous feedback to a practiced individual — firefighting, chess, trauma triage — trained intuition outperforms explicit structure, and imposing a framework slows the expert down. A framework earns its place in the remaining territory: many variables, mostly qualitative, judgment that must transfer across people and cases.

Part IIThe Six Elements Every Framework Contains

Dissect any framework that has survived contact with reality and you find the same six elements, whether or not its author stated them. 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 implicit assertion is always double-sided: these matter, and everything omitted matters less. A framework that names customer, competitor, and capability is also asserting that regulation, timing, and luck are second-order. Whether that's true is an empirical question most framework users never ask.

3 · The structure. How the dimensions relate — and this should mirror the domain's actual topology, the subject of Part III. A large share of bad framework design is topology mismatch: forcing a feedback-loop reality into a linear pipeline, or carving a smooth continuum into four tidy quadrants because quadrants present well.

4 · Boundary conditions. Where it applies and where it breaks. These are almost always left implicit, which is precisely how frameworks get misused. Lean-startup logic breaks where experiments are expensive and irreversible; agile breaks where requirements genuinely are fixed. The framework isn't wrong — it's out of bounds.

5 · Decision logic. What you do differently after using it. If running a case through the framework changes no downstream action and no belief, the framework is decoration — 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 — bargaining power, entry barriers, substitution — wearing a business suit. A consultant's ad-hoc two-by-two usually has no mechanism underneath, which is why it cannot tell you when it is wrong. A framework without a mechanism can only ever be pattern-matched, never reasoned with.

The dissection habit is worth practicing on frameworks you already use. Here are three familiar ones taken apart along the six elements — notice how much of each framework's real content sits in the two rows their popular versions never mention:

Part IIIA Field Catalog of Shapes

The structure element 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. A previous edition of this essay claimed there were exactly five shapes — and then dissected Cynefin, whose structure ("a taxonomy with movement between domains") fit none of them. That is an out-of-sample failure inside the essay's own pages, and it earns the honest correction: this is a field catalog, not a closed taxonomy. Seven shapes cover most frameworks in circulation; hybrids are common and legitimate; and a shape you haven't seen yet is always possible. Each entry asserts something different about how the world works, and each lies in a characteristic way when misapplied.

Hybrids are not a special case; they are the norm among frameworks that survive. Cynefin is a tree (a taxonomy of domains) crossed with a loop (situations migrate between them, and the response strategy feeds back into which domain you're 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 asserts the domains are distinct; the loop part asserts they're transient. Both claims can be checked, and they fail independently.

The practical use of this catalog is diagnostic, in both directions. When designing, ask which shape the domain really has before drawing anything — the honest answer is often "a loop," and loops are the shape people most resist because they present badly on slides. When consuming 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 stages don't feed back. A 2×2 claims the axes are independent. A stack claims lower levels are prerequisites. Check the claim, not the diagram.

Part IVTwo Routes to Designing One

An earlier edition of this essay taught exactly one design method — induce dimensions from cases — while holding up Five Forces as the exemplar of good design. But Five Forces was not induced from cases at all: Porter deduced it from industrial-organization economics, a body of theory about bargaining power and entry barriers, and then checked it against industries. The essay's procedure contradicted its own favorite example. The correction matters, because 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 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, and 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 a built-in mechanism (element six comes free); its characteristic failure is elegance without traction — dimensions that follow beautifully from the theory and don't move any real decision. Triangulation is the discipline: dimensions that 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 skipped.

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 check whether it can produce the verdicts "don't do this" or "this case doesn't fit here." A framework that blesses every option it is shown is not an analytical tool; it is a rationalization engine with a diagram. Beyond the master question, seven tests do most of the work — each aimed at a specific way frameworks fake competence.

Run the battery in roughly that order — it is sequenced from 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 didn't 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 adopted, you stop seeing the variables they omit — the framework becomes the territory. This 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, and their boundary conditions silently move. A framework's life is a loop, and the loop has an exit no one 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 from 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: actively hunt for 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.

Part VIIThis Essay, Tested Against Itself

An essay that hands you a pressure-test battery and doesn't run it on itself is asking you to do something it won't. So: the essay is itself a framework — six elements, seven-shape catalog, two-route pipeline, eight tests — and here is how it scores against its own battery. This is also a changelog: every revision in this edition came out of a failed test, which is the recalibration loop of Figure 4 running on its own author.

CodaOne Caveat on This Essay's Own Framing

In the spirit of the exercise, this essay should disclose its own optimization target: everything above is tuned for decision-usefulness — frameworks as tools that change what a practitioner does next. The strongest alternative lens is the academic one, which treats frameworks as precursors to theory and judges them by whether they generate testable hypotheses rather than better decisions. If your context is research rather than practice, weight the mechanism element and the falsifiability tests more heavily, and the compression-for-usability criteria less. The anatomy is the same; the grading rubric is not.

And that disclosure is itself the final lesson. Every framework — including a framework about frameworks — is a bet about what matters. The honest ones state the bet, publish their test results, and revise in public, the way Part VII tries to. The dangerous ones let you forget a bet was ever placed.