Review and Decide on a Submission

Authenticate as the reviewer, using your own account.

Before You Begin

Complete these prerequisites before reviewing a submission:

• Obtain the submitted policy identifier from the author.
• Confirm policy:review to inspect saved validation and request changes.
• Confirm policy:approve if you will approve the submission.

An owner/editor grant does not supply either capability. Refer to authority requirements.

Inspect the Current Submission

To inspect the submitted policy, follow these steps:

1. Open the policy identifier that the author handed off.
2. Confirm that the current draft remains In Review.
3. Inspect classifications, principals, methods, and permissions.
4. Inspect the current validation findings.
5. Read permitted history and the author’s review reasoning.

For direct application programming interface (API) use, read policy detail and GET /policies/{policy_id}/validation under your reviewer identity. Saved validation returns the exact current head and its Draft-ETag. The head is the latest saved snapshot in the proposal. The entity tag (ETag) is a concurrency validator, not approval evidence. Use that current token for the decision. Do not reuse the author’s pre-submission token.

If dependencies or findings changed, review them again. Resolve non-overridable failures through author correction. Only explicitly reviewable conflicts permit acknowledgement with reasoning.

Request Changes

To request changes to the submission, follow these steps:

1. Select Reject when the action is available.
2. Enter a nonblank reason that names the correction and expected result.
3. Confirm the request. Policy returns editable work while preserving its content.
4. Give the author the policy identifier and correction request.

For example: “Use a title that identifies the protected classification and intended principal.” The current application programming interface limits this reason to 512 characters. Keep the reason actionable rather than pasting an entire investigation.

For direct clients, use POST /policies/{policy_id}/request-changes with reason and the current draft token in If-Match. The response contains a new token in its draft summary. There is no separate reject endpoint.

The Panel labels this request-changes action Reject. Open Change History and check that the request records your reason and user identity. The interface can label the returned proposal Rejected. The author can still edit that work. Any previously approved version remains unchanged. Returned work awaits author correction. Resubmitted work has entered In Review again and needs a new review. The author continues with correction and resubmission.

Approve the Reviewed Submission

Proceed only after reviewing the current submission, including any resubmitted corrections. You must hold approval authority, even if you previously requested changes.

To approve the reviewed submission, follow these steps:

1. Refresh the policy’s current submitted content and findings.
2. Confirm that no hard failures remain.
3. Acknowledge only the required, permitted current conflicts.
4. Select Approve Policy on the review page.
5. Enter nonblank review notes that explain the decision.
6. Confirm approval. Policy creates the governed revision and queues asynchronous publication.
7. Reload the policy and open Change History to check the approved version, your user identity, and your notes.

For direct clients, use POST /policies/{policy_id}/approve with reviewNotes and applicable acknowledgedConflictIds. Put the exact reviewed draft token in If-Match. Do not send approvedBy. Policy records your authenticated identity. Refer to API reference.

Stop Conditions

Stop when the draft changed, the token became stale, or new findings appeared. Reload the policy and validation results, then review any changed content before deciding again. Do not acknowledge hard failures or approve an older copied submission. If approval or rejection times out, check Change History for the decision before sending it again.

Approval starts background publication of the reviewed configuration. Continue with delivery verification.