Decisions
Structured decision logging with reasoning, falsification, revisit scheduling, matrix, and verdicts.
What is a Decision?
A decision log entry records why you made a choice, not just what you chose. This is the most structurally important object in Foundry after projects. Every significant choice you make gets logged with its reasoning, assumptions, risks, and a falsification condition.
Most founders make dozens of strategic decisions weekly and remember the reasoning for none of them. Six months later, they're asking "why did I choose Stripe over Paddle?" with no record to consult. The Decision Log prevents this.
What makes a good decision entry:
- The decision itself ("We're switching from monthly to annual billing")
- The reasoning ("Annual reduces churn by 40% based on competitor data")
- The assumptions ("Our audience prefers paying upfront for a discount")
- What would prove it wrong ("If annual billing drops conversion rate below 8%")
- When to revisit ("Check after 90 days of data")
Decision Fields. Complete Reference
| Field | Type | Required | Description |
|---|---|---|---|
| ------- | ------ | ---------- | ------------- |
| Title | Text | Yes | What was decided, the headline |
| Decision Made | Text | Yes | The actual choice. Be specific. |
| Context | Text | No | What prompted this decision. What situation are you in? |
| Reasoning | Text | No | Why you chose this over alternatives. Your logic chain. |
| Alternatives Considered | Text | No | What else you evaluated and why you rejected it |
| Assumptions | Text | No | What you're assuming is true that might not be |
| Risks | Text | No | What could go wrong if this decision is wrong |
| What Would Prove Wrong | Text | No | The falsification condition, concrete evidence that would overturn this |
| Revisit At | Date | No | When to revisit and evaluate this decision |
| Outcome Note | Text | No | Notes recorded during revisit (what actually happened) |
| Verdict | Enum | No | VALIDATED, PROVED_WRONG, SUPERSEDED, STILL_ACTIVE |
| Project | Reference | No | Which project this belongs to |
| Tags | Many-to-many | No | Tags for categorization |
| Matrix Scores | JSON | No | Decision comparison matrix data (for multi-option decisions) |
Decision Statuses & Verdicts
| Status | Meaning | When |
|---|---|---|
| -------- | --------- | ------ |
| ACTIVE | Current and in effect | Default on creation |
| REVISIT_PENDING | Past its revisit date | Automatic when revisitAt passes |
| SUPERSEDED | Replaced by a newer decision | Manual, when you make a new decision that overrides this one |
| ARCHIVED | No longer relevant | Manual removal |
Verdicts record what happened when you revisited:
| Verdict | Meaning |
|---|---|
| --------- | --------- |
| VALIDATED | The decision was correct. Evidence supports it. |
| PROVED_WRONG | Evidence showed the decision was wrong. You need to change course. |
| SUPERSEDED | Circumstances changed. The decision isn't wrong, it's just outdated. |
| STILL_ACTIVE | Too early to tell. Set a new revisit date. |
Verdicts and statuses are independent. A SUPERSEDED decision might have a VALIDATED verdict (it was right at the time, but circumstances changed).
Decision Matrix
For complex decisions with multiple options, Foundry provides a decision matrix, a structured comparison grid.
How it works:
1. When creating/editing a decision, open the matrix view
2. Define your criteria (e.g. "Cost", "Speed", "Quality", "Risk")
3. Weight each criterion (how important is it relative to others)
4. Define your options (e.g. "Build in-house", "Use Stripe", "Use Paddle")
5. Score each option against each criterion on a 1-10 scale
6. The matrix calculates weighted totals and highlights the recommended option
The matrix is stored as JSON and rendered visually on the decision detail page. It provides a structured framework for decisions where gut feel isn't sufficient.
Revisit Scheduling
When creating a decision, you can set a revisit date, the date when you should check back and evaluate whether the decision held up.
When the revisit date arrives:
- The decision appears on the Today page as an overdue revisit
- It triggers an OVERDUE_REVIEW recommendation
- It appears on the Decisions page with a "Revisit Pending" badge
During revisit, you:
1. Review the original reasoning and assumptions
2. Check the falsification condition, did the "what would prove wrong" happen?
3. Record an outcome note (what actually happened)
4. Assign a verdict (VALIDATED, PROVED_WRONG, SUPERSEDED, STILL_ACTIVE)
5. Optionally set a new revisit date if STILL_ACTIVE
Good revisit cadences:
- Pricing decisions: 90 days
- Hiring/partnership decisions: 30 days
- Product direction decisions: 6 months
- Technical architecture: 3-6 months
Example Scenario
You create a decision entry:
- Title: "Use Stripe over Paddle for payment processing"
- Decision Made: "Going with Stripe. Higher development effort but better control and system."
- Context: "Need to add billing to Foundry. Evaluated Stripe, Paddle, and LemonSqueezy."
- Reasoning: "Stripe has the best developer docs, handles complex billing scenarios, and most tutorials/examples use Stripe. Paddle handles EU taxes but we're US-only for now."
- Alternatives: "Paddle (simpler MoR but less control), LemonSqueezy (too limited for our needs)"
- Assumptions: "We won't need EU tax handling in the next 12 months. Stripe's complexity won't slow us down."
- Risks: "Stripe requires us to handle tax compliance ourselves if we go international."
- What Would Prove Wrong: "If we get >20% of signups from EU within 6 months, we should reconsider Paddle."
- Revisit At: 6 months from now
- Project: "Foundry Billing"
Six months later, the decision surfaces as REVISIT_PENDING. You check: only 3% of signups are EU. Verdict: VALIDATED.
FAQ
No. Only title and "decision made" are required. But the more context you provide, the more useful the decision is when you revisit it months later.
Can I link decisions to ideas or assets?
Yes. Use the Relationships system to create explicit links between decisions and other objects. Common patterns: "This decision SUPPORTS that project" or "This decision was INSPIRED_BY that insight."
Should I log every decision?
No. Log decisions that are strategic, reversible but costly, or based on assumptions you want to verify later. "Which font to use" doesn't need a log entry. "Whether to pursue enterprise sales" does.
Can I share a decision with someone?
Yes. Create a shared link from the decision detail page. The recipient gets a read-only view without needing a Foundry account. Shared links can have an expiry date.