Policy Evaluation Logic

When customers use the Import Policy or Validate Policy APIs, PlainID evaluates the incoming Policy and its Building Blocks to determine how the Policy is resolved in the target environment. This evaluation determines whether existing Building Blocks are reused, new Building Blocks are created, or existing Building Blocks are updated.

At the core of this evaluation is a comparison mechanism based on either a set of Rules or Building Block names, depending on the evaluation path selected.

This article explains the two evaluation paths available during import and validation, how they differ, how sets of Rules are used, and when each approach should be used.

Evaluation Paths

Rule-Based Evaluation (Using a Set of Rules)

This is the default behavior and applies when the evaluateByBBName parameter is not set or is set to false.

During evaluation, PlainID calculates a set of Rules for each Building Block based on its rule definition. This set of Rules represents the logical content of the Building Block and is used as the primary comparison mechanism.

Impact on Building Blocks

When evaluating by a set of Rules, Building Blocks are never updated. They can only be reused or newly created.

Evaluation behavior is as follows:

• If a Building Block with an identical set of Rules already exists in the target environment, that Building Block is reused.
• If no matching set of Rules exists, a new Building Block is created.
• Existing Building Blocks in the target environment are never modified, even if the incoming Policy contains changes.

Because set-of-Rules evaluation is content-based, changes to a Building Block rule in the source environment result in a different set of Rules. When promoted, this causes a new Building Block to be created in the target environment, often with an indexed name such as BBName (1).

As a result, the Policy can be imported or validated safely without impacting Building Blocks that may already be used by other Policies. However, over time, this behavior may lead to duplicated or orphaned Building Blocks across environments.

This approach is recommended when promoting Policies between environments where isolation and non-impact to shared Building Blocks are required.

Name-Based Evaluation (Update Building Blocks)

This behavior applies when evaluateByBBName is explicitly set to true.

In this mode, PlainID bypasses set-of-Rules-based matching and uses the Building Block name and type as the primary evaluation anchor. There is no fallback to set-of-Rules evaluation when this mode is enabled.

Evaluation behavior is as follows:

• If a Building Block with the same name and type exists in the target environment, its rule definition is compared to the incoming definition.

  • If differences are detected, the existing Building Block is updated to match the incoming Policy.

• If no Building Block with that name exists, a new Building Block is created.

• If a Building Block with a different name already exists in the target environment but has an identical set of Rules, the import fails. This prevents multiple Building Blocks with the same logical definition from coexisting under different names.

Because updates are applied directly, any Building Block that is shared across multiple Policies is updated consistently, similar to making changes through the UI.

This evaluation path ensures that Building Blocks remain logically aligned across environments and prevents duplication caused by set-of-Rules drift. It is best suited for controlled environments where Building Blocks are versioned and governed by name.

Comparison Summary

Import vs. Validation

Policy Validation

The Validate Policy API performs a dry-run evaluation. It applies the same evaluation logic, including set-of-Rules-based or name-based matching, but does not persist any changes.

When using evaluateByBBName=true, the list of affected Policies is included if a Building Block update would occur.

When name-based evaluation is enabled and updates would affect Building Blocks shared by other Policies, the validation response includes the identifiers of the impacted Policies. This allows customers to understand the potential impact before import.

Validation is typically used to assess the effect of promoting a Policy between environments.

Policy Import

The Import Policy API applies the selected evaluation logic and persists the result.

• With set-of-Rules-based evaluation, Building Blocks are reused or created, but never updated.
• With name-based evaluation, Building Blocks may be reused, created, or updated, and updates are reflected across all Policies that reference those Building Blocks.

PlainID supports two distinct evaluation paths during Policy import and validation to address different promotion and governance needs. The default set-of-Rules-based evaluation prioritizes safety by preventing changes to existing Building Blocks, making it suitable for environments where isolation and non-impact are critical. In contrast, name-based evaluation enables controlled updates by anchoring evaluation on Building Block names, ensuring consistency across environments and preventing duplication caused by rule changes across environments.

By selecting the appropriate evaluation path and using the evaluateByBBName parameter intentionally, customers can balance stability, consistency, and control when promoting Policies across environments.

To try out the APIs, refer to the Import Policy or Validate Policy API documentation.