# Review and release a system version

> Submit a Draft system version for review, record reviewer decisions, and verify the released signoff record.

Canonical URL: http://modelmonster.ai/docs/managing-systems/system-review-workflow/

## Article Metadata

- Reading time: 7 min

Before a `Draft` can become an `Active` system version, contributors submit it and assigned reviewers decide whether it is ready to release. This guide shows you how to submit a version, record decisions, follow notifications, cancel a round, and verify signoff. Approval records your organization's release decision; it does not replace any legal, security, regulatory, or operational review your process requires.

## Understand what review changes

![Version and review states from Draft through In review to Active, rejection, cancellation, and completion](/media/original_images/visual-1-version-review-states.png)

System version review is a unanimous human release gate. Every person assigned to a review must approve before the reviewed version becomes `Active`.

The workflow tracks two related states:

- **Version lifecycle:** A version moves from `Draft` to `In review`, then becomes `Active` after final approval or returns to `Draft` after rejection or cancellation.
- **Review resolution:** The review remains open while decisions are pending, then resolves as `Completed`, `Rejected`, or `Review cancelled`.

For example, suppose a review has two assigned reviewers. After the first reviewer approves, their decision becomes `Approved`, but the other reviewer remains `Pending`. The version stays `In review` until the second reviewer approves.

A previous version can remain `Active` while a newer version is `In review`. The newer version does not replace the released version until its review is complete. The completed review preserves who approved the release, but organizations should still perform any other validation and professional review their processes require.

## Check that the Draft is ready for review

From **Systems**, open the system and select **Overview**. Start with the readiness banner and summary cards: they show the version state and call out unresolved policy violations, policy warnings, and unanswered use-case questions. Follow the links from Overview to inspect the underlying details.

![Draft Overview showing readiness warnings, policy health, use-case gaps, and Submit for review](/media/original_images/visual-2-overview-readiness.png)

Before submitting, check that:

- **Blueprint** represents the system's relevant boundary, important components and resources, and the connections and operations reviewers need to understand.
- **Use Case** explains the business and deployment context that the model alone cannot show, with the questions relevant to this system answered.
- **Execution Flows** and policy results do not contain unresolved issues that should be addressed before release.
- Assumptions, limitations, and uncertainties that affect the review are recorded where they belong: in **Use Case** for business or deployment context, in a component's **Notes** or a resource's **Description** for model-specific details, and in **Documentation** for supporting evidence. Use the optional submission comment to draw reviewers' attention to anything important for this review round.
- A knowledgeable contributor has compared the model with the real system, including relevant code, configuration, runtime behavior, and supporting evidence.

Readiness depends on the system and the purpose of the review. Overview helps you find likely gaps, but it does not replace judgment or the detailed workspace tabs.

When you are satisfied with the Draft, confirm that **Submit for review** is available. If the primary action is **Finalize draft** instead, your organization releases Drafts without a review round, so this workflow does not apply. Unresolved readiness items are normally warnings that you can submit with; if your organization requires them to be resolved first, Overview identifies what is blocking submission and links to the relevant area.

## Submit the version for review

1. Select **Submit for review**.
2. If reviewers need context, enter it in **Comment (optional)**.
3. Check **Reviewers for this submission**. Applicable default reviewers are already included and cannot be removed from this submission. You may not review your own submissions.
4. If other people should review the version, select eligible people under **Additional reviewers**.
5. Select **Submit**.

Submitters cannot review their own submissions, so the final reviewer list must include at least one other eligible person. Organization administrators are eligible reviewers, as are people with `Reviewer`-or-higher access on the system's team. If no one else is available, ask an administrator to give an appropriate reviewer access before trying again.

![Submit for review dialog with comment, assigned reviewers, submitter exclusion, and additional reviewer](/media/original_images/visual-3-submit-review-dialog.png)

After submission, the version becomes `In review`, the primary action becomes **Open review**, and the review appears as pending work. The submitter receives **Submitted for review**, while each assigned reviewer receives **Review assigned**.

The assigned reviewer list is fixed for this review round. Later changes to settings or access do not rewrite the open assignment.

> **Note:** If the wrong people are assigned, cancel the review and correct the list before submitting a new round.

The platform will also email an applicable notification when email delivery is enabled, the recipient has an email address, and their **System Version Reviews** email preference is enabled.

## Open and inspect the review

The **Review** dialog is the shared place where contributors inspect the submission and assigned reviewers record decisions. You can open it in any of these ways:

- From the system, select **Open review**.
- From **Systems**, open the item under **Pending Reviews**.
- From Dashboard notifications, open **Review assigned** as a reviewer or **Submitted for review** as the submitter.

![Review dialog showing pending assigned reviewers and Approve and Reject actions](/media/original_images/visual-4-pending-reviewer-dialog.png)

Use the dialog to inspect the submission details, the contributor's optional comment, the assigned reviewers, how each reviewer was assigned (shown as their source), and each current decision, such as `Pending` or `Approved`.

> **Warning:** The system cannot be edited while it is `In review`. Complete or cancel the review before editing so you do not enter work into a version that cannot accept saved changes.

Reopen the retained **Review** after a decision and use its resolution as the authoritative outcome.

## Record a reviewer decision

Only people assigned to the review round can use the ordinary **Approve** and **Reject** actions.

### Approve the version

1. In **Review**, select **Approve**.
2. In **Approve review**, optionally enter an **Approval comment (optional)**.
3. Select **Approve**.

Your decision becomes `Approved`. If another assigned reviewer remains `Pending`, the version stays `In review`, and the submitter receives **Review approved**.

![Review dialog showing one approved reviewer, one pending reviewer, and the version still in review](/media/original_images/visual-5-partial-approval.png)

If yours is the final required approval, the review becomes `Completed`, the version becomes `Active`, and the submitter receives **Review completed** instead of another **Review approved** notification. The completed review displays **Review completed** and “All required reviewers finished this review round.”

### Reject the version

1. In **Review**, select **Reject**.
2. Enter a clear **Rejection comment** that explains what needs to change.
3. Before confirming, note that rejection closes this review round and returns the version to `Draft`.
4. Select **Reject**.

![Reject review form with a clear rejection comment describing missing release evidence](/media/original_images/visual-6a-rejection-comment.png)

![Rejected review resolution showing the recorded comment and version returned to Draft](/media/original_images/visual-6b-rejected-resolution.png)

The submitter receives **Review rejected**. After making the requested changes, the contributor must start a new review round for the next release attempt.

When enabled for the recipient, email may mirror **Review approved**, **Review completed**, or **Review rejected**.

## Cancel a review that should not continue

Use cancellation when an open review is obsolete or has the wrong assignment.

1. In the open **Review** dialog, select **Cancel**.
2. If helpful, enter a **Cancellation reason**.
3. Before confirming, note that cancellation closes the active review and returns the version to `Draft`.

![Cancel review form explaining that cancellation returns the version to Draft](/media/original_images/visual-7-cancel-review-confirmation.png)

4. Select **Cancel review**.

The review resolves as `Review cancelled`, and the retained review remains readable. The submitter receives **Review cancelled**, with an email notification if enabled.

## Verify the outcome and signoff record

Reopen the retained **Review** and check its resolution:

- `Completed` means the reviewed version should be `Active`.
- `Rejected` or `Review cancelled` means the version should be available again as `Draft`.

![Completed review showing both approvals, the Active version, and the completion resolution](/media/original_images/visual-8-completed-review.png)

For a completed review, inspect the released version and its signoff record:

1. Open **Overview** or **System Versions** and locate the released version.
2. Select **View archive**.
3. Open **Reports**.
4. Select **Signoffs Attestation**.

![Archived report preview showing the Signoffs Attestation with reviewer source, approval, and decision time](/media/original_images/visual-9-signoffs-attestation.png)

The rendered **Signoffs Attestation** preserves the submission and reviewer decision history, including each reviewer's source, decision, and decision time. Use this attestation together with the retained review as evidence that the review completed.

> **Note:** If an assigned reviewer loses eligibility during an open round, an organization administrator can recover the round with **Remove reviewer** or **Approve on behalf**.

## Continue with the released or returned version

If the version is `Active`, use version history and its archive to inspect the released snapshot. If the version returned to `Draft`, make the needed changes and submit a new review round when it is ready.

![System Versions page showing an Active reviewed version and the View archive action](/media/original_images/visual-10-active-version-history.png)

Continue with:

- [System Versioning Model](/docs/managing-systems/system-versioning-model/) — understand current and historical versions, released snapshots, and archives.
- [Reports](/docs/reporting-and-artifacts/reports/) — learn how to use the Reports surface that contains the rendered **Signoffs Attestation**.