Policy Lifecycle and Governance

Authors submit drafts. Reviewers request changes or approve them. Approval creates an approved version, called a governed revision, and starts background publication. Each saved snapshot records proposed content and validation evidence. The latest saved snapshot is the draft head. Several snapshots can belong to one open proposal without creating several governed revisions. Delivery runs asynchronously afterward. Keep drafts, governed revisions, and protection states separate throughout this journey.

Actors, Capabilities, and Policy Grants

The following names describe responsibilities, not additional product roles.

The table summarizes each governance responsibility, its required authority, and its limit:

The policy_author authority supplies author capabilities, not review or approval. The policy_viewer authority supplies viewing capability. The policy_admin mapping includes broader review, approval, and recovery capabilities. Do not grant it merely to reproduce this example. Use your deployment’s approved authority and gateway-permission mappings.

Owner/editor grants establish policy resource access. They do not supply command capabilities. An author role mapping alone does not prove that the caller holds a grant on an existing policy. Review and approval remain distinct capabilities even when one approved mapping supplies both. Policy does not define a separate policy_reviewer role. Refer to roles and permissions.

Follow the Handoff

To complete the separate-user author and reviewer handoff, follow these steps:

1. As Alex, save a Data or artificial intelligence (AI) draft.
2. As Alex, submit current saved work.
3. As Morgan, review the submission using a separate authenticated account.
4. As Morgan, request changes with an actionable reason.
5. As Alex, correct and resubmit.
6. As Morgan, approve the new reviewed head.
7. Follow publication and target-specific evidence.

Use separate authenticated accounts for this example. Never share credentials or send another user’s name as the audit actor. Your organization may impose additional separation-of-duties rules. This example does not claim that Policy mandates different people for every command.

Manage Policy Access

An authorized owner can manage active owner/editor grants through the application programming interface (API) access operations. Listing grants requires policy:view. Creating or revoking grants requires active ownership or authorized administrator recovery, not an editor grant alone. Do not assume the Panel exposes every access-management operation.

Before changing access, ask a Protegrity Provisioned Cluster (PPC) user with administrator permissions to confirm the recipient’s identity mapping. For a user grant, use the exact gateway-verified login username. For a role grant, use an authority the gateway actually forwards for the intended accounts. This can be a permission name, not a PPC role’s identifier or display name. Do not substitute opaque PPC account identifiers, display names, or runtime principals from the authoring catalog. Never supply or spoof gateway identity headers. Follow the subject identity rules and access operations. After a change, list grants again to confirm the intended active owner/editor entry. Listing confirms persistence, not effective recipient access.

Preserve a valid owner when removing access. During an approved handoff, have the recipient confirm intended access using their own authenticated account through the supported workflow. For ownership transfers, confirm ownership-management access before removing the previous owner’s access. An editor grant does not authorize ownership administration by itself. Do not broaden roles to solve a missing policy grant. For owner-recovery cases, involve an authorized administrator using the audited recovery path.

Change or Retire Governed Work

Editing a governed policy leaves its current approved revision unchanged. Normal Edit resumes existing open work. Refer to rollback or archive only for their distinct purposes. Inspect history before making either decision.

Automatic recompilation can create compilation minors without changing author intent. A compilation minor is a recompilation within the same governed revision, not another approval of changed intent. Refer to automatic recompilation. For a complete example, follow your first policy.