Submit Saved Work for Review

Act as the author who has prepared and saved proposed policy work.

Before You Begin

Complete these prerequisites before submitting work:

• Save and inspect the proposed work.
• Confirm policy:edit and applicable owner/editor access through capabilities and grants.
• Identify the reviewer who will receive the policy identifier.

Submit Current Work

To submit the current saved work, follow these steps:

1. Open the saved policy in Policy Library.
2. Inspect its current draft content and validation findings.
3. Correct hard failures before continuing.
4. Select Submit for Review when Policy offers the action.
5. Supply reasoning and acknowledge only the current, permitted reviewable conflicts when prompted.
6. Confirm In Review in current policy detail. Submission changes the saved draft’s review status. It does not publish the policy.
7. Give the policy identifier to the separately authenticated reviewer.

Use a specific handoff message, such as: “Review this policy’s current submission, classification scope, and principal permissions.” Do not send credentials or ask the reviewer to reuse your browser session.

Direct API Handoff

For the application programming interface (API), use POST /policies/{policy_id}/submit relative to the configured API base. Refer to submission request examples.

For a direct API handoff, follow these request checks:

• Read GET /policies/{policy_id} before submitting.
• Put the exact current draft token in If-Match.
• Use reviewNotes and acknowledgedConflictIds only as the endpoint specifies.
• Do not send submittedBy. Policy derives the actor from authenticated identity.
• Check that the returned draft status is In Review and retain its new Draft-ETag value.

Do not substitute the governed-policy ETag for the current Draft-ETag. An entity tag (ETag) is a server-issued concurrency validator, not a permission or approval. Send the current Draft-ETag value in If-Match to bind the command to the current draft head. The head is the latest saved snapshot of proposed content and validation evidence. Treat tokens as opaque. Never construct or parse them. Submission changes the draft head. The reviewer must obtain the post-submission token rather than reuse your pre-submission token. Repeated saves and submission can change snapshot identity without creating a new governed revision.

Verify or Stop

Confirm In Review through policy detail and permitted history. An approval or publication event should not follow from submission alone.

If validation findings changed, read the new messages before acknowledging them. If Policy rejects a stale token, reload the policy and compare its content with the draft you intended to submit. Do not merely copy a fresh token onto an old decision. Compare the current content and findings first. If submission times out, inspect current detail before repeating it. Do not create a replacement policy to bypass an uncertain result.

Next, the reviewer follows review and approval. For returned work, follow correction and resubmission.