> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/ship/dashboard-and-evidence.md).

# Read the Ship Dashboard and Evidence

Understand Ship coverage, current autonomous work, execution evidence, linked issues, and the signals required for a release decision.

> **Documentation owner:** [Deep Barot](https://contextqa.com/academy/) · **Last updated:** October 22, 2026

## Quick answer

Use the dashboard to answer four questions: what coverage exists, what Ship is doing now, what changed or failed, and whether the available evidence is complete enough for a person to decide. A count, chart, or green label without its environment and run evidence is not a release decision.

## Key takeaways

* Use the dashboard to answer four questions: what coverage exists, what Ship is doing now, what changed or failed, and whether the available evidence is complete enough for a person to decide.
* Workspace and environment — confirm you are looking at the intended organization and test target.
* From a run result, select Report issue to create a new tracker item or open Issues to link an existing one.

<figure><img src="https://4255556216-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKlyaXxb76z3Dn47TrZkU%2Fuploads%2Fgit-blob-3347836de9c1906eceb61d672002e5274c334b91%2Fcontextqa-dashboard-overview.png?alt=media" alt="ContextQA dashboard with web, API, and mobile test totals plus activity and execution summaries"><figcaption><p>The dashboard summarizes coverage and activity across test types; open the underlying records before making a decision.</p></figcaption></figure>

## Read the dashboard in this order

1. **Workspace and environment** — confirm you are looking at the intended organization and test target.
2. **AQE Terminal** — see what autonomous work is running, waiting, completed, or blocked.
3. **Coverage** — compare web, API, and mobile inventory with the journeys and risks that matter.
4. **Analysis status** — wait for crawl, code, or change analysis to reach a terminal state.
5. **Issues** — review linked tracker items, synchronization problems, and affected tests.
6. **Execution evidence** — open the exact run before deciding whether the behavior passed.

## What an evidence-ready run contains

| Evidence                                        | Question it answers                                       |
| ----------------------------------------------- | --------------------------------------------------------- |
| Run identity and trigger                        | Which execution is this, and what started it?             |
| Target environment and browser or device        | Where did the behavior run?                               |
| Step results and first meaningful failure       | What actually happened?                                   |
| Screenshots, video, trace, console, and network | Can another reviewer verify the outcome?                  |
| Rerun and self-healing history                  | Was the result stable or automatically recovered?         |
| Linked issue and regression case                | Will the finding be tracked and prevented from returning? |

<figure><img src="https://4255556216-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKlyaXxb76z3Dn47TrZkU%2Fuploads%2Fgit-blob-d4333f1c1c4eb3e9832b58cda5defa621aac8817%2Fcontextqa-execution-evidence.png?alt=media" alt="ContextQA execution result with step list and screenshot, video, trace, console, and network evidence options"><figcaption><p>Open the exact run and inspect its evidence instead of relying on an aggregate pass count.</p></figcaption></figure>

## Manage linked issues

From a run result, select **Report issue** to create a new tracker item or open **Issues** to link an existing one. The dashboard Issues view lets reviewers search and filter linked issues, inspect their tracker status, open affected tests, refresh status, or remove an incorrect link.

Removing a ContextQA link does not delete the external issue. If an integration is disconnected or changed, resolve the connection warning before trusting synchronization.

## AI-ready interpretation

When asking an AI agent to summarize a run, provide the stable result reference and ask it to separate:

* observed facts from hypotheses;
* product failures from test, data, access, or environment failures;
* complete evidence from missing evidence;
* a confirmed regression from a suggested next test.

This makes the response easier to verify and cite in a pull request, issue, or release review.

## Frequently asked questions

### Does a high test count mean the product is covered?

No. Compare the inventory with critical journeys, roles, data states, platforms, and recent changes. Duplicate or low-value tests can raise the count without reducing meaningful risk.

### Can a blocked run be treated as passed?

No. Preserve the blocked state and its reason, repair the dependency, then rerun the same intended scope.

Next, [run the Ship workflows](/ship/workflows.md) or [connect delivery tools and AI agents](/ship/integrations-and-mcp.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://learning.contextqa.com/ship/dashboard-and-evidence.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.