The universal decision process is a myth
You have been sold a single model for making decisions. Gather information, list options, weigh pros and cons, choose the best one. It shows up in business school curricula, self-help books, and corporate training decks. It sounds reasonable. It is also wrong — not because it never works, but because it treats all decisions as the same kind of problem.
They are not.
Choosing which candidate to hire, choosing which database to adopt, choosing whether to pivot your product, choosing where to eat lunch — these are structurally different problems. They differ in reversibility, time horizon, information availability, number of stakeholders, and cost of being wrong. Applying the same generic deliberation process to all of them guarantees one of two failures: you either over-invest in trivial decisions (spending forty-five minutes on a lunch choice) or under-invest in consequential ones (choosing a technology stack with the same speed you choose a restaurant).
The fix is not a better universal framework. The fix is abandoning the idea of a universal framework entirely and building one specific framework for each type of decision you encounter repeatedly.
Munger's latticework: the original argument for framework specialization
Charlie Munger made the case for this more clearly than anyone. In his 1994 address at USC Business School — later expanded across decades of Berkshire Hathaway shareholder meetings — Munger argued that effective thinking requires what he called a latticework of mental models drawn from multiple disciplines. Psychology, economics, physics, biology, engineering, statistics. Each discipline offers models that work in specific domains and fail in others.
His most famous warning was about the failure mode of using a single model: "To a man with a hammer, every problem looks like a nail." Munger was not making a vague plea for broad thinking. He was making a specific structural claim: different types of problems require different types of models, and the person who only has one model will distort every problem to fit it.
He estimated that 80 to 90 key models from the major fields would handle roughly 90% of life's challenges. The power wasn't in any individual model — it was in the ability to match the right model to the right situation. An investment decision that hinges on incentive structures needs a different analytical lens than one that hinges on network effects or mean reversion. Using the same analytical template for both produces confident but wrong answers.
This principle extends directly to personal decision-making. Your hiring decisions, your technical architecture decisions, your financial decisions, your relationship decisions — each of these is a distinct domain with its own structural properties. Each deserves its own framework.
Why one framework per type reduces cognitive load
John Sweller's cognitive load theory (1988) explains the mechanism. Your working memory can hold roughly four items simultaneously. Every decision consumes working memory: evaluating options, weighting criteria, imagining outcomes, managing uncertainty. When you approach a decision without a pre-built framework, you are simultaneously deciding how to decide and what to decide. Both tasks compete for the same limited cognitive workspace.
Sweller's research showed that once learners acquire a schema — a structured mental pattern — they can execute complex procedures with dramatically less cognitive effort. The schema automates the how, freeing working memory for the what. This is the same mechanism that lets an experienced chess player see a board position and recognize a pattern instead of calculating every possible move from scratch.
A decision framework is a decision-making schema. When you have a specific framework for hiring decisions — including what criteria matter, in what sequence to evaluate them, what disqualifies a candidate, and what timeline to use — you don't burn cognitive resources figuring out your process each time you hire. The process is settled. Your full working memory is available for evaluating the specific candidate in front of you.
Without that schema, every decision of every type becomes a novel problem-solving exercise. That is extraordinarily expensive. It's the cognitive equivalent of rebuilding your tooling from scratch for every project instead of maintaining a well-organized workshop.
Gigerenzer's adaptive toolbox: the right heuristic for the right environment
Gerd Gigerenzer, the psychologist who spent decades studying how people actually make decisions in the real world, formalized this idea as the adaptive toolbox. In Simple Heuristics That Make Us Smart (1999) and subsequent work, Gigerenzer and his ABC Research Group argued that rational decision-making is not about applying one optimization algorithm to everything. It is about having a repertoire of simple, specialized heuristics — and the ability to select the right one for the current environment.
Gigerenzer's key insight was counterintuitive: specialized simple rules often outperform complex general-purpose analysis. In environments with high uncertainty and limited data, a fast-and-frugal heuristic that uses one or two cues can be more accurate than a regression model that uses twenty variables. Not because the heuristic is smarter, but because it is adapted to the structure of that specific environment.
He called this ecological rationality — the match between a decision strategy and the structure of the environment where it is applied. A heuristic is rational not in the abstract, but relative to its domain. The "take the best" heuristic (choose based on the single most valid cue) outperforms weighted-additive models in certain environments. It fails in others. The point is not that any one heuristic is universally superior. The point is that having the right heuristic for the right environment is what produces good decisions.
This is exactly what a framework-per-type approach gives you. Each framework is a heuristic matched to the structural properties of a specific decision domain. Your hiring framework is ecologically rational for hiring decisions. Your architecture framework is ecologically rational for technology choices. Neither would work well if swapped.
Klein's recognition-primed decisions: how experts actually choose
Gary Klein's research on naturalistic decision-making provides the empirical foundation. Starting in the 1980s, Klein studied how experienced firefighters, military commanders, and intensive care nurses make decisions under time pressure and uncertainty. He expected to find them comparing options systematically. What he found was the opposite.
Experienced decision-makers almost never compared options. In Klein's studies of fireground commanders, he found "virtually no instances of the standard laboratory paradigm" — the rational-choice model of generating options and comparing them. Instead, experts used recognition-primed decision-making (RPD): they recognized the type of situation they were in, matched it to a pattern from experience, mentally simulated a single course of action, and executed it. If the simulation revealed problems, they modified or moved to the next option serially — never comparing all options in parallel.
This is framework-per-type thinking in its most refined form. The experienced firefighter doesn't have one generic "how to make decisions under pressure" process. They have pattern libraries organized by situation type. A backdraft scenario triggers one set of responses. A structural collapse triggers another. A chemical hazard triggers a third. Each pattern is a specialized framework, built through experience and refined through feedback.
Klein's work shows that expertise itself is the progressive building of type-specific decision frameworks. Novices deliberate generically. Experts recognize and act within domain-specific patterns. The path from one to the other is exactly what this lesson describes: building a specific framework for each recurring decision type.
Bezos's Type 1 and Type 2: decision types demand different processes
Jeff Bezos operationalized this at Amazon's scale. In his 2015 letter to shareholders, Bezos distinguished between Type 1 decisions (irreversible, one-way doors) and Type 2 decisions (reversible, two-way doors). His argument was not merely that some decisions matter more than others. It was that each type demands a fundamentally different decision process.
Type 1 decisions — shutting down a product line, signing a ten-year lease, making a key hire — require slow, deliberate, high-consultation processes. You need thorough analysis because you cannot easily undo the outcome. Type 2 decisions — choosing a feature to A/B test, selecting a meeting time, picking a vendor for a small project — should be made quickly by individuals or small groups, with minimal process overhead, because the cost of reversal is low.
Bezos's sharpest observation was about the failure mode: "As organizations get larger, there seems to be a tendency to use the heavyweight Type 1 decision-making process on most decisions, including many Type 2 decisions." The result is slowness, unthoughtful risk aversion, and failure to experiment. The same framework applied to both types produces organizational paralysis.
This is the organizational version of the individual error. When you use one decision process for everything, you either apply heavyweight analysis to lightweight decisions (wasting time and energy) or apply lightweight analysis to heavyweight decisions (creating avoidable catastrophes). The framework must match the type.
The AI parallel: specialized models outperform general-purpose ones
The same structural principle has emerged independently in artificial intelligence. The dominant trend in AI architecture from 2023 to 2026 has been the movement from monolithic general-purpose models toward specialized routing systems — architectures that classify the type of task and route it to a domain-specific model optimized for that task type.
The Mixture of Experts (MoE) architecture embodies this directly. Unlike dense models that activate all parameters for every input, MoE models activate only a subset of specialized "expert" modules depending on the task. A coding question routes to the code expert. A medical question routes to the medical expert. A creative writing prompt routes to the language generation expert. The routing layer — the mechanism that identifies the type and selects the appropriate expert — is itself a critical component.
Research from domain-specific AI systems consistently shows that specialized models trained on narrow domains outperform general-purpose models of the same size on tasks within that domain. A 2024 paper on Mixture of Domain Expert Models (MoDEM) demonstrated that combining domain routing with fine-tuned specialist models significantly outperformed base models, challenging the assumption that bigger general-purpose models are always better.
The parallel to human decision-making is direct. Your mind is the routing layer. Each decision framework is a specialized expert. The quality of your decisions depends not just on the quality of any individual framework but on your ability to recognize the decision type and route to the appropriate framework — exactly as a Mixture of Experts routes to the appropriate specialist module.
If you try to handle every decision with one general-purpose process, you are running a dense model when a mixture of experts would outperform it. You are paying the full computational cost of generic deliberation when a specialized framework would produce a better answer faster.
How to build your framework library
The construction is straightforward, even if the execution requires discipline.
Step 1: Identify your recurring decision types. Look at the past thirty days. What decisions did you make? Group them by type, not by topic. "Hire vs. don't hire" and "promote vs. don't promote" are both people decisions. "Adopt this technology" and "deprecate that system" are both architecture decisions. "Spend on this tool" and "renew this contract" are both purchasing decisions. Most people find they have six to ten recurring types that account for the vast majority of their decisions.
Step 2: For each type, define the structural properties. What makes this type different from others? Consider: reversibility (can you undo it?), time horizon (when do consequences materialize?), information completeness (how much can you know before deciding?), stakeholder impact (who is affected?), and cost of delay (what happens if you wait?). These properties determine what kind of framework this type requires.
Step 3: Build the framework. Each framework should include:
- Criteria — the 3-5 factors that actually matter for this decision type (not everything that could matter, but what reliably separates good outcomes from bad ones)
- Sequence — in what order to evaluate (screen for disqualifiers first, then optimize among remaining options)
- Time budget — how long this type of decision should take (30 seconds for lunch, 30 minutes for a tool purchase, 3 weeks for a key hire)
- Kill conditions — what automatically eliminates an option (a technology with no active maintainers, a candidate who misrepresents their background)
- Decision rights — who decides, and who is consulted
Step 4: Use the framework, then update it. A framework you built theoretically will be wrong in practice. The first three times you use it, note where it helps and where it breaks. Revise. The fourth time will be better. The tenth time, it will feel automatic. That's schema acquisition in action — Sweller's cognitive load theory working for you.
The framework library is a living system
This is not a one-time exercise. Your decision types evolve. You enter new roles, face new domains, encounter types you haven't seen before. When you notice yourself struggling with a decision that doesn't fit any existing framework, that's the signal: you've found a new type. Build a framework for it.
Over time, your library compounds. Each framework gets refined through use. Each refinement reduces the cognitive cost of that decision type further. The person with twenty well-calibrated frameworks makes better decisions with less effort than the person with one sophisticated general-purpose process, for the same reason that a workshop with twenty specialized tools produces better work than a workshop with one adjustable wrench.
Your decision quality is not limited by your intelligence. It is limited by whether you have the right framework for the type of decision in front of you. Build the library. Match the framework to the type. Let the specificity do the work.