Lifesight forecast scenario

Lifesight Forecast & Scenario Planning

Help the user see forward — a revenue projection, the budget needed to hit a target, or a head-to-head between options — before they commit real money. A forecast is a projection with a range, never a promise. The discipline here is honesty about uncertainty and comparing options on the right axis.

Prerequisites (router handles): workspace calibrated, profile loaded. Operate under lifesight-core; present under lifesight-rendering. Load both.

The three shapes this takes

1. Forecast — "what will revenue be?" Project forward from a stated allocation.
2. Target-KPI planning — "what budget hits $X revenue?" Solve backward from a goal.
3. Scenario comparison — "current vs +15% vs my custom plan." Put options side by side.

Identify which one the user is asking before pulling anything.

Flow

1. Confirm the basis. A forecast is meaningless without its assumptions: which allocation (current, or an optimized plan?), what budget, what period, which model. Lock these first (from the profile + one clarifying question if needed).
2. One heavy call via ask_mia (forecast / scenario / target-KPI). Walk its gates (lifesight-core Rule 4). One analysis per turn.
3. Frame the result as a range with assumptions, not a point promise.

Judgment checks (mandatory)

• Always a range + assumptions. State the confidence range and the assumptions it rests on (budget, period, model, which scenario). A single number with no range is false precision — and dangerous if someone treats it as a commitment.
• Compare scenarios on the right axis. The higher-revenue scenario is NOT automatically the better one. Show incremental revenue and efficiency (iROAS) and the spend each requires. A target that demands value-destroying spend (lots more budget at sub-1.0 marginal return) must be called out — same discipline as budget-optimization Step 4.
• Target-KPI realism. "What hits $4M?" may have an answer that's inefficient or infeasible within guardrails. Give the budget and the efficiency cost of getting there; flag if the target requires spending past saturation.
• Platform vs causal, and recency. Name whether projections are on causal (incremental) outcomes; note data recency — a forecast off stale data inherits the staleness.

Output shape

1. The projection — the number(s) with a confidence range, lead with the decision.
2. The assumptions — budget, period, allocation, model, in one tight block.
3. Scenario table (if comparing) — each option's spend, projected incremental revenue, and efficiency, so the trade-off is visible — not just top-line.
4. The read — which path is actually best and why (efficiency, not just size), and what would de-risk it.

Next steps to offer

"Optimize the allocation to hit this" (→ budget-optimization) · "Validate the key assumption with a test" (→ experiment-design) · "Build the board/CFO version" (→ board-briefing / cfo-translation).

Red flags — STOP

• Presenting a forecast as a single certain number → range + assumptions
• Picking the scenario with the biggest top-line without showing efficiency/spend
• Answering "what hits $X" without flagging if it needs spend past saturation
• Treating a projection as a commitment the user can be held to
• Forecasting off stale data without saying so