This section focuses on deploying computational governance policies in Blindata. Policy deployment is a critical step in ensuring governance processes are seamlessly integrated into your data product lifecycle. Blindata simplifies this by providing robust tools for managing and monitoring deployed policies.

Summary of Policy Implementation and Types

Policies in Blindata can be categorized into different types based on their evaluation and implementation requirements:

• Documentation Only Policies: Provide guidelines but do not require formal verification or deployment.
• Adoption Only Policies: Require acknowledgement but lack verification or an implementation tab.
• Manual Verification Policies: Include manual workflows for evaluation but do not provide automated implementations.
• Automated Verification Policies: Require implementation as code and support deployment and redeployment processes.

Implementation Operations by Policy Type

1. Adoption-Only and Manual Verification Policies: These policies do not include an implementation step. Adoption involves associating policies with data products, and evaluation is managed through manual processes.
2. Automated Policies: These policies support implementation as code. Deployment involves associating the policy with a code artifact that performs automated evaluations.

Implementation and Deployment in Blindata

To implement and deploy a policy, follow these steps:

Define the Policy

Policies are defined and documented in Computational Governance Policies dedicated guide.

Add Implementation (For Automated Policies)

For automated policies, Blindata provides an intuitive Implementation Tab to manage and configure policy implementations. Follow these steps to add an implementation:

1. Navigate to the desired policy in the Policies Repository.
2. Open the Implementation Tab.
3. Enter the required details for the policy’s evaluation logic, tailored to the validator engine being used.

When configuring an implementation, you will be prompted to provide the following information:

• Display Name: A user-friendly name for the implementation.
• Name: A unique technical identifier for the implementation.
• Description: A brief description of the implementation.
• Policy Engine: The policy engine responsible for executing the logic.
• Policy Body: The code or configuration defining the policy, based on the selected policy engine.
• Evaluation Condition: A conditional filter applied to events, ensuring the policy is only evaluated when the condition matches the incoming event. This condition is applied as a Spel expression over the policy evaluation content as discussed in the next paragraph.
• Evaluation Events: One or more specific events that trigger the policy evaluation.
• Version: The version number of the implementation.
• Blocking: A flag indicating whether the policy blocks further progression of the associated process if violated.

Evaluation Conditions

To ensure that policies are only applied when relevant, you can define evaluation conditions. These conditions act as filters, determining whether a policy should be evaluated based on the incoming event data. Filtering conditions are expressed using Spel (Spring Expression Language), a powerful expression language that allows you to dynamically access and manipulate objects and their properties within the Blindata platform.

Example conditions:

• afterState.activity.stage == 'Staging' - Applies the policy only when an activity is transitioning to the “Staging” stage.
• currentState.task.status == 'FAILED' - Triggers the policy only when a specific task fails during execution.
• afterState.dataProductVersion.info.domain == 'Finance' - Applies the policy only to data products within the “Finance” domain.

By using filtering conditions, you can precisely target policy enforcement, improve efficiency by filtering out irrelevant events, and create a more organized and manageable policy framework.

Deploy the Policy

Once the implementation is ready, deploy the policy to make it operational:

1. go to the Deployment Card on the right side of the policy detail page.
2. Click Deploy New Version.
3. Confirm the deployment. The deployed version will now be available in the card, showing the following details:
   • Deployed Version Number
   • Deployment Timestamp
   • Status (e.g., Active, Pending Validation)

Manage Deployed Policies

The Deployment Card allows you to:

• View the Deployed Versions: Access details of all active deployments, including implementation logic.
• Redeploy: If updates to the implementation are needed, click Redeploy New Version to replace the existing deployment.
• Delete Deployment: Remove the deployed version from the platform, effectively unbinding the policy from automated operations.

Collecting Policy Evaluation Results

Policy evaluation results are gathered by the Blindata Observer for Open Data Mesh. The Policies Upload use case collects all evaluation results for a specified data product and uploads them to Blindata for centralized management.

This process can be triggered following these supported event types:

• DATA_PRODUCT_VERSION_CREATED: Captures results immediately after a new data product version is registered.
• DATA_PRODUCT_ACTIVITY_COMPLETED: Gathers results after the completion of a DevOps stage, for example after the release in production.

Using trace in OPA Policy Implementations

When implementing automated computational policies with OPA (Open Policy Agent), it is strongly recommended to design policies that not only return a boolean decision (allow / deny), but also provide human-readable explanations in case of failures.

Why Use trace

Using trace inside a policy allows you to:

• Explain why a policy failed, not just that it failed
• Guide users toward corrective actions
• Improve debugging during policy development
• Produce structured, readable outputs for the Blindata UI

Typical use cases include:

• Missing or invalid metadata
• Structural inconsistencies in descriptors
• Governance rules that require user action

Logging levels

To see policy explanations (including trace() messages) in the UI, enable explanations on the evaluation request by setting verbose = true. The adapter then calls OPA with an explanation level. You can set the logging level to one of the following:

Use notes or leave it unset for normal use; use debug or full only when developing or debugging policies.

Example: Validating Contact Points Descriptions

The following example shows a policy that validates that all contact points in a Data Product Descriptor have a non-empty description.

If a description is missing or empty, the policy:

• Fails validation (allow = false)
• Emits one or more trace notes explaining the issue
• Returns a structured list of missing descriptions

Policy Implementation (OPA / Rego)

package dataproduct

import future.keywords.in

default allow := false
default missing_descriptions := []

# Normalize description:
# - missing field   -> ""
# - null value      -> ""
desc(cp) := d {
  d := cp.description
}

desc(cp) := "" {
  not cp.description
}

desc(cp) := "" {
  cp.description == null
}

has_text(s) {
  not re_match("^\\s*$", s)
}

missing_descriptions := [
  sprintf(
    "Missing description for contact point '%v' (%v)",
    [cp.name, cp.address]
  ) |
  some cp in input.afterState.info.contactPoints
  d := desc(cp)
  not has_text(d)
  trace(
    sprintf(
      "FAIL: contactPoint '%v' has empty/missing description",
      [cp.name]
    ),
    true
  )
]

allow {
  trace(
    "Start validation: checking contactPoints descriptions",
    true
  )
  count(missing_descriptions) == 0
}

Evaluation Result Structure

When this policy is evaluated with explain=notes (or higher), the validator returns a rich and structured response, including both the execution trace and the semantic result of the evaluation.

Below is an example of the final output object produced by the policy:

{
  "outputObject": {
    "decision_id": "851300e5-d1a1-41a0-a19f-26a07f095852",
    "explanation": [
      "query:1            Enter data.dataproduct = _",
      "dataproduct:33     | Enter data.dataproduct.allow",
      "dataproduct:34     | | Note \"Start validation: checking contactPoints descriptions\"",
      "dataproduct:25     | | Enter data.dataproduct.missing_descriptions",
      "dataproduct:30     | | | Note \"FAIL: contactPoint 'Data Product Owner' has empty/missing description\"",
      "dataproduct:30     | | | Note \"FAIL: contactPoint 'Data Platform Lead' has empty/missing description\""
    ],
    "result": {
      "allow": false,
      "missing_descriptions": [
        "Missing description for contact point 'Data Product Owner' (pasquale.test@mail.com)",
        "Missing description for contact point 'Data Platform Lead' (francesca.test@mail.com)"
      ]
    }
  }
}

OPA Adapter configuration (Data Ops Platform)

The following settings apply to the OPA adapter of the Data Ops Platform. Use them to control how much detail is returned when policies are evaluated (e.g. for explanations in the UI).

##########################
# OPA adapter - Data Ops Platform
##########################
opa:
  url:
    loggingLevel: "notes|debug|full"