> For the complete documentation index, see [llms.txt](https://docs.omics.ai/products/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.omics.ai/products/workbench/variant-interpreter/generating-a-report.md).

# Generating a report

Each analysis has a single clinical **report** — the signed-off conclusion of the interpretation. This page covers how the report is assembled, the sign-off workflow it moves through, and how amendments work after release.

## What's on the report

A report has two parts:

* **Findings** — the curated set of variants you're reporting. The candidate pool is every variant you've classified (see [Classifying variants](/products/workbench/variant-interpreter/classifying-variants.md)); you choose which of those to include and set their order. A variant's presence on the report *is* its inclusion — remove it to exclude it.
* **Body** — a single free-form, rich-text section for the clinical narrative. It autosaves as you type.

The report also records provenance automatically: reference genome, pipeline version, and caller versions for the analysis. See [Pipeline & caller versions](/products/workbench/variant-interpreter/pipeline-and-caller-versions.md).

## The sign-off workflow

A report moves through four phases. The flow separates *drafting* (any **Contributor**) from *sign-off* (an **Admin** with the **Sign Off Reports** capability), so a report can't be released without an authorized approval.

```
DRAFT ──Submit──▶ IN REVIEW ──Approve──▶ CLOSED (unreleased) ──Close──▶ CLOSED (released)
  ▲                 │   ▲                     │   ▲                          │
  └── Return to ────┘   └──────  Reopen  ─────┘   └──── Reopen (reason) ──────┘
       draft
```

| Phase                   | Meaning                                                 | Who acts next                        |
| ----------------------- | ------------------------------------------------------- | ------------------------------------ |
| **Draft**               | Being written. Findings and body are editable.          | Contributor submits.                 |
| **In review**           | Submitted, awaiting sign-off.                           | Admin approves, or returns to draft. |
| **Closed (unreleased)** | Approved and locked, but not yet released. Recoverable. | Admin closes to release, or reopens. |
| **Closed (released)**   | A signed version exists and can be downloaded.          | Admin may reopen to amend.           |

Available actions by phase:

* **Draft** → **Submit** (moves to In review).
* **In review** → **Approve** (Closed unreleased) or **Return to draft**.
* **Closed (unreleased)** → **Close** (releases a signed version) or **Reopen** (back to In review).
* **Closed (released)** → **Reopen** — requires a reason and starts an amendment.

{% hint style="info" %}
**Submit** and **Return to draft** are available to contributors. **Approve**, **Reopen**, and **Close** are **admin-only**; non-admins never see these buttons.
{% endhint %}

## Releasing and versioning

Closing a report from *Closed (unreleased)* releases an **immutable signed version**. The first release is version 1. The working report stays editable through reopen, but each released version is frozen and never changed.

## Amendments

To change a report after it has been released, an admin **reopens** it. Reopening a *released* report:

* requires a **reason**, and
* bumps the **amendment version** (v2, v3, …).

The reason is printed on the amended report's cover page. Once the amended report is re-approved and closed, it releases as the next version, preserving the earlier one.

## Audit trail

Every phase transition is recorded — the action, who performed it, when, and (for amendments) the reason. This activity log gives a complete, append-only history of how the report reached its current state.

## Downloads

A released report can be downloaded as **PDF**, **HTML**, or **JSON**.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.omics.ai/products/workbench/variant-interpreter/generating-a-report.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.