You have a real decision to make, so you search for a decision-making framework and get handed ten acronyms. RAPID. SPADE. WRAP. The Eisenhower matrix. A 2x2 grid with "urgent" on one axis. Each one is presented as the answer, none of them tells you which decision it was built for, and by the third tab you are running a meta-decision about which decision framework to use before you have made the actual choice.

That is the first gap every roundup leaves open. A framework is only useful once it is matched to the shape of the decision in front of you, and the shape is what nobody sorts for you. The second gap is quieter and more expensive: the frameworks all help you reach a decision and then go silent about what happens to the reasoning afterward. You pick, you move on, and six months later nobody, including you, can say why. This guide closes both. It sorts the common frameworks by the decision each one actually fits, and it covers the step every framework skips, which is making the reasoning survive contact with next year.

What is a decision-making framework?

A decision-making framework is a repeatable process for evaluating options and committing to one, designed to slow down the parts of judgment that go wrong on instinct. The good ones do three things: they reduce bias by forcing you to name your criteria before you see which option wins, they cut analysis paralysis by defining when the deliberation ends, and they make it clear who actually decides so the choice does not dissolve into a group that never quite commits.

That is the pitch, and it is real. The catch is that a framework built for a reversible solo call is the wrong tool for an irreversible one your whole team has to live with, and using the elaborate one on a small choice is its own kind of waste. So the first move is never "pick a framework." It is "read the decision."

Match the framework to the decision

Before reaching for any named method, sort the decision on two axes: how reversible is it, and who has to own it. Almost everything else follows from those two answers. A reversible call you can make alone in five minutes does not need a committee; an irreversible one your team will inherit for years should not be made in five minutes by anyone.

Amazon calls the first axis one-way versus two-way doors. In Jeff Bezos's 2015 shareholder letter, a two-way door is a decision you can walk back cheaply, so you should make it fast and let people decide without ceremony. A one-way door is expensive or impossible to reverse, so it earns the slow, deliberate treatment. Most teams get this exactly backward: they agonize over the reversible calls and rush the ones they cannot undo. That instinct has a name, Sayre's law, which observes that the fiercest arguments cluster on the smallest, safest decisions while the expensive ones slip through unexamined.

Here is the sort, with the framework each cell rewards:

The decision	Reversible?	Who owns it	Reach for	Watch out for
Small, undo-able, low stakes	Yes	You	Just decide. Set a review date and move.	Turning a two-way door into a meeting
Comparing options on known criteria	Usually	You or a pair	A weighted decision matrix or cost-benefit table	Inventing precise scores for guesses
Urgent-versus-important triage	Yes	You	The Eisenhower matrix (do, schedule, delegate, drop)	Treating "urgent" as a synonym for "important"
A team choice that needs buy-in	Sometimes	A group, one decider	RAPID or SPADE to fix roles and record the call	Consensus theater where nobody actually decides
High-stakes, hard to reverse	No	A group, one decider	WRAP plus a pre-mortem to widen options and surface risk	Confirming the option you already wanted
Time-horizon doubt ("will I regret this?")	Either	You	The 10/10/10 test: how you feel in 10 minutes, 10 months, 10 years	Over-weighting the 10-minute feeling

A few of these deserve a name and a source. Bain's RAPID framework is not really about analysis at all; it is about assigning who Recommends, Agrees, Performs, gives Input, and Decides, because the failure mode of team decisions is ownership, not information. A subtler failure survives even when ownership is crystal clear: a group agreeing to a plan no individual actually wanted, because each person assumes everyone else is in favor and no one says otherwise. WRAP, from the Heath brothers, is a debiasing checklist: Widen your options, Reality-test your assumptions, Attain distance before deciding, and Prepare to be wrong. A pre-mortem is the cheapest risk tool ever invented: before you commit, assume the decision failed and write down why, out loud, as a team. Each of these is a structured way to trace a decision's second- and third-order effects before you are living with them rather than after.

The point is not to memorize the acronyms. It is that the same decision run through the wrong-shaped framework produces a worse outcome than no framework at all, because it launders a rushed or biased call through a process that looks rigorous.

A worked example

Say your team is choosing a database for a new service. Sort it first: this is close to a one-way door (migrating later is expensive), it is high-stakes, and several engineers have to own it. That puts you in the bottom rows, not the top ones, so a five-minute Slack poll is the wrong instrument.

Run it as a decision matrix for the comparison, then WRAP the result. List the options down the side (Postgres, DynamoDB, the thing one engineer is excited about) and the criteria across the top (operational familiarity, cost at expected scale, migration cost, query shape fit). Score each, but write one sentence next to every score explaining the number, because the sentence is the part you will need later and the number is the part you will forget. Then reality-test, because the decision matrix is a map and not the territory: the "cost at scale" row is a guess, so name the scale you assumed. Then run a two-minute pre-mortem: "It is a year from now and this was the wrong call. Why?" If the answer is "the scale assumption was off by 10x," you have just found the one thing to verify before committing.

You end with a choice and, more importantly, a short record: the options, the criteria, the scores, the assumptions each score rested on, and the one risk you flagged. That record is worth more than the decision, and it is the thing every framework forgets to tell you to keep.

The step every framework skips: write the decision down

Every framework above ends at the moment you choose. None of them says what to do with the reasoning, and the reasoning is the asset. A decision without a record is a result with no explanation, which means the next person to question it (including future you) has to reconstruct the whole thing from memory or reopen it from scratch.

The fix is a lightweight decision record. It does not need a tool or a template library. It needs five fields:

Decision: what was chosen
Date: when, and by whom
Context: what forced the choice now
Options considered: including the ones rejected, and why
Assumptions: the facts this decision depends on being true
Revisit: the date or trigger that should make us re-check it

Engineering teams already formalize this for architectural choices as an architecture decision record, kept in the repository next to the code and never edited after acceptance. You do not need the ceremony of that format for a hiring call or a vendor choice, but you need its instinct: the options you rejected and the assumptions you relied on are the fields that make the record worth reading a year out. Capture it in whatever you already write in. If you journal decisions as they happen rather than reconstructing them at review time, the "why" is still accurate, because you wrote it while you still knew it.

This is also the difference between a decision that raises your team's resilience and one that quietly lowers it. A choice that lives only in the decider's head is a bus factor of one: when they leave, the decision stays in force but its reasoning walks out the door, so nobody left knows whether it still holds or why it was made.

Why the reasoning decays, and how to catch it

Diagram contrasting two decision lifecycles: without a record the assumptions drift from green to red and the decision stays trusted while quietly becoming wrong, while a recorded decision with a revisit date gets caught at review

Here is the part no decision-making framework accounts for. A decision is a bet on a set of assumptions, and assumptions expire. You chose the database because the team knew Postgres and the scale was modest. Eighteen months later the team has turned over and the scale is 50x. The decision did not change. The world underneath it did, and the record, if you even kept one, still reads exactly as confident as the day you wrote it.

This is the half-life problem that sits under every written artifact. Nobody edits a decision record to make it wrong; it goes wrong by standing still while its assumptions move. A decision that has quietly gone stale is worse than one you never wrote down, because the written one gets trusted. People cite it, build on it, and defend it long after the reasoning underneath it stopped being true.

The honest version of "use a framework and write the decision down" has a second clause: give the writing a way to tell you when it has stopped being true. That is what the Assumptions and Revisit fields in the record above are for, and it is why the strongest decision practice is not a better framework but a review habit, the decision journal that Shane Parrish popularized, where you re-read old calls against what actually happened and grade your own judgment. Frameworks improve the decision you are making now. Reviewing recorded decisions is the only thing that improves the decisions you make next.

That is the problem Scribelet is built around. A note is not a place you record a decision and hope; it is something that fights its own decay, reading the assumptions you wrote down and telling you which of your team's decisions and docs have quietly gone out of date since anyone last looked. You can try it free and keep the reasoning behind your decisions somewhere it gets re-checked instead of merely trusted.

Common ways decision frameworks fail

Even the right framework, matched to the right decision, fails in predictable ways. Most of them are not about the framework at all. The deepest one is upstream of the framework entirely: if you let a single easy-to-measure number stand in for the outcome you care about, the option that best games that number wins the decision, which is what happens when the measure becomes the target. The flip side is just as dangerous: ignoring the parts of the outcome you cannot put a number on, so the decision gets made on a partial map that leaves out what matters most.

Failure	What it looks like	The fix
Framework theater	An elaborate scoring grid built to justify the option someone already picked	Name the decision criteria before you look at the options
Analysis paralysis	The two-way door treated like a one-way door, deliberated for weeks	Sort for reversibility first; decide reversible calls fast
Consensus mush	A group "decides" but no single person owns the call	Assign the decider explicitly (this is the whole point of RAPID)
No record	A confident choice with no written reasoning	Five-field decision record, every time it matters
No review	Records kept, never re-read, so judgment never improves	A revisit date or trigger, and a habit of honoring it

The pattern underneath all five is the same. A decision-making framework is a tool for the moment of choosing, and the moment of choosing is the easy part. The value compounds in what you do before (sorting the decision to its shape) and after (recording the reasoning and revisiting it when the ground shifts). Pick the framework that fits the decision in front of you, write down why you chose what you chose, and give that writing a way to flag itself when the world it assumed has moved on. That is the whole discipline, and it outlasts any acronym.