Review and release a system version

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

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.

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.

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.

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.

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.

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.

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.

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.

1. 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.

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.

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.

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.

Continue with:

• System Versioning Model — understand current and historical versions, released snapshots, and archives.
• Reports — learn how to use the Reports surface that contains the rendered Signoffs Attestation.