Facts vs Preferences: What Counts as Evidence

By Better Wise

Where this sits: sorting what you already collected

In the last lesson you named the decision, ranked your goals, and wrote success criteria you could actually test. That gave you a container. This lesson fills it with inputs, and the key move is refusing to treat every input the same. A cost figure and a strong opinion are not the same kind of thing, and mixing them is where most decision documents quietly fall apart.

By the end of this lesson you can:

• Sort an input into one of three buckets: fact, preference, or assumption
• Rate any source on reliability and relevance, as two separate questions
• Spot a preference wearing a fact costume
• Turn your riskiest assumption into a cheap test with a deadline

Three buckets, three different jobs

Every input on your decision table belongs in exactly one bucket.

Facts reduce uncertainty. Preferences decide what you are optimizing for. Assumptions are the debt you are carrying until you check them. None is illegitimate, but each needs a different response.

flowchart TD
  A["Input on the decision table"] --> B{"Can an independent check prove it wrong?"}
  B -- Yes --> F["📊<br/>Fact"]
  B -- No --> C{"Does it express what someone values or wants?"}
  C -- Yes --> P["❤️<br/>Preference"]
  C -- No --> S["❓<br/>Assumption"]

The most common failure is a preference in a fact costume. "The team needs better reporting" sounds like a finding. Usually it is a want, and the honest version is "Priya wants reporting that does not require a manual export." One version can be checked. The other can only be ranked against other wants.

Note what a fact is not. _____. Popularity is not a check. Confidence is not a check. A fact that cannot be traced to a source and a date is really an assumption.

Exercise 1: Sort six inputs from the project thread

Your project is a decision brief on whether to move your team's reporting from spreadsheets to a paid BI tool. Sort each input and say what you would do with it next.

1. Finance: "Current licence cost is $240 per seat per year, 14 seats."
2. A colleague: "Spreadsheets are fine, people just need to be more careful."
3. Your own note: "Most of the team will need less than a day of training."
4. Vendor case study: "Teams like ours cut reporting time by 40 percent."
5. Your manager: "Whatever we pick, it has to be live before the Q3 board pack."
6. Team survey: "9 of 12 respondents said exports break at least once a month."

Answer guidance for Exercise 1

1. Fact. Verifiable with the contract. Date it and keep it as anchor evidence.
2. Preference (and a vague one). Ask for the owner and the specific preference: which part of the current workflow does this person want protected?
3. Assumption. Load-bearing if training hours could kill the timeline. Test it with a 30-minute pilot on one real report.
4. Fact about someone else, relevant only partly. Real, but the context may differ. Treat it as a weak signal until you find your own comparable case.
5. Constraint, effectively a fact about the deadline. It is not up for debate, so it moves to your constraints list, not your evidence list.
6. Fact, with a caveat. Self-reported and from a small sample, so note the sample size alongside the number.

Notice how many "facts" arrived with a caveat. That is normal. Sorting is about the type of claim, not about pretending you have perfect data.

Reliability and relevance are two separate questions

Two inputs can both be true and still deserve wildly different weight. Score them on two axes.

• _____ asks whether this source tends to be right when the answer can be checked. Track record, incentives, closeness to the primary data.
• _____ asks whether it speaks to this decision, in this context, at this time.

Two traps live in this grid. A vivid anecdote from a colleague sits low on reliability and high on relevance, which makes it feel like evidence. A confident expert from a very different company sits high on reliability and low on relevance, which makes it feel authoritative. Neither should settle the decision.

Exercise 2: Score sources, then pay down one assumption

For input 4 (the vendor case study) and input 6 (the team survey), write one line each on reliability, one line on relevance, and a verdict: anchor, context, lead, or drop. Then take input 3 and convert it into a test with a deadline.

Answer guidance for Exercise 2

Input 4, vendor case study. Reliability: moderate, the vendor benefits from a good number. Relevance: moderate to low, their baseline may not match yours. Verdict: lead. Ask the vendor for the raw baseline, or find a comparable team you can question directly.

Input 6, team survey. Reliability: moderate, self-reported and small sample, but it measures your own team. Relevance: high, it is your workflow. Verdict: anchor, with the caveat written next to the number.

Input 3, the training assumption. Test: one team member rebuilds a real monthly report in the tool while you time it. Deadline: end of this week, before the vendor demo. If it takes over two hours, the assumption is false and the timeline goal needs revisiting.

A load-bearing assumption is one where _____. Test those first. Assumptions that would not change your choice can wait.

Rules of thumb for keeping evidence honest

• If you cannot name the check, it is not a fact yet. "Everyone knows" is not a check.
• Write preferences with an owner attached: "Priya prefers X" beats "X is needed."
• Before you gather more evidence, write down what would change your mind. Otherwise you will collect confirmation and call it research.
• One strong, close, dated source beats five weak ones. Do not average anecdotes.
• Date every fact. A fact with no date drifts into an assumption.
• When reliability and relevance disagree, ask which one this decision actually turns on.
• Keep a visible assumption list with an owner and a test date. Untested assumptions are how good briefs become bad decisions.

Wrap-up

• Every input is a fact, a preference, or an assumption, and each needs a different response.
• Reliability and relevance are separate scores. High on one does not rescue low on the other.
• Test load-bearing assumptions first, cheaply, with a deadline.
• A decision brief gets stronger when the assumptions are visible, not when they are removed.

Next up is the checkpoint, where you will frame a decision and sort its inputs end to end, using exactly the buckets and scoring you just practiced.

Front: What makes a claim a fact? Back: An independent check can confirm or refute it, and you can name that check.

Front: What is a preference? Back: A value, taste, or priority held by a person that can be ranked but not proven true or false.

Front: What is an assumption? Back: A claim you are treating as true without having checked it yet.

Front: What is the quickest triage question for a fact? Back: Can an independent check prove this wrong, and who would run it?

Front: How do you spot a preference disguised as a fact? Back: It states a want as a property of the world, such as 'the team needs better reporting'.

Front: What does reliability measure? Back: Whether the source tends to be right, based on track record, incentives, and closeness to the data.

Front: What does relevance measure? Back: Whether the source speaks to this decision, in this context, at this time.

Front: How should you treat a vivid anecdote from a colleague? Back: Low reliability, high relevance: a lead to test, not proof.

Front: How should you treat a confident expert from a very different company? Back: High reliability, low relevance: useful context, not the deciding input.

Front: What makes an assumption load-bearing? Back: If it were false, the decision would flip.

Front: Why should every fact carry a date? Back: An undated fact drifts into an assumption as conditions change.

Front: What should you write before gathering more evidence? Back: What would change your mind, so you do not just collect confirmation.

Front: What do the four cells of the reliability-relevance grid recommend? Back: Anchor, context, lead to test, or drop.