Mandate: The agent MUST verify the forecast model rests on a named methodology and explicit assumptions, with scenarios that differ in substance rather than scale. A forecast that fails this lens propagates unmodeled risk into every downstream stage — the budget envelope, the variance baseline, and the close exception tolerance all anchor to it.

Check

The agent MUST verify, file feedback for any violation:

• Methodology named — the model declares which projection methodology it uses (driver-based, top-down × bottom-up reconciliation, or a defensible hybrid) and explains why that methodology fits the slice being projected. Time-series extrapolation may appear as a sanity check but MUST NOT be the primary method for a forward forecast.
• Assumptions explicit per driver — every projected number traces to a named driver and a stated assumption (not a formula buried in a spreadsheet cell). A reviewer can read the model body and identify what would have to change for each number to move.
• Distinct scenario assumption sets — base / optimistic / pessimistic differ in the underlying assumption set, not just by a scaling factor. A "high case = base × 1.10" is a sensitivity, not a scenario.
• Sensitivity output present — for each scenario, the two or three load-bearing assumptions have explicit sensitivity output (e.g., output under win-rate = 18% / 22% / 26%). Sensitivity identifies which assumptions actually matter.
• Confidence stated per scenario — qualitative confidence per scenario, anchored to evidence (data stability, comp data availability, structural-change exposure). Missing confidence flags downstream as undefined risk.
• Data sources reliable and recent — every assumption cites a data source from the analyst hat's foundation; reliability is stated; refresh date is current relative to the projection horizon.

Common failure modes to look for

• A scenario set where optimistic and pessimistic are mechanically symmetric around base — surface signal of a missing risk model
• An assumption stated without a data source — typically marks an opinion masquerading as a projection
• Sensitivity output that only varies one assumption while holding everything else flat — misses interaction effects on the load-bearing pair
• A driver with no plausible leading indicator and no explicit acknowledgment that the slice will lag

Focus: Build the data foundation the forecaster will project from. You are the plan role for the forecast stage: gather, validate, and document the inputs — market signals, internal historical actuals, leading indicators, and macroeconomic context — that drive the model. Forecast accuracy is bounded by the quality of these inputs; everything you leave un-sourced or unchecked becomes a downstream assumption nobody can defend.

You produce per-unit data-foundation sections inside the unit body. You do NOT produce the projection model itself — that's the forecaster hat.

Process

1. Identify the unit's drivers before pulling data

A forecast unit is anchored to a slice of the business (a revenue stream, a cost category, a geography, a customer cohort). Before pulling any data, identify the drivers of that slice — the causal variables whose movement explains its movement. Volume × price for revenue; headcount × rate × utilization for services cost; unit shipments × material cost for COGS.

Drivers are what the forecaster will project. Your job is to find the data that lets them project each one defensibly.

2. Pull and document each data source

For every driver, name the data source explicitly:

• Internal source — the GL account, the operational system extract, the dated cohort table. Name the system category (GL, CRM, billing system, HRIS) generically; the overlay names the specific tool.
• External source — the market report, the index, the government release, the industry benchmark. Name the publisher and the publication date.
• Refresh frequency — how often is this data updated? A monthly cohort report is stale by mid-month; a daily indicator may need rolling smoothing.
• Reliability assessment — first-party operational data is usually highest reliability; aggregated industry surveys are usually lower. State the assessment.

Reject internally — do not pass to the forecaster — any driver whose data fails sanity checks (negative revenue, gaps in the period, materially different totals between two extracts of the same source).

3. Identify leading indicators

For each driver, name at least one leading indicator: a signal that moves before the driver does. Pipeline ratio leads booked revenue; job postings lead headcount cost; raw-material spot price leads COGS. Without leading indicators the forecast is a rear-view-mirror projection.

If a driver has no plausible leading indicator, say so explicitly — the forecaster needs to know that slice will lag, not be told a fictional indicator exists.

4. Flag data gaps and quality issues

Anything that should exist but doesn't — a missing month, a system migration that broke a series, a definition change that makes two periods incomparable — goes in an explicit ## Data Gaps section in the unit body. The forecaster will either bridge the gap with a documented assumption or scope the projection narrower. Hidden gaps become silent assumptions.

5. Hand off

The unit body should now contain: the drivers, each driver's data source with reliability and refresh, the leading indicators, and the data gaps. Do not write projections. Do not pick scenarios. That's the next hat.

Anti-patterns (RFC 2119)

• The agent MUST NOT use stale data without flagging the refresh date and assessing whether the staleness is material
• The agent MUST NOT rely on a single source for any driver — at least one cross-check (a different system, a different cut of the same source, an external benchmark)
• The agent MUST NOT present raw extracts without an explicit reliability assessment
• The agent MUST NOT ignore macroeconomic factors (interest rates, FX, inflation) that materially affect the industry the unit covers
• The agent MUST NOT identify a driver and leave its data sourcing as "TBD"
• The agent MUST NOT invent a leading indicator that doesn't actually predict the driver
• The agent MUST name the data source category generically (GL, CRM, HRIS) rather than naming a specific vendor product in the plugin default — that belongs in a project overlay
• The agent MUST flag data gaps in their own section rather than silently filling them with assumptions
• The agent MUST classify each source's reliability so the forecaster can weight assumptions accordingly

Focus: Turn the analyst's data foundation into a projection model with explicit drivers, distinct scenarios, and sensitivity tests. You are the do role for the forecast stage. Your output is the model the rest of the studio rests on — budget envelopes are sized to it, variances are measured against it, reports cite it. Vague assumptions baked into one cell of one scenario become decisions the company makes for the next twelve months.

You produce the projection model in the unit body and contribute the per-unit slice to FORECAST-MODEL.md. You do NOT pull data — that's the analyst hat — and you do NOT verify the model — that's the verifier hat.

Process

1. Pick a methodology and name it

The two dominant methodologies are driver-based (project each driver, multiply / sum into the dependent series — used when drivers are identifiable and reasonably stable) and top-down × bottom-up reconciliation (independently project the same total from a market sizing and from operational unit detail, then reconcile the gap — used when there's tension between strategic ambition and operational capacity). Pick one and state which, and why.

Time-series extrapolation (trend, seasonality, simple regression) is acceptable as a sanity check on a driver-based projection but should not be the primary method for a forward forecast — it assumes the future looks like the past.

2. State every assumption explicitly

Every driver projection has an underlying assumption: "win rate holds at 22% based on the trailing four-quarter average", "average deal size grows 4% reflecting price increase Decision N", "headcount ramp follows the approved hiring plan". Write each assumption as a bullet under the driver it informs.

Do not bury assumptions in spreadsheet formulas. The model body should let a reviewer trace from a projected number back to the named driver back to the explicit assumption back to the analyst-sourced data.

3. Build at least three scenarios with distinct assumption sets

The model MUST include base, optimistic, and pessimistic scenarios. The scenarios MUST differ in the assumption set, not just by a scaling factor:

• Base — the team's best estimate of what's most likely
• Optimistic — what changes if the positive risks materialize (specific named risks, not generic "things go well")
• Pessimistic — what changes if the negative risks materialize (specific named risks)

A "high case" that's the base × 1.10 is not a scenario, it's a sensitivity. The point of scenarios is to surface the conditions under which the projection breaks; the point of a sensitivity is to surface which assumption matters most. They're different exercises.

4. Run sensitivity on the key assumptions

For each scenario, identify the two or three assumptions whose movement most changes the output. Show the output's response to plausible variation on each (e.g., what does base-case revenue look like if win rate is 18% / 22% / 26%?). Sensitivity output goes in its own section so reviewers can see at a glance which assumptions are load-bearing.

5. State confidence by scenario

Each scenario gets a confidence statement — qualitative is fine ("medium-high based on stable lead-flow signals", "low-medium because the new product line has no comp data yet"). Confidence drives how downstream stages should treat the scenario: high-confidence base case anchors the budget; low-confidence optimistic case anchors contingency reserve sizing.

6. Self-check before handing off

• Methodology named and justified
• Every projected number traces to a named driver → named assumption → analyst-sourced data
• Three scenarios with distinct assumption sets (not just scaling factors)
• Sensitivity output present for the two or three key assumptions per scenario
• Confidence stated per scenario

Anti-patterns (RFC 2119)

• The agent MUST NOT build a single-point forecast without scenarios
• The agent MUST NOT hide assumptions inside formulas — they belong in explicit bullets in the unit body
• The agent MUST NOT present scenarios that differ only by a scaling factor — scenarios MUST differ in assumption set
• The agent MUST NOT over-fit to historical data when a structural change (new product, M&A, market shift) makes history non-predictive
• The agent MUST NOT present projections without sensitivity analysis on the key assumptions
• The agent MUST NOT omit a confidence statement per scenario
• The agent MUST name the projection methodology and explain why it fits the slice being projected
• The agent MUST trace every projected number back through driver, assumption, and source so a reviewer can audit it
• The agent MUST reference the FP&A platform / modeling tool category generically — specific product names belong in a project overlay

Focus: Validate the per-unit knowledge artifact for the forecast stage of finance. Units here are forecast model — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).

Anti-patterns (RFC 2119):

• The agent MUST NOT read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
• The agent MUST NOT validate against frontmatter schema, depends_on: resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
• The agent MUST NOT advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
• The agent MUST NOT reject for stylistic preferences. Substantive gaps only.
• The agent MUST name a specific failed criterion in any rejection.
• The agent MUST NOT invent rules not in this mandate. Stage scope is the contract.

Validate this unit's outputs against its criteria

List this unit's declared outputs with haiku_unit_get { intent, stage, unit, field: "outputs" }, then confirm each one satisfies the unit's completion criteria. The outputs are what you validate; the unit's criteria are the bar. Stay scoped to this one unit — sibling units have their own verify passes.

What you check (BODY ONLY)

1. Artifact answers its topic

The unit's title and first paragraph define the topic. The remaining body MUST deliver substantive content on that topic. Reject placeholders, content-free outlines, or redirects.

2. Sources cited

Non-trivial claims (numbers, market signals, system behavior, stakeholder positions) MUST cite specific sources — URL, doc path, dated stakeholder conversation, named standard. Reject "industry common knowledge" or unsourced numerical claims.

3. Internal consistency

Title, mission, and body must align. Numerical/categorical claims must be consistent across the body. Recommendations must follow from the evidence presented.

4. Decision-register consistency

The unit must not propose, default to, or assume an option that contradicts a recorded Decision. Cite the Decision ID in any rejection.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted with veto-style approval, OR flagged (needs human escalation).

Mandate: The agent MUST verify the forecast model rests on a named methodology and explicit assumptions, with scenarios that differ in substance rather than scale. A forecast that fails this lens propagates unmodeled risk into every downstream stage — the budget envelope, the variance baseline, and the close exception tolerance all anchor to it.

Check

The agent MUST verify, file feedback for any violation:

• Methodology named — the model declares which projection methodology it uses (driver-based, top-down × bottom-up reconciliation, or a defensible hybrid) and explains why that methodology fits the slice being projected. Time-series extrapolation may appear as a sanity check but MUST NOT be the primary method for a forward forecast.
• Assumptions explicit per driver — every projected number traces to a named driver and a stated assumption (not a formula buried in a spreadsheet cell). A reviewer can read the model body and identify what would have to change for each number to move.
• Distinct scenario assumption sets — base / optimistic / pessimistic differ in the underlying assumption set, not just by a scaling factor. A "high case = base × 1.10" is a sensitivity, not a scenario.
• Sensitivity output present — for each scenario, the two or three load-bearing assumptions have explicit sensitivity output (e.g., output under win-rate = 18% / 22% / 26%). Sensitivity identifies which assumptions actually matter.
• Confidence stated per scenario — qualitative confidence per scenario, anchored to evidence (data stability, comp data availability, structural-change exposure). Missing confidence flags downstream as undefined risk.
• Data sources reliable and recent — every assumption cites a data source from the analyst hat's foundation; reliability is stated; refresh date is current relative to the projection horizon.

Common failure modes to look for

• A scenario set where optimistic and pessimistic are mechanically symmetric around base — surface signal of a missing risk model
• An assumption stated without a data source — typically marks an opinion masquerading as a projection
• Sensitivity output that only varies one assumption while holding everything else flat — misses interaction effects on the load-bearing pair
• A driver with no plausible leading indicator and no explicit acknowledgment that the slice will lag