> 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/sign-off-and-release.md).

# Sign-off, release & amendments

A report moves through four phases, shown as steps at the top of the Report tab. The flow separates *drafting*, which any contributor can do, from *sign-off*, which needs an admin with the **Sign Off Reports** capability. A report can't be released without an authorized approval.

```
DRAFT ──Submit for review──▶ UNDER REVIEW ──Approve──▶ SIGNED OFF ──Close (release)──▶ RELEASED
  ▲                               │                        │                              │
  ├──────── Return to draft ──────┘                        │                              │
  ├──────────────────────── Reopen ────────────────────────┘                              │
  └──────────────────────────────────── Reopen (reason required) ─────────────────────────┘
```

| Phase            | Meaning                                                                  | Next step                                                                       |
| ---------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------- |
| **Draft**        | Being written. Findings and wording can be changed.                      | A contributor clicks **Submit for review**.                                     |
| **Under review** | Awaiting sign-off. The report document is frozen and locked for editing. | An admin clicks **Approve**, or anyone who can edit clicks **Return to draft**. |
| **Signed off**   | Approved, but not yet released.                                          | An admin clicks **Close (release)**, or **Reopen** to return it to Draft.       |
| **Released**     | A signed version exists and can be downloaded.                           | An admin can **Reopen** it to issue an amendment.                               |

## Who can do what

| Action                                       | Capability                                 |
| -------------------------------------------- | ------------------------------------------ |
| **Submit for review**, **Return to draft**   | **Manage Cases** (contributors and admins) |
| **Approve**, **Reopen**, **Close (release)** | **Sign Off Reports** (admins only)         |

Buttons you can't use aren't shown. Viewers see a read-only note instead.

## Review and approval

1. The contributor finishes the report and clicks **Submit for review**. The report moves to **Under review**, and its document is frozen: the findings, classifications, wording, and letterhead are fixed as they stand.
2. The admin reviews the report, using **Preview** to read the full document. Also check, in the sample drawer, that the workflow and caller versions match the lab's validated configuration. See [Pipeline & caller versions](/products/workbench/variant-interpreter/pipeline-and-caller-versions.md).
3. The admin either:
   * clicks **Approve** to sign off the report, or
   * clicks **Return to draft** to send it back for more work.

Because the document is frozen at submission, what the admin reviews is exactly what will be released; later reclassifications, template edits, or branding changes don't alter it. If the report changes phase while the admin is reviewing it (for example, someone returns it to draft), the approval is refused and the admin is asked to review the updated report. Returning a report to draft or reopening it discards the frozen document, and it's frozen again on the next submission.

## Releasing

From **Signed off**, the admin clicks **Close (release)**. Workbench completes the approved document with the release date, the signer's name, the date and time signed, and the version, then releases it as an **immutable signed version** in PDF, HTML, and JSON.

The first release is **Version 1**. A released version never changes. Later changes to classifications, templates, or branding don't affect it.

## Downloading a released report

Once a report is released, click **Download** on the Report tab and choose **PDF**, **HTML**, or **JSON**. Downloads are the exact files frozen at release.

Reports can't be downloaded before they're first released. To see a report before release, use **Preview**.

## Amendments

To change a report after it's been released, an admin reopens it:

1. Click **Reopen**.
2. Enter the **Reason for reopening a released report**. The reason is printed on the amended report.
3. Click **Confirm reopen**.

The report returns to **Draft** as the next amendment. While the amendment is in progress, a banner shows which version was last released, with a button to download it. Edit the report, then submit, approve, and release it as before. Each release after the first is labelled with its version number: the first amendment is **Amendment 2** (superseding version 1), the next **Amendment 3**, and so on. Only the most recent released version can be downloaded.

{% hint style="info" %}
Reopening a report that is **Signed off** but not yet released doesn't need a reason and doesn't create an amendment. It returns the report to Draft.
{% endhint %}

## Activity

Click **Activity** on the Report tab to see the report's audit trail, newest first. Each entry records the action, who performed it and when, and, for reopened reports, the reason. Entries include:

* Draft created
* Submitted for review
* Returned to draft
* Approved & signed off
* Report reopened
* Report closed (released)

Report templates and report branding keep their own activity history. See [Report templates](/products/workbench/variant-interpreter/generating-a-report/report-templates.md) and [Report branding](/products/workbench/variant-interpreter/generating-a-report/report-branding.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://docs.omics.ai/products/workbench/variant-interpreter/generating-a-report/sign-off-and-release.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.