Will I Hit My Goal? Forecasting It From Your Pace

You set a goal with a deadline. You have been chipping away at it. And now, late at night, the only question that matters is the one nothing on your screen will answer: will I hit my goal, or am I quietly falling behind?

Most planners are useless here. They show you a checklist and a due date and leave you to do the arithmetic in your head, which is exactly where the trouble starts. Humans are systematically bad at this estimate. We do not look at our own history. We look at the plan, imagine it going well, and tell ourselves we will catch up next week.

This post is about replacing that wishful arithmetic with a real forecast: one built from the pace you have actually sustained, with a projected finish date, a date range, and an honest probability. These are the exact equations inside StrataGist's Compass engine. No hand-waving. Real math, shown plainly.

Why your own estimate is the problem

The reason "I think I'll make it" is unreliable has a name. The planning fallacy is the robust finding that people underestimate how long their own tasks will take because they focus on an optimistic, plan-based scenario instead of relevant past experience (Buehler, Griffin, and Ross, 1994).

People underestimate their own completion times even when they know that similar past tasks ran long. The fix is not more willpower. It is anchoring on the historical record instead of the story in your head (Buehler, Griffin, and Ross, 1994).

This hits some people harder than others. ADHD involves a self-regulation deficit that produces "temporal myopia," where behavior is captured by the immediate now instead of being steered by an internally represented future (Barkley, 1997). When the future is hard to feel, the deadline is not a real input to today's decision. A forecast that lives on the screen, not in your head, is a form of cognitive offloading: using an external tool to carry a load your working memory keeps dropping (Risko and Gilbert, 2016).

So the design rule is simple. Do not ask the user to predict. Measure what they actually did and project it forward.

Step one: the pace you need

Start with the only question a deadline really poses. To finish on time, how much do you have to complete per week from now on?

paceNeeded = remaining / weeksLeft

remaining  = max(0, total - done)
weeksLeft  = max(0.1, (dueMs - nowMs) / WEEK_MS)
WEEK_MS    = 604800000   // 7 days in ms

remaining is the open work in the goal's subtree (every leaf task under it that is not yet done). weeksLeft is the time to the target date, floored at 0.1 so the math never divides by zero on the morning something is due. If a goal has no target date, paceNeeded is simply not computed. No deadline, no required pace. The system does not invent urgency you did not ask for.

This single number reframes the goal. Not "240 things to do," but "you need to finish 6 a week." That is a goal you can actually hold in your head, which matters because specific, sufficiently difficult goals drive higher performance than vague ones (Locke and Latham, 2002).

Step two: the pace you are actually getting

Here is where most tools cheat by showing a flat lifetime average. That number lies about anyone who started strong and stalled. StrataGist weights recent weeks more heavily, using an exponentially recency-weighted mean over a trailing 8-week window.

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.length > 0) ? muRecent : null

counts[i] is how many items you completed in trailing week i. The 0.7^weeksAgo weighting means last week counts far more than two months ago. A person who front-loaded then went quiet reads as drifting, which is the truth. A steady worker gets muRecent close to the flat mean. With no completion history at all, paceActual is null, because guessing a pace from zero data would be dishonest.

The raw completion timestamps become that weekly series by simple bucketing.

wAgo = floor( (nowMs - completedAt) / WEEK_MS )
if 0 <= wAgo < weeks:  counts[weeks - 1 - wAgo] += 1

Each finished item lands in a weekly bucket by how many whole weeks ago you completed it. The newest week sits last in the array.

Step three: how steady are you, really?

Two people can average the same pace and have wildly different futures: one finishes four tasks every week like a metronome, the other does sixteen one week and zero for three. Steadiness is its own measurement. It starts with the flat mean and the sample variance around it.

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

That n - 1 denominator is the standard Bessel correction for a sample variance. sigma, the standard deviation of your weekly output, is the raw "choppiness" number that drives everything downstream. To make it comparable across goals of different sizes, it gets normalized into a coefficient of variation.

paceVariation = (muRecent > 0) ? min(2, sigma / muRecent) : null

Zero means a perfectly even pace. Larger means choppier. It is clamped at 2 so one chaotic week cannot break the scale.

Step four: the answer, three ways

Now the forecast. First, the expected finish date: remaining work divided by your real pace, added to today.

expectedWeeks = remaining / paceActual
projectedDate = nowMs + expectedWeeks * WEEK_MS
// remaining == 0 && total > 0  =>  projectedDate = today

A single date pretending to be certain would be its own kind of lie, so the projection comes as a range built from your volatility. Project at one standard deviation faster and one slower.

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

This is the elegant part: the band literally is your historical variance made visible. A steady history (small sigma) gives a tight window. A volatile one gives a wide one. The slow pace is floored at 25% of actual so a bad streak cannot push the late date to infinity.

And the headline number, the one you actually asked for: the probability you finish on time. The weeks-to-finish is modeled as a Normal distribution, and the chance you land at or before the deadline is read off its cumulative distribution function.

meanW = remaining / paceActual
sdW   = (remaining * sigma) / paceActual^2          // error propagation of R/mu
hitProbability = clamp( normalCdf( (weeksLeft - meanW) / sdW ), 0, 1 )
// sdW ~= 0:  1 if meanW <= weeksLeft else 0
// paceActual <= 0:  probability = 0

The standard-normal CDF is a deterministic closed form (an Abramowitz-Stegun polynomial), so identical inputs always give the identical probability. No random sampling, no number that wobbles every time you refresh.

t = 1 / (1 + 0.2316419 * |z|)
d = 0.3989422804 * exp(-z^2 / 2)
p = d*t*(0.3194 + t*(-0.3566 + t*(1.7815 + t*(-1.8213 + t*1.3303))))
CDF(z) = z >= 0 ? 1 - p : p

So "will I hit my goal?" gets a real answer. Not a vibe. A date, a range, and a percentage, all derived from work you genuinely did.

The signal that drives the nudge

For the system to decide how loudly to speak up, it needs one signed number for how far off pace you are.

deviation = clamp( (paceActual - paceNeeded) / paceNeeded, -1, 1 )
// fallback when no numeric pace: +0.5 if band ahead, -0.5 if behind, else 0

Positive means ahead, negative means behind, zero means dead on. It is a fraction of the needed pace, so being one task short on a small goal reads differently than on a large one. A calmer companion number says how far off the deadline you will land.

weeksVsTarget = round10( (dueMs - projDateMs) / WEEK_MS )

Positive is weeks early, negative is weeks late. Either way, it is information, not an alarm.

Honesty about the forecast itself

A projection from two data points is not worth the same as one from twenty weeks of steady work, and pretending otherwise would be exactly the kind of false confidence we are trying to kill. So the forecast rates its own trustworthiness.

confidence = round100( historyFactor * steadiness * targetFactor )

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

You earn high confidence only with enough history, a steady pace, and a real target date. The factors multiply, so any single weak one drags the whole score down. Choppy weeks erode confidence even after a long run. This is a deliberate stance: heuristics are labeled as heuristics, and the tool tells you when it is guessing.

When the numbers exist, they decide the trajectory word, so the label can never contradict the figure beside it.

if weeksVsTarget != null:
    band = weeksVsTarget > 1 ? ahead : weeksVsTarget < -1 ? behind : on-track
else if paceNeeded & paceActual & paceNeeded > 0:
    band = deviation > 0.1 ? ahead : deviation < -0.1 ? behind : on-track
else:
    band = completion-ratio band

If there is no numeric pace yet, it falls back to a qualitative read: of the work planned to have happened by today, what fraction is done.

ratio = done / planned
band  = ratio >= 0.9 ? ahead : ratio >= 0.6 ? on-track : behind
// planned == 0  =>  quiet

From forecast to action

A number that only confirms you are behind is just a more precise way to feel bad. The point of knowing your pace is to act on it before the deadline does the deciding for you.

The single most effective lever is shrinking the gap with a concrete plan for the next step. Implementation intentions, simple "when situation X arises, I will do Y" plans, have a medium-to-large effect on goal attainment across 94 tests (Gollwitzer and Sheeran, 2006), and they help even where action control is chronically impaired (Gawrilow, Gollwitzer, and Oettingen, 2011). That is why StrataGist does not stop at the forecast. When you capture the next task, it auto-schedules it onto today's timeline, which is a soft commitment device that turns "I should catch up" into a specific block at a specific time. Present bias is real and strongest for effort (the very thing a deadline asks of you), so a good default beats a punitive deadline alert every time.

The forecast is steering, not a scoreboard. The Compass engine reads your pace and the band, then adjusts how strongly it surfaces the work that closes your gap. Ahead of pace? It eases off. Behind? It brings the goal forward, gently. And because the whole model treats time-in-app as a cost rather than a win, it is trying to get you to the finish line and out, not to keep you staring at a dashboard.

See your own forecast

Stop guessing whether you will hit your goal. Let the math you just read run on your real history: your pace needed, your actual pace, a projected finish date with an honest range, and a true hit probability.

StrataGist is free and local-first, and you can start with no signup. Open the dock at /dock, capture a goal with a deadline, and watch the Compass forecast it from the work you actually do.

References

1. Barkley, R. A. (1997). Behavioral inhibition, sustained attention, and executive functions: Constructing a unifying theory of ADHD. Psychological Bulletin, 121(1), 65-94. link
2. Buehler, R., Griffin, D., & 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
3. Gawrilow, C., Gollwitzer, P. M., & Oettingen, G. (2011). If-then plans benefit delay of gratification performance in children with and without ADHD. Cognitive Therapy and Research, 35(5), 442-455. link
4. Gollwitzer, P. M., & Sheeran, P. (2006). Implementation intentions and goal achievement: A meta-analysis of effects and processes. Advances in Experimental Social Psychology, 38, 69-119. link
5. Locke, E. A., & 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
6. Risko, E. F., & Gilbert, S. J. (2016). Cognitive offloading. Trends in Cognitive Sciences, 20(9), 676-688. link30098-5)