---
title: "Roadmap evidence check"
description: "Find the initiatives and Projects on the roadmap that have little customer evidence in Deck, and link the evidence that Deck already has."
url: "/docs/agents/workflows/roadmap-evidence-check"
---

This page is an agent-readable workflow for Deck. Humans can follow along. Coding agents should treat the steps as the source of truth.

# Roadmap evidence check — agent workflow

* **Use it when:** the user asks "which roadmap items have no customer evidence?", "is our roadmap backed by feedback?" or "what are we building on gut feel?"
* **Outcome:** each roadmap item in scope has an evidence status, with Deck's counts and links. Evidence that Deck has but did not link is linked, if the user says yes.
* **Needs:** Deck MCP. The check only reads. Links to evidence are optional writes. Subtheme search needs the Starter plan or higher.

## 1. Probe Deck MCP

Call `get_user_context`. This must be a real tool call.

* 401 Unauthorized: tell the user to connect Deck MCP in this client (Settings → Connections). Stop.
* No Deck tools: fetch and follow [https://docs.getdeck.io/docs/agents/getting-started/prompts/ai-pm.md](https://docs.getdeck.io/docs/agents/getting-started/prompts/ai-pm.md). Stop this workflow until the tools work.

## 2. Set the scope and the threshold

Ask the user for the scope. Typical answers are all active work, one initiative, one owner, or one segment.

Ask for the evidence threshold. The default is fewer than 3 linked insights. The Deck Backlog page uses the same line: it hides opportunities with fewer than 3 pieces of evidence.

Roadmap items that are only in Linear or Jira have no Deck evidence. Import them first with [Import the Linear roadmap](/docs/agents/workflows/import-linear-roadmap) or [Import Jira epics](/docs/agents/workflows/import-jira-epics).

## 3. Read the roadmap

Make these calls at the same time. Add the filters that the user named, for example `owner` or `segment_id`. For one initiative, call `explore_build_initiatives` and add `initiative_id` to `list_projects`.

* `list_initiatives` with `status: "active"`. Read `leveraged_insights_count` and the Projects of each initiative.
* `list_projects` with `status: "not_started"`.
* `list_projects` with `status: "in_progress"`.

Each Project row has `evidence_count` and `external_link`. Page with `offset` or `cursor` until you have every item in scope.

## 4. Shortlist the thin items

Put an item on the shortlist when Deck's count is below the threshold. Do not compute a count of your own.

Open each shortlisted item. Make these calls at the same time:

* A Project: `explore_build_projects` with `project_id`. Read the evidence, the linked opportunity and the parent initiative.
* An initiative: `explore_build_initiatives` with `initiative_id`. Read `leveraged_insight_ids`, `evidence_provenance` and the Projects. An initiative can have little evidence while its Projects have a lot. Report both counts as Deck gives them.

## 5. Look for evidence that Deck already has

For each thin item, take 2 or 3 keywords from its title and description. Make these calls at the same time:

* `search_deck` with `query`. It returns matching insights, themes, subthemes and opportunities, each with a link.
* `explore_insights` with `query`. Add `segment_ids` when the item has segments.
* `explore_themes` with `query`.
* `explore_subthemes` with `query`. On the Free plan this returns `feature_unavailable`. Then skip it.

A keyword match is a candidate, not proof. Before you propose a link, read the insight with `explore_insights` and `insight_id`. Keep only insights that support the item.

To see related opportunities, call `explore_opportunity_backlog` with `min_evidence: 0`. An opportunity with evidence can back the item.

## 6. Report

Give each item one status:

* **Evidence found, not linked:** Deck has supporting insights or an opportunity that the item does not link. List them.
* **Thin evidence:** Deck has a few related insights. Give Deck's counts.
* **No evidence in Deck:** no search found support.

Show one table: item, type, Deck's evidence count, status, candidate evidence with links, and a recommendation. Some items have no customer evidence for a good reason, for example security, compliance or platform work. Say so when the description shows it. Do not call an item wrong because it has no evidence.

## 7. Link the evidence (optional)

Show the exact links that you will make and get a yes. Then make one call for each item:

* A Project: `add_project_insights` with `project_id`, `insight_ids` and a short `reason`.
* An initiative: `add_initiative_insights` with `initiative_id` and `insight_ids` (1-100).

Then read Deck's new count and report it. For a Project, call `list_projects` again and read `evidence_count`. For an initiative, call `explore_build_initiatives` again and read `leveraged_insights_count`.

`generate_project_evidence_story` rewrites the Evidence section and spends credits. Call it only when the user asks for it, and get a yes each time.

## Rules

* Show the plan and get a yes before you call write tools.
* Quote Deck's numbers. Do not compute your own.
* Use only insight IDs from Deck results. Never invent IDs.
* Link an insight only after you read it and it supports the item.
* Low evidence is a signal to check, not a verdict. Recommend customer research when Deck has no evidence.
* If the user has more than one Deck organization, call `select_organization` first and pass `org_id` on every call.

## Done when

* Each item in scope has a status and Deck's evidence count.
* Each candidate insight, theme or opportunity in the report has a Deck link.
* The links that the user approved are written, and the new counts come from Deck.

See also: [Initiatives](/docs/features/initiatives), [Projects](/docs/features/projects), [Opportunity Backlog](/docs/features/opportunity-backlog) and [Model Context Protocol](/docs/integrations/mcp).

---

[View full sitemap](/docs/sitemap)