> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/configure-verify-step-with-ai/ai-verify.md). # Configure the AI Verify (v2) step Add the AI Verify (v2) step inside a Container Step Group to automatically verify your Kubernetes deployments using a combination of statistical and agentic analysis along with crisp insights. The AI Verify (v2) step deploys lightweight data collection plugins into your Kubernetes cluster to collect metrics and logs, strips personally identifiable information before data leaves your cluster, and produces a pass or fail verdict with actionable analysis. It runs exclusively inside a Container Step Group, which provides the Kubernetes infrastructure the plugins need to execute. {% hint style="info" %} **Feature availability** AI Verify is behind the feature flags `CDS_CV_AI_VERIFY_NG` and `CDS_CV_HEALTH_SOURCES_ENABLED`. Contact [Harness Support](mailto:support@harness.io) to enable these features. {% endhint %} *** ## What you will learn from this topic * **Container Step Group setup:** How to create a Container Step Group and configure its Kubernetes infrastructure so the AI Verify step can run inside it. * **Step parameters:** The data collection window, timeout, health sources, and optional resource limits that control how the AI Verify step collects and analyzes data. * **YAML structure:** The complete YAML for integrating AI Verify into a Blue-Green deployment pipeline, including a recommended baseline warm-up pattern. * **Execution results:** How to read the analysis verdict, agent timeline, and scatter plot in the execution view. *** ## Before you begin * **Health sources:** You need at least one health source configured for this project. You can create health sources in advance or directly from the AI Verify step configuration. Go to [AI-assisted health source configuration](/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/configure-verify-step-with-ai/ai-assisted-health-source.md) to create health sources. * **Kubernetes connector:** You need a Harness Kubernetes connector with permissions to create and delete pods in the target namespace. * **Kubernetes namespace:** The target namespace must already exist in your cluster. The step runs one pod with one container per health source inside that pod. {% hint style="info" %} **Contact Harness Support** If the AI Verify step does not appear in the step palette after the feature flags are enabled, contact [Harness Support](mailto:support@harness.io) or your account administrator. {% endhint %} *** ### Add the AI Verify (v2) step AI Verify (v2) must be placed inside a Container Step Group. You cannot add it as a standalone step outside a step group. {% stepper %} {% step %} **Add a Container Step Group** Open your pipeline and navigate to the **Execution** section of your deployment stage. After your deployment step, click **Add Step Group**. In the step group configuration panel, enter a name for the step group. {% hint style="warning" %} **Enable container-based execution** You must turn on the **Enable container-based execution** toggle in the step group configuration. Without this, the step group does not expose the infrastructure section and the AI Verify step does not appear in the step palette inside it. {% endhint %} {% endstep %} {% step %} **Configure the step group infrastructure** In the step group's **Container Runtime Infrastructure** section, configure where the plugin pod will run: 1. Select **Kubernetes Direct** as the infrastructure type. 2. Select the **Kubernetes Cluster Connector** for the cluster where you want the plugin pod deployed. 3. Enter the **Namespace** where the pod will run. This namespace must already exist. {% endstep %} {% step %} **Add and configure the AI Verify step** Inside the Container Step Group, click **Add Step**. Search for **AI Verification** and select the **AI Verify (v2)** tile (with the purple icon). The step configuration panel opens with the **Step Parameters** and **Advanced** tabs. {% endstep %} {% endstepper %} *** ### Configure step parameters The **Step Parameters** tab contains all the settings for the AI Verify step. ![AI Verify (v2) step parameters panel showing Name, Data Collection Window, Timeout, Health Sources, and Optional Configuration with resource limits](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-df7a95489e4dacea3b319c18aa0b8390c4064371%2Fai-verify-step.png?alt=media) | Parameter | Description | Required | | -------------------------- | ---------------------------------------------------------------------------------------------------------- | -------- | | **Name** | Name of the AI Verify step, displayed in the pipeline execution view. | Yes | | **Description** | Optional free-text description for the step. | No | | **Data Collection Window** | Duration for collecting logs and metrics; select from the dropdown or enter a value such as `5m` or `2h`. | Yes | | **Timeout** | Maximum time for the entire step. Must exceed the data collection window to allow for analysis processing. | Yes | | **Health Sources** | One or more AI Verify health sources to analyze, referenced by identifier. | Yes | | **Limit Memory** | Maximum memory per plugin container, for example `256Mi`. Under **Optional Configuration**. | No | | **Limit CPU** | Maximum CPU per plugin container, for example `250m`. Under **Optional Configuration**. | No | #### Name Enter a name that describes what the step verifies, for example `AI Verify Payment Service` or `Verify Production Deployment`. This name appears in the pipeline execution view. #### Data Collection Window The data collection window controls how long the plugin pod collects data from your observability platforms. The window begins when the step starts, so your deployment should be fully rolled out before the AI Verify step runs. Common values are `5m` for most deployments, `3m` for quick verifications, and `10m` for services that require longer observation periods. #### Timeout The timeout must exceed the data collection window because the step includes both the data collection phase and the analysis processing phase. If you set the data collection window to `5m`, set the timeout to at least `10m` to allow enough time for plugin startup, data collection, and analysis. If the step exceeds the timeout, it fails regardless of analysis state. {% hint style="success" %} **Recommended timing** A data collection window of `5m` with a timeout of `10m` works well for most deployments. Add a Shell Script step before the AI Verify step group to pause for one to two minutes after your deployment completes. This gives the new pods time to emit healthy baseline logs before the collection window opens. {% endhint %} #### Health sources Select the health sources you want to analyze. The step group runs a single pod with one plugin container per health source. Each container runs its own analysis independently and produces its own verdict. You can mix log-type and metric-type health sources in the same step. Click **+ Add** to open the health source selector and choose from health sources created at the project, organization, or account level. Each entry in the list shows: * Health source name * A **LOG** or **METRIC** badge indicating the data type * Edit and Delete icons {% hint style="info" %} Health sources are referenced by their identifier, not their display name. Go to [AI-assisted health source configuration](/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/configure-verify-step-with-ai/ai-assisted-health-source.md) to view and copy health source identifiers. {% endhint %} #### Optional configuration: Resources The **Optional Configuration** section exposes resource limits for the plugin containers. These default to `256Mi` memory and `250m` CPU, which handle typical workloads. Expand this section to override the defaults. * **Limit Memory:** Maximum memory per plugin container. Increase to `512Mi` or higher if you are analyzing high-volume data sources or see out-of-memory errors in pod logs. * **Limit CPU:** Maximum CPU per plugin container. Increase to `500m` or `1000m` if you see CPU throttling. Both fields accept Kubernetes resource notation. *** ### Write the YAML configuration You can configure the AI Verify (v2) step in YAML. The step type is `AIVerifyNG` and must be inside a `stepGroup` with a `stepGroupInfra` block that defines the Kubernetes infrastructure. The example below shows a complete Blue-Green deployment pipeline that includes a baseline warm-up step before the AI Verify step group. The warm-up step pauses briefly after the stage deployment completes to give the new pods time to emit healthy baseline data before the collection window opens.
Blue-Green pipeline with AI Verify (v2): full YAML ```yaml pipeline: name: BlueGreen_AI_Verify_Pipeline identifier: BlueGreen_AI_Verify_Pipeline projectIdentifier: your_project orgIdentifier: default stages: - stage: name: BlueGreen Deployment Stage identifier: BlueGreenDeploymentStage type: Deployment spec: deploymentType: Kubernetes service: serviceRef: my_service environment: environmentRef: my_environment deployToAll: false infrastructureDefinitions: - identifier: my_k8s_infrastructure execution: steps: - step: name: Stage Deployment identifier: stageDeployment type: K8sBlueGreenDeploy timeout: 10m spec: skipDryRun: false pruningEnabled: false - step: type: ShellScript name: Warm Up Baseline identifier: warmUpBaseline timeout: 5m spec: shell: Bash onDelegate: true source: type: Inline spec: script: | echo "Waiting for the stage pod to emit healthy baseline logs" sleep 120 environmentVariables: [] outputVariables: [] - stepGroup: name: AI Verify identifier: aiVerifyGroup steps: - step: type: AIVerifyNG name: AIVerifyV2 identifier: AIVerifyV2 spec: dataCollectionWindow: 5m healthSources: - healthSourceRef: my_health_source resources: limits: cpu: 250m memory: 256Mi timeout: 10m failureStrategies: - onFailure: errors: - AllErrors action: type: MarkAsFailure stepGroupInfra: type: KubernetesDirect spec: connectorRef: my_k8s_connector namespace: my_verify_namespace failureStrategies: - onFailure: errors: - AllErrors action: type: MarkAsFailure - step: name: Swap Primary and Stage Services identifier: swapPrimaryAndStage type: K8sBGSwapServices timeout: 10m spec: {} rollbackSteps: - step: name: Swap Primary and Stage Services identifier: rollbackSwapPrimaryAndStage type: K8sBGSwapServices timeout: 10m spec: {} failureStrategies: - onFailure: errors: - AllErrors action: type: StageRollback delegateSelectors: - my_delegate ```
**`stepGroup` fields:** * `stepGroupInfra.type`: Must be `KubernetesDirect`. * `stepGroupInfra.spec.connectorRef`: Identifier of your Kubernetes connector. * `stepGroupInfra.spec.namespace`: Namespace where the plugin pod runs. * `failureStrategies`: Set at the step group level to control what happens if the verification fails. `MarkAsFailure` fails the stage without rolling back; `StageRollback` triggers the rollback steps. **`AIVerifyNG` step fields:** * `spec.dataCollectionWindow`: Duration string such as `5m` or `2h`. * `spec.healthSources`: List of health source references. Each entry requires a `healthSourceRef` key. The step runs one plugin container per health source inside a single pod. * `spec.resources.limits.cpu`: CPU limit per plugin container, for example `250m`. * `spec.resources.limits.memory`: Memory limit per plugin container, for example `256Mi`. * `timeout`: Maximum step duration. Place this at the step level, not inside `spec`. *** ### View execution results Once the pipeline runs, click the AI Verify step to open its execution details. The **Analysis** tab shows the verification results for each health source. The verification status banner at the top shows whether the analysis passed or failed. When issues are detected, the interface shows a breakdown with Summary, Root Cause Hypothesis, Recommendation, Evidence, and Actionable Fix sections. These insights come from LLM contextualization of the statistical anomaly detection results. ![Analysis summary panel showing the pass/fail verdict and LLM-generated insights including root cause and recommendations](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-fd7cfc010b3321df5a033c8bec8e390d6d4bf022%2Fanalysis-summary-panel.png?alt=media) Below the summary, the Analysis tab shows the full execution view with an agent timeline on the left, a scatter plot in the center, and execution metadata at the top. ![Complete analysis tab view with agent timeline and scatter plot visualization](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5632467533b0e86e5bb5a6d7559d44c593ae14b0%2Fanalysis-tab-complete.png?alt=media) The agent timeline displays each processing phase with its duration. You will see Clustering Agent, Data Gatekeeper Agent, and other analysis components listed in sequence. Click the arrow next to any entry to expand the detailed logs for that phase. The scatter plot visualizes analyzed data points, showing Critical Regression and Non-Blocking Regression classifications. Normal behavior clusters together while anomalies appear as outliers. ![Scatter plot showing anomaly detection results with critical and non-blocking regression classifications](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-f8d1eb9b64eeb73a5b810b63ba66ed49cc391956%2Fscatter-plot-visualization.png?alt=media) Click **View Detailed Analysis** to open a full-screen view with cluster-by-cluster breakdowns, individual log patterns, and metric anomaly timelines. ![Events list tab showing all health events with Healthy, Warn, and Unhealthy indicators](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-cee0527cccfa5aa98d3e9fd3d2b81f2ccdf8786d%2Fevents-list-tab.png?alt=media) The **Events List** tab provides an alternative view showing all events with health indicators (Healthy, Warn, Unhealthy) and event types such as `NON_BLOCKING_REGRESSION` or `IGNORED_CLUSTER`. The **Details** tab shows execution metadata such as start time, duration, and timeout. The **Input** and **Output** tabs show the step's configuration parameters and execution outputs respectively. *** ## Next steps You have added the AI Verify (v2) step to your pipeline. The step will now analyze your deployment automatically each time the pipeline runs. * [AI-assisted health source configuration](/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/configure-verify-step-with-ai/ai-assisted-health-source.md): Create and manage the health sources that AI Verify references to collect logs and metrics. * [AI Verify (v2) overview](/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/configure-verify-step-with-ai/overview.md): Understand how statistical anomaly detection and LLM contextualization work together to produce verification verdicts. * [Interpret log results](/continuous-delivery/use-continuous-delivery/verify-deployments/cv-results/interpret-log-results.md): Read and act on the log analysis results from verification runs. {% @harness-feedback/feedback %}