Roles and Permissions
Authentication establishes who is making a request. Authorization determines whether that identity can perform the requested operation. Some commands also require access to the particular policy. A command capability answers whether an identity may perform an operation at all. A policy access grant answers whether that operation may affect this specific policy. Commands that require both checks must satisfy both.
Responsibilities Are Not New Roles
An author prepares and submits proposed work. A reviewer inspects a submission and can request changes with the required authority. An approver accepts the reviewed content with approval authority. An operator observes delivery and performs specifically authorized recovery tasks.
One person can hold multiple responsibilities.
Different users can also perform them with separate authenticated accounts.
The capability model does not itself enforce mandatory two-person approval.
There is no separate policy_reviewer role in the role bundles below.
Product Role Bundles
The following table summarizes each product role bundle and its key limitation:
| Role | Capability Scope | Important Limit |
|---|---|---|
policy_viewer | Grant policy:view. | Do not assume edit, review, approval, or restricted diagnostic access. |
policy_author | Add edit, rollback, compile, and preview capabilities. | Require an applicable policy grant for ordinary edit and rollback. Do not grant review or approval. |
policy_admin | Add review, approval, archive, audit, system configuration, and observability. | Do not treat this broad bundle as the default way to grant one responsibility. |
Platform permissions can map to capabilities separately from these role bundles. Their membership does not necessarily match the product bundles exactly. Ask the platform administrator to verify the effective authorities for your task. Unknown authorities do not create capabilities. An authority is a permission asserted by the trusted platform gateway. It is not a request field that clients may choose for themselves.
Command Capabilities
Use this table to identify the capability and policy boundary for each task:
| Task | Required Capability | Additional Boundary |
|---|---|---|
| Create, edit, or submit authored work | policy:edit | Require the applicable policy access grant for existing-policy edits and submission. |
| Roll back authored work | policy:rollback | Require the applicable policy access grant. |
| Refresh saved validation or request changes | policy:review | Do not substitute author ownership for review authority. |
| Approve a submission | policy:approve | Review the current draft and use its current concurrency token. |
| Archive a policy | policy:archive | Use the governed-policy validator and provide a reason. |
| Inspect retained operations or restricted validation diagnostics | policy:audit | Do not assume a support reference grants access. |
| Reconcile native ownership | policy:system-configure | Require additional archive authority for withdrawal decisions. |
| Inspect operational metrics | policy:observability | Do not assume system configuration authority includes metrics access. |
Retry authority follows the retained operation. Publishing retry requires approval authority. Withdrawal retry requires archive authority. Refer to recovery and reconciliation for the complete operation-specific rules.
Policy Access Grants
An owner or editor grant determines access to particular authored work.
It does not create review, approval, archive, or system configuration capabilities.
An author role also does not automatically grant edit access to every policy.
For example, policy:edit without an applicable owner/editor grant does not authorize an existing-policy edit.
An owner grant without policy:approve does not authorize approval.
Refer to policy access management for grant changes. Do not remove the last active owner during routine access maintenance. Administrator recovery is a separate audited path, not an ordinary grant substitute.
Identity and Downstream Access
Use the supported platform sign-in or gateway authentication path.
Policy records the authenticated actor. Clients must not impersonate another reviewer.
Do not supply submittedBy or approvedBy as a workaround.
Policy authority does not automatically create permission in a downstream system. An operator may need separate integration and target access. Refer to security settings and API authentication.
Continue with lifecycle and governance.
Feedback
Was this page helpful?