Policy Integration Flows

Understand how discovery, principal catalogs, native policy context, and target delivery affect policy work.

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.

Last modified : November 03, 2026