Work With Policies

• 1: Author Data Policies
• 1.1: Configure a Data Policy
• 1.2: Save and Validate a Data Draft
• 2: Author Artificial Intelligence Policies
• 2.1: Configure Artificial Intelligence Protection
• 2.2: Preview and Save an Artificial Intelligence Draft
• 3: Policy Lifecycle and Governance
• 3.1: Submit Saved Work for Review
• 3.2: Review and Decide on a Submission
• 3.3: Correct Returned Work and Resubmit
• 3.4: Restore Policy Intent or Retire a Policy
• 4: Monitor Delivery and Withdrawal
• 4.1: Verify Data Delivery Evidence
• 4.2: Verify Federated Guardrails Delivery Evidence
• 4.3: Inspect Delivery Issues and Verify Withdrawal
• 5: Create and Review Your First Policy
• 6: Common Policy Workflows
• 7: Policy Working Practices
• 8: Policy Use Cases
• 9: Inspect and Use the Policy Library
• 10: Policy Authoring Procedures
• 11: Policy Lifecycle Operations
• 12: Policy Integration Flows

1 - Author Data Policies

Use the Data journey to configure protection for discovered data. Classification scope selects data categories and their applicable discovered locations. Principal scope identifies who receives the configured target permissions. The current authoring lane enables Encryption. Standalone Masking and Filtering choices remain Coming Soon.

Before starting, prepare access and catalog inputs. Use your deployment’s supported principals and native integration. Do not create a policy against invented catalog identities.

To author and verify a Data policy, follow these steps:

1. Configure scope, principals, and protection.
2. Save and inspect validation.
3. Submit the exact saved draft.
4. Hand off to an authorized reviewer and approver.
5. Verify Data delivery.

Saving incomplete work does not make it eligible for submission. The current governed revision, which records approved intent, remains unchanged until approval. Draft edits do not replace that revision or prove a change in target protection. Refer to states and revisions.

For a complete worked handoff, follow your first policy.

1.1 - Configure a Data Policy

Configure a narrowly scoped Data policy before saving its first draft. Scope means the selected classifications, applicable discovered data, and intended principals. Act as an authorized author, not as the eventual reviewer.

Before You Begin

Refer to access requirements and complete example preparation.

Complete these prerequisites before configuring Data protection:

• Identify one discovered classification and one supported principal.
• Use nonproduction inputs that your organization permits you to protect.
• Ask the Traverse administrator to confirm the classification’s tables or columns if its meaning is unclear.

Select Classifications and Principals

To configure the Data policy scope, follow these steps:

1. Open Policy Library.
2. Select Data Protection Policy from the creation choices. The authoring form opens. Navigation alone does not save a policy.
3. Select the classification that identifies your prepared data. The selected classification defines the data scope for this draft.
4. Select the supported principal that should receive access. Use its catalog identity, not a similarly named replacement.

The principal receives permissions at the protection target. It need not be the signed-in Policy author. Policy edit authority does not grant that author access to protected data.

Choose all principals only when your intended scope explicitly requires it. Switching between explicit identities and wildcard scope changes policy meaning. Reinspect permissions after changing that selection. Do not use wildcard scope to work around an unsupported principal.

If classifications or principals cannot load, stop before submission. Send the error to the Traverse integration administrator to investigate missing discovery or identity data. Never replace missing identities with guessed values.

Configure Protection and Permissions

To choose the protection method and permissions, follow these steps:

1. Select Encryption. The current Data lane does not enable standalone Masking or Filtering.
2. Inspect the recommended protection settings for each classification. Recommendations depend on current discovery and integration context.
3. Choose the supported settings that match your organization’s protection requirements.
4. Assign the required permissions for each selected principal.
5. Review the generated title.
6. Enter a meaningful title if your workflow requires a clearer name.

For each principal, choose at most one read mode: cleartext, protected, or null. Cleartext returns readable data. Protected returns a token or ciphertext rather than cleartext. Null returns a null value instead of the protected value. Protection and reprotection permissions remain independent of the read mode. A principal selection alone does not supply an action permission. Turning off every read mode does not imply a cleartext grant.

Avoid wildcard scope for the first Data exercise. Do not infer a principal-specific permission from an absent matrix row. Inspect compiler findings and the saved policy before relying on any grant.

Check Scope Before Saving

Confirm the classification, principal identities, method, and permissions together. If you change scope, revisit the permission rows and title. A title does not prove that the underlying selections remain complete.

Stop when recommendations, schema checks, or principal compatibility fail. Do not substitute a Coming Soon method or a different identity. If the finding describes discovery or Policy Integration Manager (PIM) configuration rather than a form field, send it to the administrator of that integration.

Next, save and inspect the draft. Refer to authoring choices for shared concepts.

1.2 - Save and Validate a Data Draft

Save retains authoring work without replacing the current governed revision. The governed revision records approved intent. The draft records proposed changes. Compilation checks authored inputs and derives target-specific rules and validation findings. It does not publish those rules.

Before You Begin

Complete these prerequisites before saving the draft:

• Use your author account with edit capability and applicable owner/editor access.
• Configure the Data policy.

Save Proposed Work

To save the proposed policy work, follow these steps:

1. Review the title, classifications, principals, and protection permissions.
2. Select Save Draft. Policy compiles the current inputs before saving.
3. Inspect the returned notice. A successful Save returns you to the Library.
4. Reopen the policy in Policy Library.
5. Confirm the saved scope and draft status.

Record the policy identifier for later review and support. A successful Save can retain compiler findings or incomplete semantic work. It does not prove submission readiness, approval, or target delivery. Repeated saves retain snapshots within the same proposed revision. A snapshot records saved content and its validation evidence at that point. The latest snapshot is the draft head. Another Save advances that head, not the governed revision.

Inspect Findings

To review the saved validation findings, follow these steps:

1. Inspect outstanding exceptions and validation feedback for the saved draft.
2. Correct missing permissions, invalid scope, or unsupported selections.
3. Save the corrected work.
4. Reopen the saved draft to confirm the correction.

Do not assume that an unavailable or stale validation count means zero findings. Submission and approval revalidate current dependencies. Only explicitly reviewable conflicts permit acknowledgement with reasoning. Hard failures require correction. Acknowledgement cannot bypass them.

An authorized reviewer can refresh the exact saved head through GET /policies/{policy_id}/validation in the application programming interface (API) reference. That operation requires policy:review. An author without that capability must not use it as a diagnostic shortcut.

Recover Without Losing Intent

If Save fails, retain your edits and read the reported finding. For a connection or directory error, ask the administrator of the named integration to restore access before retrying Save. If you changed the form during compilation, save again using the latest edits.

If Policy reports that the draft changed, reload it and compare its content with your unsaved edits. In an API client, obtain a new Draft-ETag only after that comparison. For an uncertain response, inspect the Library before creating another policy. If the saved result remains unclear, preserve the policy identifier and support reference. Send those details to your Policy administrator instead of repeatedly selecting Save or creating another policy.

Next, submit the saved draft. For artificial intelligence (AI) preview, use AI preview and Save.

2 - Author Artificial Intelligence Policies

Use artificial intelligence (AI) authoring for Federated Guardrails protection. The current lane configures classification scope and principal-specific Unprotect permission. Classification scope selects the data categories that generated rules cover. Principal scope identifies the target identities to which those rules apply. Unprotect permits the configured inbound path to return cleartext for a principal. Do not treat Coming Soon options as available protection methods.

Prepare access, classifications, and principals. Confirm that your operator has configured the intended Guardrails consumer.

To author and verify an AI policy, follow these guides:

1. Configure classifications and the permission matrix.
2. Inspect preview and save the draft.
3. Submit current saved work.
4. Hand off to a separately authenticated reviewer and approver.
5. Verify Guardrails publication and receipt.

Preview is not persistence. Approval is not publication. Consumer receipt records eligible retrieval of published output. Consumer receipt is not evidence that every runtime has activated protection. Here, runtime means the downstream Guardrails system evaluating traffic, not Policy’s authoring service. Refer to states and revisions.

2.1 - Configure Artificial Intelligence Protection

Configure artificial intelligence (AI) protection as an authorized policy author. Classification scope selects data categories. Principal scope selects the identities covered by generated rules. The target principal is not necessarily the authenticated Policy author.

Before You Begin

Complete these prerequisites before configuring an AI policy:

• Complete example preparation.
• Identify one classification and one explicit supported principal.
• Confirm that your operator has configured the intended Federated Guardrails consumer.

Choose Scope and Settings

To configure the AI policy scope and settings, follow these steps:

1. Open Policy Library.
2. Select AI Policy from the creation choices. Opening the form does not create a saved policy.
3. Select the prepared classification.
4. Select the supported principal.
5. Select Federated Guardrails.
6. Review the generated title.
7. Enter a clearer title when needed.

Use catalog identities for users, agents, services, or groups that your deployment supports. Do not substitute display names for native identities. Stop if a required classification or principal cannot load. Send the missing selection and error message to the Traverse integration administrator before submitting work.

Knowledge Graphs, Protegrity Semantic Guardrails, third-party guardrails, and Privacy appear as Coming Soon choices. This procedure does not enable those choices.

Set Unprotect Permission

Unprotect allows a selected principal to recover readable values from protected content. The generated rules also protect data for the selected principals. The Unprotect toggle controls the reverse operation. Turning it off does not disable protection.

To set permissions for each principal, follow these steps:

1. Inspect the principal row in Permissions Matrix.
2. Set Unprotect according to the principal’s intended permission. Enable it to allow readable values. Otherwise leave it off.
3. Review every row after changing the selected principals.

Bulk selection applies to the current principal selection. Use it only when every selected identity needs the same Unprotect decision. Inspect individual rows afterward.

An all-principals selection produces wildcard scope rather than a list of named identities. Use it only with explicit authorization for that broader scope. For a first policy, prefer an explicit principal.

Verify the Intended Matrix

Check the classification and every principal-specific Unprotect decision together. Changing principal scope can change generated rules. Do not infer saved or deployed permission from the matrix alone.

Next, inspect preview and save. After Save, follow governance and Guardrails delivery verification.

2.2 - Preview and Save an Artificial Intelligence Draft

Preview helps inspect current artificial intelligence (AI) authoring decisions. It does not create a saved policy or reserve an approval token. Preview derives output from the current inputs without publishing it to Guardrails. Compilation checks authored inputs and derives target rules and findings. Save runs compilation separately. It does not persist the preview response as approval evidence.

Before You Begin

Complete these prerequisites before previewing or saving:

• Use your author account with edit capability and applicable owner/editor access.
• Configure classification scope and Unprotect permissions.

Inspect Preview

To inspect the generated preview, follow these steps:

1. Review the current classifications, principals, and Unprotect decisions.
2. Inspect the preview feedback after the current inputs finish loading.
3. Review any reported warnings.
4. Correct scope or permissions when the feedback identifies unintended output.

Wait for feedback that corresponds to your current selections. Do not treat a previous preview as evidence for later edits. If preview reports an error, retain that message before changing inputs. For a connection or directory error, send the message to the administrator of the named integration.

Save and Verify

To save the AI policy draft and verify it, follow these steps:

1. Confirm a nonblank policy title.
2. Select Save Draft. Policy compiles current inputs and attempts to persist the draft.
3. Inspect the Save result. A successful Save returns you to the Library.
4. Reopen the saved policy.
5. Confirm its AI source, classification scope, and principal permissions.
6. Record its policy identifier for review.

The saved draft is proposed work, not the governed revision containing approved intent. Each Save records a snapshot within the proposal. The latest snapshot is its current head. Save and preview use different operations. A successful preview does not guarantee that Save succeeds. A saved draft does not prove approval, publication, or consumer receipt.

If Save reports validation or compatibility errors, correct the named inputs. If another user changed the draft, refresh current work before repeating a decision. If the response remains uncertain, inspect the Library before creating a duplicate. Keep the visible error and support reference for an authorized operator.

Prepare Review

Inspect saved findings before submission. Correct hard failures rather than acknowledging them. An authorized reviewer can inspect current saved validation through the application programming interface (API). That read requires review capability. Ordinary author access does not imply it.

Next, submit the current saved draft. After approval, follow Guardrails evidence.

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

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

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

3.3 - Correct Returned Work and Resubmit

Act as the author after a reviewer requests changes. Use your own authenticated account with edit capability and policy resource access. The returned proposal remains editable, even when the interface labels it Rejected. An existing governed revision remains unchanged. Returned work is not yet a new submission. Save records corrections. Resubmission returns those corrections to In Review.

Before You Begin

Complete these prerequisites before correcting returned work:

• Obtain the policy identifier and correction request from the reviewer.
• Confirm edit capability and applicable owner/editor access.
• Keep the existing proposal. Do not create a replacement policy.

Correct the Proposal

To correct the returned proposal, follow these steps:

1. Open the policy identifier that the reviewer returned.
2. Read the reviewer’s reason in the available decision or history information.
3. Open the available edit or resume action. Policy reopens the existing proposal.
4. Correct the named title, classification, principal, method, or permission input.
5. Save the corrected draft.
6. Reopen the policy to verify the saved correction.

If your account cannot see the full reasoning, ask the reviewer for actionable feedback. Do not interpret a redacted or unavailable note as an empty decision. Do not create another policy merely to avoid the returned-work status.

Refer to Data Save or artificial intelligence (AI) preview and Save for lane-specific validation. If Save fails, preserve the current edits and visible error. For a connection or directory error, ask the administrator of the named integration to restore access before retrying Save.

Resubmit and Hand Off

To resubmit the corrected work, follow these steps:

1. Inspect current saved findings.
2. Correct hard failures or address permitted reviewable findings.
3. Follow submission using the current saved draft.
4. Confirm In Review.
5. Hand the same policy identifier back to the reviewer.

For direct application programming interface (API) use, obtain the current draft token. The server-issued draft entity tag (ETag), returned as Draft-ETag, identifies the current head for concurrency checks. Do not reuse a token from before the request for changes or later Save. Do not send another user’s name as the actor.

Verify the Handoff

History should retain the earlier request and the later resubmission. The reviewer must reload the submitted draft and review its corrected content before approval. If another user changed the draft, compare their changes with yours before saving again. Stop rather than overwriting unknown newer work.

Next, the reviewer follows review and approval. After approval, follow delivery.

3.4 - Restore Policy Intent or Retire a Policy

Policy rollback and archive solve different problems. Rollback proposes earlier policy intent for another review. Archive removes this policy’s configuration from the receiving products. Neither operation restores a database or rolls back a software installation. Restoring database contents is an operator recovery task, not a policy rollback. Closing a draft abandons only proposed changes. It does not withdraw approved output.

Refer to history and states and revisions first.

Before You Begin

Complete these prerequisites before restoring or archiving a policy:

• Identify the policy and the intended outcome: restore earlier intent or retire its contribution.
• Confirm policy:rollback and applicable owner/editor access for rollback.
• Confirm policy:archive and the retirement impact for archive.
• Arrange an authorized operator’s withdrawal check if you lack audit access.

Restore Earlier Policy Intent

You need policy:rollback and applicable policy owner/editor access. Choose an earlier governed revision, not the current revision or an arbitrary saved snapshot. A governed revision records approved intent. A draft snapshot records saved proposed work.

To restore earlier policy intent, follow these steps:

1. Inspect current governed and open-draft information.
2. Identify the earlier governed revision that contains the intended policy content.
3. Select Roll back when the action is available.
4. Select the intended earlier governed revision in the dialog.
5. Review the warning about existing open draft work.
6. Enter a reason for restoring that revision.
7. Acknowledge replacement if an open proposal exists.
8. Confirm the rollback decision. Rollback creates a new In Review proposal from the selected content.
9. Open the resulting draft and Change History to check its content and the version selected for rollback.

The current governed revision remains unchanged. Follow review before the restored proposal can become governed. If you edit that proposal, save and resubmit the corrected work before approval. Replacement confirmation applies only to the exact open draft head shown by the server. If that head changes, inspect the newer work before confirming again. Do not treat successful rollback as immediate target recovery.

If you cannot identify the correct source revision, stop. Ask an authorized reviewer to confirm the intended content. For direct clients, follow the exact rollback preconditions in the application programming interface (API) reference.

Archive a Policy

You need policy:archive and a clear retirement reason. Confirm the policy identifier and impact on shared protection before proceeding.

To archive a policy, follow these steps:

1. Inspect the current governed revision and any open draft.
2. Review affected targets and shared contributions.
3. Select Archive when the action is available.
4. Enter a nonblank reason.
5. Confirm the retirement decision. Policy closes applicable open work and starts asynchronous withdrawal.
6. Inspect policy detail and the withdrawal operation.
7. Follow withdrawal verification.

For direct clients, use POST /policies/{policy_id}/archive with reason and the current governed-policy ETag in If-Match. Do not substitute a draft token. Do not send archivedBy. Policy derives the actor from trusted identity. Refer to canonical API examples.

An initial archive response does not prove completed withdrawal. Withdrawal removes this policy’s contribution from applicable target output. Archive completion does not prove that every shared location became unprotected. Other policies can retain protection over shared resources.

Verify or Stop

Reload the policy and check Change History for the rollback or archive request before repeating a command that timed out. If Policy reports changed content or a conflicting Policy Integration Manager (PIM) object identifier, send the error to your Policy administrator. The administrator can follow recovery.

For draft-only abandonment, use close an open draft.

4 - Monitor Delivery and Withdrawal

Approval queues publication rather than synchronously activating every target. Check the currently approved version, not unsaved edits or an older delivery request. The Operations tab lists publication and removal requests. Each has a request number called generation. Retrying a request sends its previously saved configuration again.

Before You Begin

Complete these prerequisites before checking delivery:

• Identify the currently approved policy version.
• Confirm permitted policy visibility.
• Arrange an operator with policy:audit to inspect restricted Operations details. If you hold that capability, you can perform the operation checks yourself.

Follow the Target-Specific Path

To verify delivery for the target, follow these steps:

1. Confirm the governed revision through Library inspection.
2. Have the authorized operator check the latest publication request in Operations. The operation identifies retained publication work and any reported error.
3. Follow the verification path for your policy’s targets:
   • Data evidence for Data protection.
   • Guardrails evidence for artificial intelligence (AI) protection. Complete both for a mixed policy.

For failed or retired work, follow issues and withdrawal.

A mixed policy needs evidence for every applicable target. Successful Data protection does not substitute for Guardrails receipt. These verification guides cover Data protection and Federated Guardrails. For Secure Query, ask its administrator for the verification procedure supported by your deployment.

Interpret Results

The following table distinguishes the evidence provided by each delivery result:

A Guardrails receipt records an eligible consumer retrieval of published output. It is not a consumer assertion that protection has activated. The chart supports both anonymous-only compatibility and an exact named consumer match. Its empty-string default accepts absent or empty request identity, not named requests. Publication reaches Published. Publication plus qualifying receipt allows reconciliation to Enforced for Guardrails-only policies. Mixed policies also need Data evidence. Follow Guardrails verification to check the consumer configuration and current receipt. Refer to states and revisions. For periodic changes after approval, see automatic recompilation.

For the complete author-to-reviewer journey, follow your first policy.

4.1 - Verify Data Delivery Evidence

Verify Data protection after an authorized approver creates a governed revision.

Before You Begin

Complete these prerequisites before verifying Data delivery:

• Confirm permitted policy visibility.
• Arrange an operator with policy:audit to inspect restricted deployment diagnostics.
• Ask the Traverse integration administrator which tables or columns the approved policy should protect.

Expected locations are the data locations that compilation of the governed revision identifies for protection. They are not every discovered location or the selections in a newer draft.

Verify the Current Deployment

To verify the current deployment, follow these steps:

1. Open the policy in Policy Library.
2. Record the current governed revision and visible protection state.
3. Have the authorized operator check the latest publication request in Operations for errors.
4. Record its deployment identifier and request number (generation) if you need administrator help.
5. Follow delivery troubleshooting if publication reports an error.

Use the application programming interface (API) policy-detail reference when your Panel does not expose the required detail. Use view=governed&includeProtection=true for approved delivery readback. The governed view selects approved inputs for current protection observations. The default view=latest selects replacement-draft content while that draft remains open. Check the approved scope, not the replacement proposal, when verifying delivery. Use the operations reference for restricted deployment details. Restricted operation inspection requires audit authority. Do not obtain broader access merely to interpret a status badge.

Verify Location Evidence

To verify protection at each expected location, follow these steps:

1. Ask the Traverse integration administrator to check the protection status of each table or column identified above.
2. Ask the administrator to confirm that those observations apply to the currently approved policy version.
3. Check that every expected location reports protected.
4. If the policy also uses Guardrails, complete Guardrails verification.

For example, suppose the approved scope expects locations A and B. If A reports protected and B explicitly awaits protection, progress remains incomplete. If Traverse returns no observation for B, ask its administrator to investigate that missing location. If Traverse is unavailable, wait until the administrator restores access before checking protection again. Missing, unexpected, or mismatched location identities prevent a complete match to the expected set.

Policy can show Enforcing while some locations report protected and delivery or protection checks remain incomplete. Check every expected location and any Guardrails delivery before accepting Enforced as the current result.

Stop and Escalate

If the administrator cannot identify the expected tables or columns, or Traverse omits them, keep the verification open. Retain the policy identifier, revision, deployment, generation, timestamp, and visible issue. Do not write protection state manually or guess missing locations.

For failed publication, follow inspection and retry. If publication stopped with an error, resolve that error even if Traverse later shows protected data. If Guardrails also applies, follow Guardrails evidence.

Return to delivery overview or recovery.

4.2 - Verify Federated Guardrails Delivery Evidence

Verify Federated Guardrails delivery after approval.

Before You Begin

Complete these prerequisites before verifying Guardrails delivery:

• Prepare the policy identifier and current governed revision.
• Ask the Guardrails administrator whether retrieval uses anonymous compatibility or a named consumer account.
• Confirm the deployment’s apiService.environment.GUARDRAILS_CONSUMER_USERNAME value with its configuration owner.
• Arrange an operator with policy:audit to inspect restricted Operations details.

A receipt records that consumer’s retrieval of the generated configuration. It does not confirm that Guardrails has started applying the configuration to requests.

The chart maps this value through the API ConfigMap into the consumer-username environment variable. The empty-string default accepts only requests with absent or empty identity. A nonempty value requires an exact gateway-verified username match. See consumer evidence and configuration for supported settings. Neither publication nor an ineligible retrieval proves receipt completion.

Inspect Publication and Receipt

To verify publication and the consumer receipt, follow these steps:

1. Open the policy in Policy Library.
2. Record the currently approved policy version and displayed protection status.
3. Have the authorized operator check the latest publication request in Operations for errors.
4. Ask the Guardrails administrator to confirm a successful fetch using the configured identity mode.
5. Reload the policy and check its protection status. Publication reaches Published. Publication plus qualifying receipt allows reconciliation to Enforced for a Guardrails-only policy.
6. If the policy remains Published after a successful fetch, send the policy version, operation details, and retrieval time to your deployment or support owner.

A successful fetch must include the current policy version. Guardrails can retrieve one combined configuration containing several policies. An older configuration or one containing a different version of this policy does not confirm current delivery.

Use the application programming interface (API) retrieval reference and authentication for consumer retrieval contracts. An eligible retrieval can record receipt on either a full 200 response or an unchanged 304 response. Eligibility requires the configured identity mode: absent or empty identity for the empty-string default, or an exact gateway-verified named match. Named requests do not qualify under the empty-string default. Receipts must match current publication targets and checksums, or exact current contributor lineage in a newer aggregate. Follow approved gateway access rules and keep named consumer credentials separate. Never supply trusted identity headers yourself.

Without a qualifying pull, a published Guardrails-only deployment remains Published. With publication and qualifying receipt, it can reach Enforced. For mixed deployments, also complete Data evidence.

Understand the Evidence Boundary

A receipt confirms retrieval, not successful processing of real requests. Ask the Guardrails administrator to perform the deployment’s runtime test after retrieval. If several Guardrails replicas run, confirm their configuration through Guardrails monitoring. Policy’s receipt does not verify each replica.

For example, retrieving a combined configuration containing policy version 2 does not verify delivery of version 3. Background recompilation can also change the generated configuration without changing the approved major version. When investigating a mismatch, give the administrator the full version, including its compilation minor, and the retrieval timestamp.

Stop and Escalate

Stop when publication failed, the consumer identity is uncertain, or receipt evidence mismatches. If the retrieval identity does not match the configured mode, ask the configuration owner to correct the mismatch. Approval retries cannot repair an identity mismatch. Retain the policy, revision, generation, timestamp, and visible support reference. Ask the Guardrails administrator to include the retrieved product response’s fingerprint when available. The retrieval reference describes this aggregate-output field. Do not infer it from the policy title or revision. Ask your Policy administrator to compare the recorded retrieval with the policy’s current generated configuration. Do not retry approval merely because the consumer has not fetched the output.

For failed retained work, follow delivery issues. For ongoing recompilation, see automatic recompilation.

4.3 - Inspect Delivery Issues and Verify Withdrawal

Use this task when publication fails or an archived policy remains Archiving. Each delivery request has a generation number. Retries reuse the configuration saved for that request. Restricted operation inspection requires policy:audit.

Before You Begin

Complete these prerequisites before investigating delivery:

• Retain the policy identifier and visible error.
• Confirm audit capability before following Operations directions. Otherwise, give this task to your Policy administrator.
• Confirm policy:approve for publication retry or policy:archive for withdrawal retry. Audit access alone does not permit either command.

Inspect Before Retry

To inspect a failed delivery before retrying, follow these steps:

1. Open the policy’s Operations tab.
2. Select the latest request and record its deployment identifier, error message, and support reference.
3. Follow the publication troubleshooting table to identify the administrator who can resolve the reported problem.

If you cannot open Operations, send the policy name and visible error to your Policy administrator.

For direct application programming interface (API) use, inspect GET /policies/{policy_id}/operations under audit authority. Refer to recovery reference for diagnostics and command-specific prerequisites.

Do not interpret an unavailable diagnostics record as successful delivery. An operations 404 can mean no recorded deployment. A support reference does not grant access to restricted diagnostics.

Retry Eligible Retained Work

To retry eligible retained work, follow these steps:

1. Ask the administrator handling the failure to confirm that its cause is resolved.
2. Reopen Operations and check that no later publication or removal request exists.
3. Use Retry publication or Retry archive if Policy offers the action for that request.
4. Check the subsequent attempt for errors and follow Data or Guardrails verification.

Publication retry requires policy:approve. Withdrawal retry requires policy:archive. For direct clients, use the generation-specific deployment retry contract. An empty 204 response means the reset succeeded, not that delivery recovered. Retry sends the previously saved configuration. It does not include edits made after that request.

The server rejects replaced work or a generation with a newer successor. Treat a retryability hint as advisory, not permission to bypass command checks. For a missing or conflicting Policy Integration Manager (PIM) object identifier, ask your Policy administrator to follow the ownership-reconciliation playbook before retrying.

If policy intent needs correction, return to authoring, review, and approval. Retry does not use a newly edited draft. For ownership reconciliation, follow the operator recovery playbooks.

Verify Withdrawal

Start this task after an authorized user archives a policy.

To verify that withdrawal completed, follow these steps:

1. Open Operations and find the removal request created by archive.
2. Read its current status and error message.
3. If an error remains, follow the publication troubleshooting table linked above.
4. Reload the policy until archiving completes. If it remains Archiving, send the operation details to your Policy administrator.

While withdrawal remains incomplete, the policy can retain Approved governance and show Archiving delivery progress. Do not interpret archive initiation as completed removal. Guardrails withdrawal publishes revised aggregate output without the retired contribution. Policy does not wait for a Guardrails consumer to fetch that revised output before completing Guardrails withdrawal. If the policy also uses Data protection, a successful Guardrails update does not complete the Data removal.

Withdrawal removes this policy’s contribution. Other policies can retain protection over shared resources. Archive completion does not certify destruction of all cryptographic material. It also does not prove that every location became unprotected.

Authorized archive evidence records an attributable claim for the active withdrawal. It does not replace target completion evidence or certify deprotection. Follow the archive evidence contract when an operator needs that record.

If the request has been replaced, or the error identifies an unknown PIM object, stop retrying and send the error to your Policy administrator. Return to delivery or operations.

5 - Create and Review Your First Policy

This journey uses two authenticated users: author Alex and reviewer Morgan. Morgan also needs approval authority to approve the corrected submission. Use separate accounts, not shared credentials or client-supplied actor names. This example does not require every deployment to enforce two-person approval.

Before You Begin

Complete these prerequisites before starting the example:

• Complete access and example preparation.
• Ask a Protegrity Provisioned Cluster (PPC) user with administrator permissions to assign Alex policy_author.
• Ask that administrator to give Morgan the policy:review and policy:approve permissions.
• Identify one discovered classification and one supported principal.
• Identify the expected Data locations and their configured protection integration.
• Use a nonproduction example that your organization permits you to protect.

Classification scope identifies the selected data categories and their applicable discovered locations. The selected principal is the target identity receiving permissions, not necessarily Alex or Morgan. Their Policy capabilities authorize authoring and review, not access to the protected data.

Do not grant a broad administrator role merely to follow this example. Refer to authority requirements.

Steps

Follow these steps to complete the author-to-reviewer workflow:

1. As Alex, configure a Data policy. Select the prepared classification and explicit principal, then configure Encryption and the required permissions.
2. Save and inspect the draft. Record its policy identifier and confirm that the saved content matches your selections.
3. Submit the saved draft. Confirm In Review before handing the identifier to Morgan.
4. As Morgan, review and request changes. For this exercise, request a clearer policy title with a nonblank reason.
5. As Alex, correct and resubmit. Confirm the corrected title and current submitted snapshot: saved content and findings, also called the draft head.
6. As Morgan, approve the current submission. Approval creates a governed revision: the approved intent. It also queues publication.
7. Follow Data delivery verification. Verify the current deployment and every expected location independently.

For artificial intelligence (AI) protection, substitute AI configuration and AI preview and Save for the first two tasks. Finish with Guardrails evidence.

Verification

You have completed the authoring and governance journey when history shows Alex’s submission, Morgan’s requested changes, Alex’s resubmission, and Morgan’s approval. You have not completed delivery merely because approval succeeded.

Stop when validation blocks submission or approval. Correct the field named by the validation message and reload the validation results. For a connection or directory error, ask the administrator of the named integration to investigate. If publication fails, preserve the deployment identifier and support reference. Refer to delivery issues instead of repeatedly approving unchanged work.

6 - Common Policy Workflows

Use this map to choose the next task. Follow the linked instructions rather than maintaining separate copies of the workflow. For a complete worked example, use your first policy.

Policy Library Workflows

Start with Library inspection. Find the intended policy, inspect its current state, and read permitted history. Use the policy identifier to avoid acting on a similarly named row.

Policy Authoring Workflows

Choose Data authoring for the enabled Encryption journey. Choose artificial intelligence (AI) authoring for Federated Guardrails. Both paths require supported classifications, principals, and approved author access. Classifications select data categories. Principals identify the target identities receiving permissions. Neither path activates protection merely by saving a draft.

Create a Policy

After saving and inspecting findings, submit and hand the policy identifier to the reviewer.

Workflow: Review Conflicts Before Approval

Refer to review. Reload the submitted draft and read its current validation findings. Request changes for hard failures. After correction and resubmission, reload and review the corrected draft. Only explicitly reviewable findings permit acknowledgement. Acknowledgement records a deliberate exception with current finding identifiers and reasoning. It cannot waive hard failures.

Workflow: Approve or Archive a Policy

These are different decisions, not alternative ways to finish a draft. Refer to approval to approve the reviewed draft and start publication. Refer to archive to remove a policy’s published configuration. Approval creates the governed revision containing approved intent. Archive starts withdrawal of that contribution, not deletion of its history. Track delivery and withdrawal after either consequential operation.

7 - Policy Working Practices

Use these practices alongside the authoring and governance guides.

Policy Authoring Practices

Prefer explicit supported principals for a narrowly scoped first policy. Check classification identities and discovered scope rather than names alone. Scope includes selected classifications, applicable data, and intended principals. Review permission rows again after changing principal scope. Do not treat wildcard selection as a missing or empty scope.

Use a meaningful nonblank title. Inspect saved content and findings after Save. Do not interpret preview or an enabled Save button as submission eligibility. Refer to Data or artificial intelligence (AI) instructions.

Lifecycle Management Practices

Keep author and reviewer responsibilities explicit. Use each person’s own authenticated account. Owner/editor grants do not supply review or approval capability. Conversely, an author authority mapping does not prove an owner/editor grant on an existing policy. Do not grant broad administrator access merely to complete a handoff.

Concurrency evidence must match the resource and the content under review. An entity tag (ETag) validates a resource version. It does not grant authority. Draft and governed-policy validators are not interchangeable. The conditional-request reference defines each command’s header requirements and stale-work handling. Keep actionable reasons with requested changes and approval decisions. Refer to governance for command-specific prerequisites.

Operational Practices

When reporting a delivery error, include the policy identifier, approved version, deployment identifier, error message, and support reference. Ask the administrator named by delivery troubleshooting to resolve the error before retrying. Retry sends the previously saved configuration. Edited drafts require submission and approval.

Periodic recompilation preserves authored intent and approval identity. It can change compilation minors and queue delivery when source context changes. A compilation minor recompiles the same governed revision without approving new intent. Refer to automatic recompilation.

Verification

After approval, follow the Data or Guardrails verification guide rather than stopping at the approval notice. For Data, check every expected location’s protection status with the Traverse administrator. For Guardrails, confirm consumer retrieval and use Guardrails monitoring to check runtime behavior. After archive, check that archiving finishes. Another policy can still protect the same data.

8 - Policy Use Cases

These use cases explain when to choose each workflow. Use the linked instructions for prerequisites, actions, and verification.

Use Case 1: Browse Policies in Policy Library

A stakeholder finds policies by name, classification, or principal. The Library tasks explain search and filtering. A read-only user cannot edit, approve, or archive policies.

Use Case 2: View Policy Summary Without Leaving the Library

A reviewer inspects scope, exceptions, and current state in the view panel. Refer to summary inspection. Do not confuse open proposed content with the governed revision.

Use Case 3: Start a New Policy From the Library

An author chooses Data or artificial intelligence (AI) authoring. Opening a form does not create persisted policy work.

Use Case 4: Author Policy Inputs Using Guided Steps

A Data author selects classified scope, principals, Encryption, and permissions. Scope means selected data categories, their applicable data, and the intended target identities. An AI author configures Federated Guardrails and principal-specific Unprotect permission. Save, preview, and submission remain different operations.

Use Case 5: Review Conflicts and Approve Policy

A separately authenticated reviewer inspects the current submission. The reviewer requests corrections or, with approval capability, approves reviewed work. Refer to review decisions and then delivery.

Use Case 6: Track Policy State Using KPI Summaries

A stakeholder uses key performance indicator (KPI) tiles to narrow the loaded list. The tiles do not establish target activation. Refer to detail and history for an individual policy.

Use Case 7: Change an Approved Policy Safely

An author opens replacement draft work while the existing governed revision remains current. The governed revision records approved intent. Saving a replacement does not approve it. The replacement follows submission and review. Automatic recompilation instead updates compiled output without rewriting author intent. Refer to automatic recompilation.

Use Case 8: Reject and Resubmit a Draft

A reviewer requests changes with an actionable reason. The author corrects and resubmits the same proposal. The Rejected presentation does not make the work permanently uneditable. Returned work awaits correction. Resubmitted work enters In Review for another decision.

Use Case 9: Roll Back to an Earlier Approved Version

An authorized author restores earlier policy intent as proposed work. Another review and approval must precede replacement of the governed revision. Policy rollback does not roll back software or restore a database.

Release Alignment Note

Choose an enabled authoring option. The guides below cover Data Encryption and Federated Guardrails. Options labeled Coming Soon do not start an authoring workflow.

9 - Inspect and Use the Policy Library

Use the Library to inspect saved Data and artificial intelligence (AI) policies. The Library includes policies created in Policy and information imported from Policy Integration Manager (PIM). Authored policies have Policy identifiers and governance history. Native identifiers belong to resources in downstream systems. Matching names do not make those identities interchangeable. Not every visible row permits editing.

Before You Begin

Complete these prerequisites before using the Library:

• Obtain the Policy address and your own authorized account through access preparation.
• Confirm policy:audit before inspecting restricted operations.
• Arrange an authorized operator’s help if you lack that capability.

Access Policy Library

To open Policy Library, follow these steps:

1. Log in using your own authorized account.
2. Open Policy Library.
3. Confirm that the list loads without a retrieval error.

A read-only account can inspect permitted information without acquiring mutation authority. If loading fails, keep the visible error instead of interpreting an empty list as no policies.

Understand Policy Library Columns

Read policy identity, source, classifications, principals, methods, exceptions, and modification information together. Scope means the selected classifications, applicable data, and principals covered by the policy. Treat policy state and protection state independently. An Approved row can still have an open draft or incomplete publication. The governed revision records approved intent. An open draft proposes changes to it. Refer to states and revisions.

An unavailable or stale validation count does not mean zero exceptions. Inspect the saved findings before submission or approval. Imported display-only policies do not become editable merely because you can view them.

Search for Policies

To find and verify a policy, follow these steps:

1. Enter a recognizable name, classification, or principal in the search field.
2. Inspect the matching rows.
3. Confirm the policy identifier or detailed scope before taking action.

Search narrows the displayed collection. It does not grant access. If no row matches, clear search and any active tile filter. Do not create a duplicate until you have checked the intended policy identifier.

Search Input Options

Use policy names, classifications, or principals as search input. Check the resulting scope before taking a lifecycle action.

Narrow and Sort the Policy List

To filter and sort the displayed policies, follow these steps:

1. Select the applicable Data Policy, AI Policy, or Drafts tile.
2. Choose an available sortable column to order the displayed results.
3. Clear the active tile when you need the broader collection again.

Sort Options

Use the sort direction shown by the selected column. Do not infer a review priority from list order alone.

KPI Tiles

Key performance indicator (KPI) tiles summarize the loaded collection. Open an individual policy to check publication and protection status. The tiles count policies, not completed deliveries.

Review Policy Summary in the View Panel

To inspect a policy summary, follow these steps:

1. Select the intended row or its View action.
2. Inspect the policy summary.
3. Confirm classifications, principal scope, protection methods, and outstanding exceptions.
4. Inspect the current governed and proposed information when available.

Do not mistake draft content for the governed revision. If details fail to load, reopen or refresh the policy before making a decision. Use the application programming interface (API) when the Panel does not expose required evidence.

View Panel Fields

Inspect identity, scope, current state, exceptions, and source together. Use current detail rather than inferring content from a summary cell.

Inspect History

To inspect a policy’s lifecycle history, follow these steps:

1. Open the policy’s view panel.
2. Inspect Change History.
3. Identify creation, saves, submission, review decisions, and approval events.
4. Check the responsible actor and timestamp for each relevant event.

Distinguish the currently approved version from earlier approved versions and the editable draft. Use the history view’s continuation control when more entries remain. Read the version’s actor, timestamp, and available notes before choosing it for rollback.

History lists lifecycle events and their metadata, not a full historical-content comparison. Repeated saves belong to one proposal and can appear as separate events. Each Save records a snapshot. The latest saved snapshot is the draft head. Keep current draft identity separate from governed revision identity. Do not treat a record version counter or saved snapshot identifier as a governed revision number. Do not infer that the first visible entry identifies the governed revision.

For complete permitted history, use GET /policies/{policy_id}/history. Follow pagination in the API reference instead of assuming the visible history contains every retained event. History can redact decision reasoning according to caller authority. An absent visible reason does not prove that the reviewer supplied none. An authorized auditor can use the separate audit export contract.

If history fails to load, do not treat the failure as an empty audit trail. Preserve the policy identifier and error for an authorized operator.

Inspect Lifecycle Operation Details

Use this task only with audit capability. Otherwise, give the policy identifier and visible error to your Policy administrator.

To inspect an operation when you have audit capability, follow these steps:

1. Open the policy’s Operations tab.
2. Select the latest request and read its attempt count and error message.
3. Copy its deployment identifier and support reference if you need help from your Policy administrator.

Restricted operation reads require audit capability. Read access does not confer retry or reconciliation authority. Continue with delivery issues.

Use Status-Aware Row Actions

Policy offers actions according to current state and authority. The server still authorizes each command. An absent action is not a reason to forge a request or broaden permissions.

Choose an available action that matches the work you need to do:

• Use edit or resume to prepare proposed work.
• Use submission to hand work to review.
• Use review for decisions.
• Use rollback or archive for restoration or retirement.
• Use close an open draft to abandon only proposed work.

Interpret Cedar Policy Source

Cedar source describes generated access rules. Use this reference when your view or API response includes Cedar source. It does not prescribe an additional Panel action. It does not show whether PIM applied the configuration or Guardrails retrieved it. Use delivery verification to check those results. For API authoring, keep the full structured compile request rather than replacing it with copied Cedar text.

Review Checklist

Compare the generated rules with the classifications, principals, and permissions you selected. If they differ, correct the structured authoring inputs and compile again.

Start Policy Creation From Policy Library

To start policy creation, follow these steps:

1. Choose Data Protection Policy or AI Policy.
2. Follow the selected authoring journey. Opening the form alone does not save a policy.

Refer to Data authoring or AI authoring. Treat Quantum Policy’s Coming Soon choice as unavailable.

Expected System Behavior

The selected journey opens an authoring form. Only a successful Save creates persisted draft work.

10 - Policy Authoring Procedures

Policy offers separate Data and artificial intelligence (AI) authoring journeys. Use the lane that matches your protection target. These journeys share governance, but they use different permission models.

Before You Begin

Prepare discovered classifications, supported principals, and approved author access. Refer to start here and roles and permissions.

Configure Data Scope

Refer to Data scope selection. Scope identifies the selected classifications, applicable data, and intended principals. Select an available classification from the catalog rather than typing a new category name. Review changed scope before saving or resubmitting.

Choose Principals

Use explicit supported principals for a narrowly scoped first policy. An all-principals selection broadens scope. It does not mean no access. Refer to principal selection.

Choose Protection and Permissions

Refer to Data protection and permissions. The current Data journey enables Encryption. It marks standalone Masking and Filtering choices Coming Soon.

Data-Element Naming

Inspect the effective title and classification context before Save. The title labels authored work. A native data element is a separate target resource with its own identity. Two data elements with the same name can still have different identifiers in Policy Integration Manager (PIM).

Secure Query Availability

Attribute-based access control (ABAC) and row-level security (RLS) describe different kinds of access restriction. ABAC evaluates attributes when deciding access. RLS restricts which rows a query can return. They do not make the disabled Data Filtering choice available. This guide does not prescribe a supported Secure Query authoring recipe. Ask your Secure Query administrator for the procedure supported by your deployment. This is not a required step in the Data authoring journey. Refer to integration flows for the products covered by these Policy guides.

Save and Submit Data Work

Refer to Data Save and validation. Saving persists a draft. It does not approve or publish it. The draft is proposed work. The governed revision records approved intent after review. Continue with submission only after inspecting saved findings.

Review and Approval Controls

Refer to review and approval after submission. The Panel’s Reject action requests changes. It does not erase the proposal.

Choose AI Authoring

Refer to AI authoring. Configure Federated Guardrails and principal-specific Unprotect choices. Then inspect preview and save. Preview does not persist or activate a policy.

The AI configuration instructions explain classifications, supported principals, and principal-specific Unprotect permission.

11 - Policy Lifecycle Operations

Refer to lifecycle and governance for the complete actor handoff. Use the links below to choose the action you need.

Lifecycle States

Treat draft status, governed revision, and protection progress separately. The draft holds proposed changes. The governed revision records approved intent. Protection progress describes target-specific delivery or protection evidence, not draft readiness. An approved policy can have an open replacement draft. Refer to states and revisions.

Before You Begin

Check command capabilities and policy grants. An owner/editor grant alone never supplies review or approval capability.

Edit an Existing Policy

Open the policy in the Library. Use the available edit or resume action to reopen existing draft work. Do not replace an open proposal merely to begin editing. The current governed revision remains current while you prepare its replacement. Continue with Data Save and validation or artificial intelligence (AI) preview and Save.

Edit Controls

Do not use rollback as a substitute for reopening a draft.

Submit a Policy for Review

Refer to submission as the authorized author. Submission creates In Review work, not a governed revision or publication.

Confirm In Review and hand the policy identifier to the reviewer.

Resolve Requested Changes and Resubmit

Refer to correction and resubmission. Use the same policy identifier and inspect the new current draft head.

A request for changes returns editable work. The interface can label that work Rejected. Only resubmission returns the corrected saved head to In Review. Refer to request changes for the UI action and API command.

Approve a Policy

Refer to review and approval. The approver must reload the submitted draft and read its current validation findings.

Approval Prerequisites

Use your approval capability and the current reviewed draft token for that decision.

Review Automatically Generated Minor Versions

Periodic recompilation can create a compilation minor without another author edit. A compilation minor recompiles approved intent within the same governed revision. It is not a new governed revision or another approval decision. It preserves author intent, approval identity, and open drafts. Unchanged output creates neither a new minor nor publication work. Inspect history and automatic recompilation. Do not use publication retry as a recompile command.

Monitor Publication and Protection State

Refer to delivery verification. Approval queues publication. Publication does not prove target protection.

Archive a Policy

Refer to archive. The command starts withdrawal and can close open draft work. Its initial result does not prove completed deprotection. Withdrawal removes this policy’s contribution. Shared protection can remain.

Close an Open Draft

Use your author account with edit capability and applicable owner/editor access.

To close an open draft, follow these steps:

1. Open the intended policy in Policy Library.
2. Select Delete draft when the action is available.
3. Confirm the policy identifier in the dialog.
4. Accept cancellation. Policy closes proposed work without deleting governed history.
5. Reopen the policy and verify that no open draft remains.

Do not treat canceling a draft as archiving its approved revision.

Deletion Considerations

The draft deletion action abandons proposed work, not its retained history. It does not withdraw the approved contribution.

Review Enforcement-Point Coverage

Compare the approved scope with per-target delivery evidence. A visible target label does not prove target activation. Do not add an unavailable target to bypass a publication issue.

Enforcement-Point Deployment Controls

Refer to delivery verification for the applicable target. Approval starts publication. Use the linked guide to monitor it rather than looking for a separate deploy action.

Manage Policy Access Grants

Refer to policy access management. Owner/editor grants support resource access, not review or approval authority.

Roll Back Policy State

Refer to policy rollback. Rollback creates proposed work for review. It does not restore a database or chart. The restored proposal starts In Review. The current governed revision stays unchanged until approval.

12 - Policy Integration Flows

Policy reads classifications, data locations, and principals from Traverse, and existing policy information from Policy Integration Manager (PIM). It uses those inputs to generate configuration for the receiving products.

Integration Architecture Summary

Traverse supplies discovery context and Data protection observations. PIM supplies existing policies, roles, and identity-source configuration. Federated Guardrails consumes the relevant published product output. Refer to concepts before choosing an authoring lane. Operators configure dependencies through operations.

Upstream Flow: Discovery Data Into Policy

Discovery identifies classifications and locations that affect policy compilation. Authors choose valid discovered scope rather than inventing location identities. Incomplete or unavailable discovery cannot establish complete protection evidence. Refer to Data authoring and Data verification.

Discovery Inputs Used by Policy

Classification identities, discovered fields, and source context determine applicable protection. The latest editable draft does not define the expected locations for an older governed revision.

Upstream Flow: Principal Catalog Into Policy

Principal catalogs provide supported identities for authoring. Display names help readers, but native identities govern target meaning. Native identities identify users, groups, or resources in an integrated system. Policy identifiers identify authored policies, drafts, or governed revisions. They do not replace native identities. Neither kind of target identity grants the caller Policy command capabilities. A missing identity requires investigation, not substitution with a similarly named principal.

Principal Inputs Consumed by Policy

Explicit identity scope and wildcard scope have different meanings. Selecting a principal does not automatically grant every protection action. Refer to Data permissions and AI permissions.

Trusted Application Inputs

Trusted application bindings describe target application context. They do not grant the caller review, approval, or administrator authority. Ask the PIM integration administrator to confirm that the selected identifier names the intended trusted application, not a similarly named application.

PIM Policy and Member-Source Harmonization

Native policies and member sources supply existing target context. Imported or display-only information does not automatically become editable authored work. If Policy reports a missing or conflicting PIM object identifier, ask your Policy administrator to inspect its saved mapping. A stale mapping is a stored native reference that no longer matches the expected live resource, resource kind, or target. Policy must verify that identity before reuse. A matching display name does not repair it. Do not delete or adopt native resources merely to clear a publication error. Refer to recovery.

Upstream Flow: Cedar Schema Attributes Into Policy

Schema attributes constrain valid compiler inputs. They do not enable Coming Soon authoring features. Use the current supported schema and preserve structured authoring input. Do not copy retired attribute examples into a new policy.

Schema Attribute Inputs Consumed by Policy

Scope, principal types, methods, and actions must fit the current contract. Use the application programming interface (API) reference for accepted request shapes. Refer to authoring procedures for the supported interactive path.

Downstream Flow: Policy to Enforcement Points

Approval queues publication for a pinned governed revision. That revision fixes the approved intent for the delivery work. Later edits to an open draft do not change the configuration already queued for publication. Refer to delivery for publication and protection checks.

Deployment Payload Categories

Different targets consume different artifacts and acknowledgement paths. A published Guardrails artifact does not prove Data protection. A native publication response does not prove consumer activation.

Data-Element Identity Across Targets

Policy preserves target-specific identities and contributor relationships. Do not treat a matching display name as proof of shared ownership. Use the identifiers returned by ownership inspection, not names copied from another policy.

Protector Location Validation for PIM Deployment

Native deployment must respect supported source and protector scope. Protector scope means the source address ranges that the native integration can represent. Do not broaden a range or substitute a protector to bypass validation. If validation rejects a source address or protector, send the error to the PIM integration administrator. Keep the requested range unchanged until the administrator confirms the correct protector and address range.

Operational Integration Checks

Periodic recompilation refreshes inputs before deriving approved output again. It preserves author intent, approval identity, and open drafts. Changed output can create compilation minors and queue publication. A compilation minor recompiles intent within the same governed revision. It does not approve a new policy decision. Unchanged output creates neither. Fresh-input failure does not authorize compilation against cached discovery.

If refresh or validation fails, Policy keeps the previous approved configuration. There is no public run-now endpoint. Deployment retry instead reuses retained artifacts. Refer to automatic recompilation.

For incomplete publication or withdrawal, use delivery issues and API recovery. A Guardrails receipt records eligible consumer retrieval, not activation on every runtime. Ask your Secure Query administrator for the verification procedure supported by your deployment.