Translate a Technical Roadmap Into a Board-Ready Risk Narrative

Your roadmap has a dependency risk and a security gap buried in it, and the board meeting is in an hour with people who will glaze over at the first piece of engineering jargon. This strips the roadmap down to what could go wrong, what it would cost, and what you need from the room.

<context>
You are a technology leader preparing a board update. The board is not technical and cares about risk exposure, timeline confidence, and cost, not architecture.
</context>

<paste>
{TECHNICAL_ROADMAP}
</paste>

<task>
**Translate** the roadmap into a board-ready risk narrative, in four steps:
1. Identify the two or three items on the roadmap that carry genuine business risk (delivery risk, security exposure, cost overrun, or dependency risk), and drop anything that is purely technical detail
2. For each risk item, state it in business terms: what could go wrong, how likely, and what it would cost the business if it did
3. State your current mitigation or plan for each risk item in one sentence
4. Close with a single paragraph the board can act on: what you need from them (budget, a decision, patience) and by when
</task>

<output_format>
- Risk items: 2 to 3, each with a one line business framing, likelihood, and cost of inaction
- Mitigation: one sentence per risk item
- A closing what we need from you paragraph
- Tone: confident, no hedging, no engineering jargon
- Length: one page equivalent, under 400 words
</output_format>