What-If Planning: Simulate Your Year Before You Live It

You set a goal in January. By March you have no idea whether you are on pace, behind, or quietly abandoning it. The goal still sits there, technically alive, but you are flying blind. You do not know if your current rate of work finishes it by the deadline, or by the heat death of the universe.

This is the core failure of resolutions. A resolution is a wish with a date attached. It tells you where you want to land. It tells you nothing about your actual trajectory, and it never updates as the months grind on. So you do the only thing you can: you guess. And humans are catastrophically bad at guessing how long their own work takes (Buehler, Griffin, and Ross, 1994). We picture the smooth best-case plan and ignore every past week where life happened.

What-if planning is the fix. Instead of declaring a goal and hoping, you simulate the year before you live it. You replay how you have actually been working and project that forward into a real finish date with a real probability attached. This post shows the exact math StrataGist uses to do it, because a forecast you cannot inspect is just astrology with extra steps.

Why resolutions fail and simulation wins

The planning fallacy is not a character flaw you can willpower away. It is a stable bias in how people estimate.

People systematically underestimate how long their own tasks will take because they focus on optimistic plan-based scenarios rather than relevant past experience (Buehler, Griffin, and Ross, 1994).

The phrase that matters there is "relevant past experience." The cure for the planning fallacy is not more optimism or better discipline. It is reference-class forecasting: stop imagining the plan, and instead look at how this kind of work has actually gone for you before. A simulation does exactly that. It refuses to ask "how fast could I go?" and instead measures "how fast have I been going?"

This matters even more if your sense of time is unreliable to begin with. People with ADHD show measurable time-perception deficits and tend to overestimate or misjudge durations (Zheng, Wang, Chiu, and Shum, 2022), rooted in a broader temporal myopia where behavior is captured by the immediate now instead of being guided by represented future events (Barkley, 1997). If your internal clock is already noisy, a gut-feel projection is worthless. An external, measured one is not.

Specific, difficult goals do drive higher performance than vague ones (Locke and Latham, 2002). But "specific" has to include the trajectory, not just the target. A goal of "finish the book by December" is specific about the destination and silent about the road. What-if planning fills in the road.

The backtest: replaying your history

StrataGist's simulation engine is called Ephemeris, after the astronomical tables that let you compute where a planet was, or will be, at any instant. The principle is the same: a deterministic function of time. Feed it a moment, and it tells you the state of your goals at that moment.

The backtest harness works by advancing a simulated "now" across the weeks of your history. At each step it runs the data, as it existed at that instant, through the exact same forecasting code the live app ships. There is no separate "demo math." The replay drives the real engine:

for dayMs = startMs ... base, step by stepDays:
    nodes  = streamAsOf(stream, dayMs)      // your world, as of that instant
    offers = rankOffers(presence(nodes))    // what the app would have surfaced
    traj   = goalTrajectory(goal, nodes)    // the forecast it would have made

Because the engine is a pure function of now, the same inputs always produce the same output. No random sampling, no Monte Carlo dice. You can replay your spring and ask: given what I had actually done by mid-March, what finish date would the system have predicted? Then you check it against what really happened. That is a backtest, the same discipline a quant uses before trusting a trading model.

The equations behind the forecast

Here is the substance. Everything below is the literal math in web/lib/trajectory/index.ts, not a marketing simplification.

Pace needed versus pace actual

Two numbers anchor the whole forecast. The first is how fast you must go from here to finish on time:

remaining  = max(0, total - done)
weeksLeft  = max(0.1, (dueMs - nowMs) / WEEK_MS)
paceNeeded = remaining / weeksLeft

The second is how fast you are actually going. A flat average would let a strong January hide a dead March, so the central pace is a recency-weighted mean (an EWMA) over a trailing 8-week window, with older weeks decayed by 0.7 each step:

muRecent  = Sigma_i ( DECAY^weeksBack_i * counts[i] ) / Sigma_i ( DECAY^weeksBack_i )
DECAY     = 0.7,  weeksBack = 0 for the most recent week
paceActual = (done > 0) ? muRecent : null

A user who front-loaded and then stalled reads as drifting, not "fine on average." A steady user gets muRecent ~= muFlat, so nothing is distorted. This is reference-class forecasting made concrete: your near future is predicted by your recent self, weighted toward last week.

Volatility, because steadiness is information

How choppy your weeks are is as important as how productive they are. The engine takes the sample standard deviation of the weekly counts and reduces it to one "how steady is this person" number, the coefficient of variation:

variance      = Sigma_i ( counts[i] - muFlat )^2 / max(1, LOOKBACK_WEEKS - 1)
sigma         = sqrt(variance)
paceVariation = min(2, sigma / muRecent)

That Bessel-corrected (n minus 1) variance is the raw spread, and it feeds the projection band, the confidence, and the hit probability. A volatile history honestly produces a less certain forecast. The system never pretends to know more than your data supports.

The projected finish date and its band

Now the payoff. Divide remaining work by your actual pace to get the expected finish, then build an optimistic-to-late window by projecting at one sigma faster and one sigma slower:

expectedWeeks = remaining / paceActual
projectedDate = nowMs + expectedWeeks * WEEK_MS

fastPace   = paceActual + sigma
slowPace   = max(paceActual * 0.25, paceActual - sigma)
optimistic = nowMs + (remaining / fastPace) * WEEK_MS
late       = nowMs + (remaining / slowPace) * WEEK_MS

A steady history (small sigma) yields a tight date range. A chaotic one yields a wide range. The band literally is your historical variance made visible. The slow pace is floored at 25 percent of actual so the late date never runs off to infinity.

Hit probability: the question you actually care about

A date is good. A probability of hitting your deadline is better. The engine models the number of weeks to finish as a Normal distribution and reads the chance of finishing on time off the Gaussian CDF:

meanW = remaining / paceActual
sdW   = (remaining * sigma) / paceActual^2          // first-order error propagation
hitProbability = clamp( normalCdf( (weeksLeft - meanW) / sdW ), 0, 1 )

The standard-normal CDF is a deterministic closed-form approximation (Abramowitz and Stegun coefficients), so the same situation always gives the same probability. No dice rolled, no seed to vary. The author's comment calls it "Monte-Carlo-lite," and that is exactly right: you get the distributional answer without the randomness.

Confidence: when to distrust the forecast

Honesty over hype means the system tells you when not to believe it. Confidence is a 0-to-1 trust score that collapses if any ingredient is weak:

confidence    = historyFactor * steadiness * targetFactor
historyFactor = min(1, doneCount / 6)
steadiness    = max(0, 1 - paceVariation / 1.5)
targetFactor  = (weeksLeft != null) ? 1 : 0.6

Three completions and a choppy pace? Low confidence, and the app says so. The factors multiply, so a single weak link drags the whole score down. A forecast that hides its own uncertainty is the thing that got you into a doomed resolution in the first place.

Are you spending time where you said it matters?

Simulation is not only about deadlines. A separate detector compares what you say matters against what you actually do, in the economist's revealed-preference sense. It computes the share of your stated importance for each goal and the share of your actual completed effort, then flags the gap:

gap  = statedShare - revealedShare
kind = |gap| >= 0.12 ? (gap > 0 ? "neglected" : "over-invested") : "aligned"

A positive gap means you declared something important and quietly under-invested in it. This is the value-drift any year-long plan needs and no resolution ever surfaces. It is shown gently, never as an alarm, because the goal is to help you correct course, not to scold you.

How StrataGist puts this in front of you

You do not see any of this Greek. StrataGist keeps rigorous math on the inside and plain language on the outside. What you get is a calm sentence: on pace, a few weeks early, or behind, with a finish date, a window, and a confidence you can trust because it was earned from your real history.

This sits inside the product's single loop, Capture then Surface then Do then Review. The forecast is the Review made quantitative: it samples how the past actually went and feeds that back into what you plan next, instead of asking you to re-categorize everything up front (Barkley, 1997). Pair that with proven follow-through tools like specific if-then implementation intentions, which carry a medium-to-large effect on goal attainment (Gollwitzer and Sheeran, 2006), and you have a year you can steer rather than merely hope for.

Stop guessing whether you are on track. Replay your history, simulate your year, and watch the finish date move as you do.

Try StrataGist free, no signup, at /dock.

References

1. Buehler, R., Griffin, D., and Ross, M. (1994). Exploring the "planning fallacy": Why people underestimate their task completion times. Journal of Personality and Social Psychology, 67(3), 366-381. link
2. Zheng, Q., Wang, X., Chiu, K. Y., and Shum, K. K. (2022). Time perception deficits in children and adolescents with ADHD: A meta-analysis. Journal of Attention Disorders, 26(2), 267-281. link
3. Barkley, R. A. (1997). Attention-deficit/hyperactivity disorder, self-regulation, and time: Toward a more comprehensive theory. Journal of Developmental and Behavioral Pediatrics, 18(4), 271-279. link
4. Locke, E. A., and Latham, G. P. (2002). Building a practically useful theory of goal setting and task motivation: A 35-year odyssey. American Psychologist, 57(9), 705-717. link
5. Gollwitzer, P. M., and Sheeran, P. (2006). Implementation intentions and goal achievement: A meta-analysis of effects and processes. Advances in Experimental Social Psychology, 38, 69-119. link