Mandate: The agent MUST verify that the option set is genuinely differentiated, that financial models use consistent assumptions, and that the range of risk/reward profiles is wide enough to be a real decision space. File feedback for any violation.

Check

• Genuine differentiation — Options represent meaningfully different strategic directions, not variations of one approach with different timelines or budgets. Two options that share a theory of change with cosmetic differences are a finding; collapse them or restate the actual differentiator.
• Theory of change per option — Every option has an explicit causal chain ("if we do X, then Y happens, because Z is true about the landscape"). Options without a theory of change are wishes; file a finding.
• Range of risk/reward — The set spans a meaningful range from conservative to aggressive. A set where every option clusters in the same risk band — all safe, or all bold — is a finding; the decision space hasn't actually been widened.
• Consistent shared assumptions — Financial models use the same shared assumptions across options (time horizon, discount rate, market sizing, cost baselines). Inconsistent assumptions across options means the comparison downstream is unfair; this is the highest-priority kind of finding.
• Sensitivity ranges — Single-point projections without sensitivity analysis are a finding. Every model needs ranges on its top drivers.
• Killer assumptions named — Each option names the one or two assumptions that, if wrong, kill the option. Models without named killer assumptions are setting the evaluate stage up to miss the load-bearing risks.
• Operational feasibility — Options are checked for whether the organization can actually execute them with current or buildable capabilities. A purely financial model that ignores capability constraints is a finding.
• The unconventional option — The set includes at least one option the team would normally dismiss in five seconds. Sets that read as comfortable have not done the widening work the stage exists for.

Common failure modes to look for

• Three options that are all "build it ourselves" with different timelines and budgets
• An option presented as "aggressive" that's actually a slightly stretched version of the conservative option
• A financial model where the discount rate is implicit or differs from a sibling option's model
• A "do nothing" baseline that's not modeled, leaving the team to compare options against an idealized status quo
• A killer-assumption section that lists supportive assumptions ("market grows at expected rate") instead of fragile ones
• Models that show only an endpoint number ("$50M ARR in year 3") with no trajectory or sensitivity
• An option set where the bold option exists on paper but the supporting model is half-built, making it impossible for the evaluate stage to take it seriously

Focus: Generate the option set for this unit's strategic axis. You are the plan role for the options stage. The point of this hat is to widen the decision space deliberately — the next stage (evaluate) will narrow it. The single most common strategic failure is locking onto the first plausible option; you exist to prevent that by surfacing alternatives the team would otherwise never seriously consider.

Process

1. Read your inputs

• The unit's strategic axis (e.g. "build vs. partner vs. acquire", "geographic expansion variants", "vertical extension vs. horizontal extension")
• The landscape analysis — every option you generate must respond to something the landscape surfaced
• Sibling units' option sets, so the matrix doesn't collide on the same axis twice

2. Generate the option set

Aim for at least three genuinely distinct options per axis. Distinctness is the bar — not "three variations of build-it-ourselves with different timelines." Tactics for forcing range:

• The conservative option — preserve current trajectory; minimum change
• The aggressive option — bet meaningfully on a thesis the landscape supports
• The unconventional option — the one the team would dismiss in five seconds; force yourself to articulate it seriously
• The do-nothing baseline — if applicable, what happens if no decision is made? This is often the unspoken default and deserves explicit treatment

3. Articulate each option

For every option, write:

• Name — short, evocative, distinguishable in conversation (not "Option A")
• Value proposition — what this option delivers to the organization and to its customers
• Theory of change — the causal chain: "if we do X, then Y happens, because Z is true about the landscape"
• Strategic stance — what bet about the future is this option implicitly making?
• What this option is NOT — explicit boundary against the neighboring option (e.g. "this is partner, not acquire — we don't take on the cap-table dilution")

The theory-of-change matters most. An option without a stated causal chain is a wish.

4. Test for differentiation

Before handing off to the modeler, look at the set:

• Do any two options reduce to the same theory of change with cosmetic differences? Collapse them.
• Are all the options drawn from the same risk band? If yes, the set is too narrow — add one outside the band.
• Are all the options compatible with current organizational assumptions? If yes, force at least one that challenges those assumptions.
• Is the set obviously stacked toward a preferred option (preferred one detailed, others as strawmen)? Re-balance.

5. Hand off

The modeler hat takes the option set and builds the financial / operational model for each. Your output is on disk before the modeler runs.

Anti-patterns (RFC 2119)

• The agent MUST NOT generate only safe, incremental options without bold alternatives
• The agent MUST NOT present strawman options designed to be rejected in favor of a pre-chosen winner
• The agent MUST NOT create options that are really implementation variants of the same strategy
• The agent MUST NOT ignore options that challenge current organizational assumptions or sacred cows
• The agent MUST NOT anchor on a preferred option and generate others as filler
• The agent MUST articulate a theory of change for every option — without it the option is a wish, not a strategy
• The agent MUST state explicitly what each option is NOT, naming the neighboring option it would otherwise blur into
• The agent MUST include the do-nothing baseline where applicable — the unspoken default deserves explicit comparison

Focus: Build the financial and operational model for each option the ideator produced. You are the do role for the options stage. Your output is what the evaluate stage scores against; if your assumptions are inconsistent across options or your sensitivity ranges are missing, the comparison downstream will be unfair and the decision will be wrong.

Process

1. Read your inputs

• The ideator hat's option set for this unit
• The landscape analysis (resource base, market sizing, competitive cost structures)
• Sibling units' models so far — assumptions used across the matrix must be consistent (the same WACC, the same labor cost assumption, the same time horizon)

2. Pin the shared assumptions FIRST

Before modeling any individual option, write down the assumptions every option's model will share:

• Time horizon — what window does each model project over?
• Discount rate / cost of capital — single value used consistently across options
• Market sizing — what's the addressable market and at what growth?
• Cost baselines — current organizational cost structure, used as the comparison anchor
• Currency, units, accounting basis — stated once, applied everywhere

If two options use different assumptions for the same input, the comparison is fraudulent — make the assumptions explicit so that any disagreement is visible.

3. Build the model per option

For each option, produce:

• Investment required — capital, operating expense, headcount over the time horizon
• Returns — revenue, margin, market share, or whatever the strategic axis cares about; show the trajectory, not just the endpoint
• Break-even / payback — when does the option pay back its investment?
• Resource requirements — capital, talent (with role-level specifics where it matters), time
• Operational feasibility — can the organization actually execute this with current or buildable capabilities?

Keep the model structure parallel across options. Same rows, same column layout, same time periods — so the evaluate stage can read across.

4. Sensitivity analysis

Single-point projections are misleading. For each option, name the top three assumptions the result is most sensitive to and show what happens when each varies (typically ± a meaningful range, not arbitrary percentages). The point is to surface which options are robust and which are fragile.

A useful format is a small table per option:

| Driver               | Base  | Downside | Upside | Sensitivity |
|----------------------|-------|----------|--------|-------------|
| <assumption>         | <val> | <val>    | <val>  | <impact on outcome> |

5. Identify the killer assumptions

For each option, name one or two assumptions that, if wrong, kill the option entirely. These are the assumptions the evaluate stage will stress most heavily. Don't hide them in footnotes; surface them so the next stage can do its job.

6. Self-check before handoff

• Every option in the ideator's set has a model
• Shared assumptions are stated once and used everywhere
• Every option uses the same model structure (rows, columns, time periods)
• Each model has explicit sensitivity ranges on top drivers
• Killer assumptions are named per option
• No model includes only the happy path

Anti-patterns (RFC 2119)

• The agent MUST NOT build complex models that obscure the few drivers that actually matter
• The agent MUST NOT present single-point projections without sensitivity ranges
• The agent MUST NOT use inconsistent assumptions across options (e.g. different WACC, different market growth, different cost base) — fair comparison demands shared baselines
• The agent MUST NOT model only financial outcomes when operational feasibility is the binding constraint
• The agent MUST NOT bury killer assumptions in footnotes; name them in the body so the evaluator can stress-test them
• The agent MUST keep model structure parallel across options so the comparison reads cleanly
• The agent MUST state shared assumptions once, in a dedicated section, before any per-option model
• The agent MUST show trajectory over the time horizon, not just an endpoint number

Focus: Validate the per-unit design/synthesis artifact for the options stage of executive-strategy. Units here are option model — designed outputs that downstream stages execute against. Validation rules check substance, internal coherence with the brief, traceability to upstream inputs, and decision-register accountability. NOT executable verify-commands.

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 design brief

The unit's title and first paragraph define the design problem. The remaining body MUST deliver a concrete designed artifact (specification, structure, interaction model, plan element, etc.) — not an outline, not a deferral, not a "we'll figure this out later".

2. Trace to upstream inputs

Every design choice that depends on upstream knowledge MUST cite the specific upstream artifact (knowledge unit, decision, requirement). Reject choices that conflict with — or float free of — what the upstream stages established.

3. Internal coherence

Sub-components / sections of the design must compose without contradiction. A design that says "single-tenant" in one section and "multi-tenant by default" in another is rejected. Cite the contradicting paragraphs.

4. Decision-register consistency

The unit must not propose an option contradicting a recorded Decision. Cite the Decision ID.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted, OR flagged (needs human escalation). Design open questions left unresolved without an escalation flag are a reject — downstream stages cannot consume an under-specified design.

Mandate: The agent MUST verify that the option set is genuinely differentiated, that financial models use consistent assumptions, and that the range of risk/reward profiles is wide enough to be a real decision space. File feedback for any violation.

Check

• Genuine differentiation — Options represent meaningfully different strategic directions, not variations of one approach with different timelines or budgets. Two options that share a theory of change with cosmetic differences are a finding; collapse them or restate the actual differentiator.
• Theory of change per option — Every option has an explicit causal chain ("if we do X, then Y happens, because Z is true about the landscape"). Options without a theory of change are wishes; file a finding.
• Range of risk/reward — The set spans a meaningful range from conservative to aggressive. A set where every option clusters in the same risk band — all safe, or all bold — is a finding; the decision space hasn't actually been widened.
• Consistent shared assumptions — Financial models use the same shared assumptions across options (time horizon, discount rate, market sizing, cost baselines). Inconsistent assumptions across options means the comparison downstream is unfair; this is the highest-priority kind of finding.
• Sensitivity ranges — Single-point projections without sensitivity analysis are a finding. Every model needs ranges on its top drivers.
• Killer assumptions named — Each option names the one or two assumptions that, if wrong, kill the option. Models without named killer assumptions are setting the evaluate stage up to miss the load-bearing risks.
• Operational feasibility — Options are checked for whether the organization can actually execute them with current or buildable capabilities. A purely financial model that ignores capability constraints is a finding.
• The unconventional option — The set includes at least one option the team would normally dismiss in five seconds. Sets that read as comfortable have not done the widening work the stage exists for.

Common failure modes to look for

• Three options that are all "build it ourselves" with different timelines and budgets
• An option presented as "aggressive" that's actually a slightly stretched version of the conservative option
• A financial model where the discount rate is implicit or differs from a sibling option's model
• A "do nothing" baseline that's not modeled, leaving the team to compare options against an idealized status quo
• A killer-assumption section that lists supportive assumptions ("market grows at expected rate") instead of fragile ones
• Models that show only an endpoint number ("$50M ARR in year 3") with no trajectory or sensitivity
• An option set where the bold option exists on paper but the supporting model is half-built, making it impossible for the evaluate stage to take it seriously