Good Decisions

A choice should be judged first by the quality of the process, not by whether the outcome happened to work. Use Good Decisions when reviewing a choice after the result is known.

The practical version:

1. Record why the decision made sense before the outcome is known.
2. Separate process quality from outcome quality.
3. Use the outcome as feedback, not as the entire verdict.
4. Improve the decision process for the next repetition.

This replaces outcome-only judgment. A good outcome can come from a weak decision, and a bad outcome can follow from a strong decision under uncertainty.

Why Outcome Is Not Enough

Decisions are made with incomplete information. Outcomes are affected by timing, chance, changing conditions, other people, and variables the user could not control.

If the user judges only by outcome, two errors become likely:

• rewarding bad processes that got lucky,
• and abandoning good processes that met bad conditions.

The better question is: given what was known at the time, was the process reasonable?

Process Review

Use this review after meaningful decisions:

Question	Purpose
What did I know at the time?	Prevents hindsight from rewriting the situation.
What was uncertain?	Shows which variables needed information.
What downside did I protect?	Checks risk management.
What option improved my position?	Checks whether the choice created future leverage.
What would change my mind?	Separates commitment from rigidity.
What did the outcome teach me?	Turns results into process feedback.

Lightweight Red Team Checks

Use these when the decision is meaningful but does not deserve a full analysis ritual:

• What assumption would break this decision if false?
• What is the strongest case against my preferred option?
• If this fails, what is the most likely reason?
• Am I choosing this because it is good, or because it protects comfort, identity, or self-image?

These replace separate Red Team tool pages. They are small checks inside the decision process.

Relationship To Learning

This principle matters in study systems because learning outcomes are noisy.

A poor test score does not automatically mean the method was bad. A good score does not automatically mean the method was strong. The user should inspect the process:

• Was encoding deep enough?
• Was retrieval spaced and interleaved?
• Were gaps found early?
• Was the exam different from expected?
• Was the result caused by knowledge, execution, stress, or timing?

This turns performance into self-regulation instead of self-judgment.

Failure Modes

Failure	What It Looks Like	Fix
Resulting	The user judges the decision only by the final result.	Review what was known before the outcome.
Hindsight certainty	The right answer feels obvious after the fact.	Preserve pre-decision notes.
Emotional verdict	Disappointment becomes evidence that the decision was bad.	Separate feeling, process, and outcome.
No feedback loop	The outcome happens but nothing improves.	Extract one process change.
Overcorrection	One bad outcome causes a total strategy change.	Look for repeated evidence before major changes.

Related Pages

• Decision Making
• Positional Decisions and Expected Value
• Changing Decisions
• Kolbs Experiential Cycle
• Self-Regulation
• Suicidal Empathy

Sources

• Justin Sung / iCanStudy complex decision-making materials, paraphrased and synthesized in original language.

Open Questions

• Should the user keep a lightweight decision journal for high-consequence choices?