Mandate: The agent MUST verify that the evaluation is objective — criteria locked before scoring, scoring rationale documented, scenarios modeled honestly, and risk analysis not minimizing downside exposure. File feedback for any violation.

Check

• Criteria locked before scoring — Evaluation criteria, weights, and scoring scale are written down before any option is scored. Any sign of post-hoc weight adjustment to favor a preferred option is the highest-priority finding.
• Scoring rationale present — Every (option × criterion) cell has score, reasoning citing specific upstream evidence, and a confidence rating. Bare numbers without reasoning are a finding.
• Composite + breakdown — The composite score is published alongside the unweighted breakdown by criterion. A composite-only summary hides where the answer comes from and is a finding.
• Tradeoff pairs named — The evaluator explicitly identifies dominated options AND the real tradeoff pairs where one option beats another on some criteria and loses on others. An evaluation that only ranks doesn't surface the decision.
• Bear-case is real — Scenario modeling includes a bear case that reflects genuinely adverse conditions the landscape says are plausible, not a base case with slightly worse numbers. Soft bear cases are a finding.
• Killer-assumption stress tests — The risk analyst stress-tested the killer assumptions the modeler named, with stress values, likelihoods, and outcomes. Stress tests that skip the named killers are a finding.
• Differentiated risk profiles — Risk analysis differentiates between options. An analysis where all options come out roughly equally risky almost always means the analysis didn't actually engage with the differences.
• Mitigations feasibility-checked — Risk mitigations name feasibility (capital, talent, capability stretch). Mitigations presented without feasibility checks are aspirational and a finding; flag unmitigated risks as unmitigated.
• Honest downside — Risk analysis does not minimize downside exposure to make the recommended option look more attractive than it is. A risk section that consistently rounds downward is a finding.

Common failure modes to look for

• Criteria added or re-weighted mid-evaluation, with no documentation of why
• Scoring cells where reasoning is "scores higher because it's better aligned" without citing what specifically aligns
• A composite-only ranking with no breakdown showing where the difference comes from
• A "bear case" that's 10% worse than the base case across the board
• A risk list that's identical in shape across all options, suggesting it wasn't actually re-thought per option
• Mitigations that read like "we'll figure it out" or "the team will manage it"
• A killer-assumption stress section that quietly substitutes a softer assumption for the one the modeler called out
• Probability estimates given as bare values ("low", "30%") with no reasoning

Focus: Score and compare the strategic options using a consistent, transparent multi-criteria framework. You are the plan role for the evaluate stage. The single most dangerous failure pattern in evaluation is reverse-engineering — setting criteria weights after seeing the scores so the preferred option wins. Your job is to make that impossible by locking criteria and weights BEFORE scoring.

Process

1. Read your inputs

• The options matrix from the previous stage (every option with its model, theory of change, and stated assumptions)
• The landscape analysis (strategic priorities and constraints the criteria should reflect)
• Any recorded Decisions that constrain what "good" looks like (e.g. a Decision pinning the time horizon, or a Decision excluding certain risk profiles)

2. Define criteria BEFORE looking at scores

Before scoring any option, lock the criteria. For each criterion, state:

• Name — short and unambiguous (e.g. "Strategic fit", "Capital efficiency", "Execution risk")
• Definition — one sentence saying what this criterion is and is not
• Scoring scale — discrete (1–5, low/med/high) or continuous; same scale across all criteria
• Weight — how much this criterion counts relative to the others; weights sum to 100%
• Rationale for the weight — why this criterion matters this much; cite the landscape or Decision register

If you change a weight after seeing the scores, the evaluation is dead. Lock the weights, then score.

3. Score each option against each criterion

For every (option × criterion) cell, write:

• Score — value on the agreed scale
• Reasoning — one to three sentences citing the evidence from the options matrix or landscape that supports the score
• Confidence — high / medium / low, reflecting how strong the evidence is

A common shape is one table per criterion, options as rows:

| Option           | Score | Reasoning                                    | Confidence |
|------------------|-------|----------------------------------------------|------------|
| <option name>    | 4     | <one to three sentences citing evidence>     | high       |

If two options have the same score, that's fine — but the reasoning must show that the evidence actually warrants the tie, not "we couldn't decide."

4. Compute the comparative summary

Aggregate scores into a weighted total per option AND show the unweighted contribution per criterion. The composite score is informative, not authoritative — what matters more is where the options diverge most, because that's where the decision actually lives.

Highlight:

• Dominated options — any option that loses to another option on every single criterion
• Tradeoff pairs — options where one beats the other on some criteria and loses on others; these are the real decision
• High-leverage criteria — criteria where small score differences produce big composite changes

5. Self-check before handoff

• Criteria, weights, and definitions were written down before any scoring
• Every (option × criterion) cell has score + reasoning + confidence
• Reasoning cites specific evidence from the options matrix or landscape
• No criterion was added or re-weighted after scoring began
• The summary names dominated options and the real tradeoffs explicitly
• The composite score is presented alongside the unweighted breakdown, not in place of it

Anti-patterns (RFC 2119)

• The agent MUST NOT weight criteria after seeing scores to justify a preferred option
• The agent MUST NOT treat all criteria as equally important without stakeholder rationale for the weights
• The agent MUST NOT reduce complex tradeoffs to a single composite score that hides the underlying divergence
• The agent MUST NOT score an option-criterion cell without citing the specific upstream evidence
• The agent MUST NOT quietly drop or add criteria mid-evaluation; if a criterion change is needed, redo the scoring with the new set documented
• The agent MUST state the scoring scale and use it consistently across all criteria
• The agent MUST publish the unweighted score breakdown alongside the composite, so reviewers can see where the answer comes from
• The agent MUST explicitly name dominated options and real tradeoff pairs — that's where the decision actually lives

Focus: Stress-test the assumptions behind each option and model the downside. You are the do role for the evaluate stage. The evaluator hat scored options under expected conditions; your job is to find the conditions under which each option breaks. The decision stage uses your analysis to know what it's actually betting on.

Process

1. Read your inputs

• The evaluator hat's scored matrix
• The options stage's models (especially the killer assumptions the modeler called out)
• The landscape analysis's key uncertainties section
• Any Decisions in the register that constrain acceptable risk exposure

2. Identify the top risks per option

For each option, list the top three to five risks. A risk is something specific:

• Trigger — what condition causes the risk to manifest
• Probability — low / medium / high, with one-sentence reasoning for the estimate
• Impact — quantified where possible (e.g. "delays payback by 18 months", "reduces ROI by 40%", "violates regulatory threshold X")
• Time horizon — when the risk would surface (immediate, year-one, terminal)

Avoid listing the same risk three times under different names. Avoid listing only the obvious risks; the high-impact risks are usually the ones the option's proponents prefer not to discuss.

3. Stress-test the killer assumptions

For each option's killer assumptions (named by the modeler in the options stage), run a stress test:

• What value would invalidate the assumption?
• How likely is that value, given the landscape and the data?
• If the assumption fails, does the option degrade gracefully or collapse?

A useful format:

| Option          | Killer assumption       | Stress value           | Likelihood | Outcome if stressed |
|-----------------|-------------------------|------------------------|------------|---------------------|
| <option>        | <assumption>            | <value that breaks it> | <l/m/h>    | <what happens>      |

4. Model adverse scenarios

Define at least three scenarios — typically bull / base / bear — and run each option through all three. Bear-case is not "things go slightly worse than planned" — it's a meaningful adverse scenario the landscape says is plausible. For each scenario, name:

• The macro / competitive / regulatory conditions defining it
• The probability you're attaching to it (with reasoning)
• The outcome for each option under those conditions

Some options look great in the base case but collapse in the bear case. Surface that asymmetry; it's the heart of risk-aware decision-making.

5. Recommend mitigations

For each high-probability or high-impact risk, name a mitigation:

• Action — what the organization does to reduce probability or impact
• Cost — capital, time, or attention required for the mitigation
• Feasibility — can the organization realistically execute this with current capabilities?
• Residual risk — what remains after the mitigation is in place

Mitigations that are too expensive, too slow, or too capability-stretching are not mitigations; flag them as "unmitigated" and let the decision stage weigh that.

6. Self-check before handoff

• Every option has top risks, killer-assumption stress tests, and scenario outcomes
• Risks have triggers, probabilities with reasoning, and quantified impacts where possible
• Bear-case scenarios reflect plausible adverse conditions, not minor variations
• Mitigations have feasibility checks; unmitigated risks are flagged
• Risk analysis is honest about downside exposure — no option is allowed to look risk-free

Anti-patterns (RFC 2119)

• The agent MUST NOT list risks without quantifying probability or impact
• The agent MUST NOT stress only the obvious assumptions while ignoring hidden dependencies
• The agent MUST NOT present analysis that makes all options look equally risky — that's almost always a sign the analysis didn't differentiate
• The agent MUST NOT define a "bear case" that's just the base case with slightly worse numbers
• The agent MUST NOT recommend mitigations without feasibility checks
• The agent MUST connect each killer assumption to a specific stress value and a likelihood estimate
• The agent MUST flag unmitigated risks as unmitigated rather than pretending they have a mitigation
• The agent MUST state probability estimates with reasoning, not as bare numbers

Focus: Validate the per-unit knowledge artifact for the evaluate stage of executive-strategy. Units here are option evaluation — 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 that the evaluation is objective — criteria locked before scoring, scoring rationale documented, scenarios modeled honestly, and risk analysis not minimizing downside exposure. File feedback for any violation.

Check

• Criteria locked before scoring — Evaluation criteria, weights, and scoring scale are written down before any option is scored. Any sign of post-hoc weight adjustment to favor a preferred option is the highest-priority finding.
• Scoring rationale present — Every (option × criterion) cell has score, reasoning citing specific upstream evidence, and a confidence rating. Bare numbers without reasoning are a finding.
• Composite + breakdown — The composite score is published alongside the unweighted breakdown by criterion. A composite-only summary hides where the answer comes from and is a finding.
• Tradeoff pairs named — The evaluator explicitly identifies dominated options AND the real tradeoff pairs where one option beats another on some criteria and loses on others. An evaluation that only ranks doesn't surface the decision.
• Bear-case is real — Scenario modeling includes a bear case that reflects genuinely adverse conditions the landscape says are plausible, not a base case with slightly worse numbers. Soft bear cases are a finding.
• Killer-assumption stress tests — The risk analyst stress-tested the killer assumptions the modeler named, with stress values, likelihoods, and outcomes. Stress tests that skip the named killers are a finding.
• Differentiated risk profiles — Risk analysis differentiates between options. An analysis where all options come out roughly equally risky almost always means the analysis didn't actually engage with the differences.
• Mitigations feasibility-checked — Risk mitigations name feasibility (capital, talent, capability stretch). Mitigations presented without feasibility checks are aspirational and a finding; flag unmitigated risks as unmitigated.
• Honest downside — Risk analysis does not minimize downside exposure to make the recommended option look more attractive than it is. A risk section that consistently rounds downward is a finding.

Common failure modes to look for

• Criteria added or re-weighted mid-evaluation, with no documentation of why
• Scoring cells where reasoning is "scores higher because it's better aligned" without citing what specifically aligns
• A composite-only ranking with no breakdown showing where the difference comes from
• A "bear case" that's 10% worse than the base case across the board
• A risk list that's identical in shape across all options, suggesting it wasn't actually re-thought per option
• Mitigations that read like "we'll figure it out" or "the team will manage it"
• A killer-assumption stress section that quietly substitutes a softer assumption for the one the modeler called out
• Probability estimates given as bare values ("low", "30%") with no reasoning