How the Decision Lab works
The Decision Lab compares specific ways of reaching the same objective. It does not predict success, rank companies or replace legal, clinical or financial advice. Everything below applies to every decision on this site.
What is compared
Each decision has one current approach (the baseline), at least two alternative paths and a smaller reversible pilot. A path is a list of steps; each step has a role, a start week, a duration or a weekly cadence, and quantities of hours and cash. You can also combine steps from several paths into a custom path; every step keeps a note of where it came from.
How quantities are calculated
A step's hours or cash are a constant multiplied by named inputs — for example 1 × finalists × sessions × session length × interviewers. There are no free-form formulas and nothing typed by a visitor is ever evaluated as code. Formulas are versioned; a saved decision records the versions it used.
- Person-hours and elapsed time are different. Setup hours are spread evenly over the step's weeks; recurring hours repeat every week until the step ends or the horizon is reached. Work in parallel still adds its hours together.
- Weeks and months. Labour is planned in weeks and cash in months; one month is 4.345 weeks. A week belongs to the month in which it ends.
- Cash and valued time are separate. Valued staff time is hours × the value of an hour you enter. It is an economic cost, not money paid out, and is always shown apart from cash.
- Money. Amounts are held in whole cents and rounded half away from zero at each step. One currency per scenario; amounts in different currencies are never added together, and nothing is converted.
- Unknown is not zero. Any input can be marked unknown. Anything that depends on it is shown as unresolved, never as 0.
- No discounting. Cumulative costs are simple sums over the horizon.
Formula families
| Family | What it adds to the steps | What it does not do |
|---|---|---|
| steps @ 1 | Hours and cash per step, by role, week and month; funnels as explicit stage entrants. | Infer quality, conversion or elapsed time from effort. |
| pricing @ 1 | Bill = base fee + unit price × usage above an allowance, for light, typical and heavy customers; revenue and contribution with the same customers; break-even usage between plans. | Predict churn, conversion or changes in usage caused by a price change. |
| horizon_cost @ 1 | Cumulative cash and cash-plus-valued-time by month, and the month in which paths cross. | Price quality differences, vendor risk or the cost of switching away later. |
| support @ 1 | Conversations avoided by self-service, answered by automation, handed off to people, and the hours people spend answering and reviewing. | Assume an automation rate. It must be entered as a range from your own data or trial. |
Engine 1.0.0. The same specification runs in the browser and on the server; the page checks that both agree and says so if they do not.
Scenarios, sensitivity and break-even
Low, base and high values are scenarios, not probabilities. Sensitivity moves one input at a time to its low and high value and reports whether the order of the paths changes. Break-even and crossover points are facts about the formulas under your inputs, not evidence of what customers or teams will do. There is no Monte Carlo simulation and no success likelihood.
How paths are judged
There is no overall score. Each path is described separately by:
- Eligibility — does it meet your hard constraints? An unanswered question leaves it unresolved, not passed or failed.
- Practical fit — soft requirements you do not meet are listed as concerns.
- Trade-offs — what you gain and give up, including things the numbers do not capture.
- Evidence — described in words from the claims behind it, never as a percentage.
- Uncertainty — unknown inputs and inputs that can change the order.
A path is called dominated only when another eligible path costs less in every modelled dimension — and its unmodelled benefits are still listed. Ties and "not enough to recommend" are legitimate outcomes.
Evidence labels
- Documented company practice. The company itself documents this practice for the stated period and scope.
- WeCaseStudy adaptation for your context. WeCaseStudy's adaptation of a documented practice for a smaller or different context. It is not a claim that the company used this exact workflow.
- Original WeCaseStudy template. An original WeCaseStudy template, not attributed to any company.
- Your custom path. Your own combination of steps; kept private in your browser.
Claim types
- Documented practice
- Self-reported outcome
- Independently observed outcome
- Editorial interpretation
- User assumption
- Model-derived result
- User-recorded pilot observation
A vendor-reported result is not an independently measured one, a documented policy is not proof that every employee follows it, and a historical practice is never presented as current without a dated check.
Review, freshness and publication
Claims carry a review state (Unverified, Source checked, Verified by a named reviewer, Disputed, Retired). Review intervals depend on how quickly a fact goes stale: 90 days for current prices and product features, 365 days for policies, 1095 days for dated historical episodes. An automatic link check can flag a broken or changed page for an editor; it never marks anything as verified, and a "last reviewed" date only moves when a person records a review.
Pages move through Draft → Researching → Verification required → Editorial review → Approved → Published → Needs update → Archived. A page is indexed by search engines only after it passes the automated checks and a named editor approves it; a material change to anything it relies on takes it out of the index until it is approved again.
Pilots and observations
Observations you record are kept apart from the modelled values; the model is never overwritten with actuals. The tool warns about missing or ambiguous denominators, small samples and mismatched periods, and does not declare statistical significance or causation from before-and-after numbers.
Privacy
Scenarios, plans, pilots and saved decisions are stored only in your browser's local storage — not on our server and not in your address bar. Exports are generated on your device. Anonymous counters record only which kind of action happened on which decision (for example "pack exported"), never your inputs, names or numbers, and no IP address is stored. Delete all local data at any time from a decision's Decision record tab or the Saved decisions page.
What this tool will not do
- Score or screen job candidates, recommend securities, or replace legal, clinical or professional review.
- Invent company practices, outcomes, benchmarks or success probabilities.
- Let sponsorship influence which paths are shown or how they are described.