SoftTech AI Registry
Harness · Harness Continuous Delivery

AI Verify — ML-directed deployment rollback

Harness ML-based deployment verification derives deployment-health signals from baseline deviation and log-pattern analysis. Customer-configured sensitivity determines when that derived health state causes verification failure. Where automatic rollback is configured as the failure response, that failure can cause Harness deployment machinery to roll back the affected production deployment without a human independently approving the rollback at runtime. This is a constrained verification-to-rollback chain, not general autonomous deployment management.

Recorded characteristics

Function
Harness states that it "applies machine learning algorithms to every deployment for identifying normal behavior" and that "During the AI Verify (v1) step, Continuous Verification automatically triggers a rollback if anomalies are found." The Continuous Verification FAQs state that "Harness rolls this into a Healthy, Medium Healthy, or Unhealthy status, and the step fails (triggering your failure strategy, such as rollback) when the status exceeds your sensitivity tolerance." Recorded chain: deployment telemetry → ML/model-derived deviation and/or log-pattern analysis → health status → customer-configured sensitivity boundary → Verify step failure → configured failure strategy → automatic rollback → production deployment state changes. Rollback can alter or withdraw the affected production deployment and restore the applicable previous or stable deployment state according to the configured deployment strategy and rollback steps. Preventing further rollout, rolling back a canary, stage rollback, pipeline rollback and returning an affected workload toward its previous/stable deployment state are distinct outcomes; which occurs depends on configuration and deployment strategy. This is not an unconstrained AI independently deciding whether to roll production back, and no generative model selects arbitrary deployment actions or generates rollback commands.
Data access
Verification analyses deployment telemetry from configured health sources (metrics and logs from monitoring/logging providers), comparing the new deployment against a baseline.
Actions
Can take actions
External actions
Yes
Human confirmation
Conditional
Permission basis
Separate permissions
Administrative control
Human confirmation (conditional): Harness supports an automatic rollback path, triggered through the configured failure strategy, without individual runtime human approval; it also supports human paths, including the Manual Intervention failure-strategy action and options that mark the step as success or ignore the failure (which do not roll back). Prior configuration of verification, sensitivity or rollback behaviour is not runtime confirmation. Human confirmation is neither universally required nor universally absent. Permission basis (separate_permissions): Harness states that "The delegate performs all operations, including deployment and integration", and that "Connectors are used for all third-party connections", including pipeline infrastructure connections to target environments; AI Verify (v2) requires "a Harness Kubernetes connector with permissions to create and delete pods". Deployment and rollback operations therefore run through Harness execution infrastructure (Delegates and configured connector/target-environment credentials), configured separately from the ordinary permissions of the human who configures, starts or interacts with the pipeline. Who can configure/start the pipeline is distinct from the runtime authority used to execute deployment/rollback. Different underlying connector credential technologies do not make this "mixed". The Delegate is not an AI identity, no dedicated AI identity is documented, and not all deployment targets use the same credential technology. Sensitivity options: High, Medium (default) and Low.
Default state
Conditional
Availability
The consequential capability depends on deployment configuration, adding and configuring the Verify step and health sources, sensitivity, and the failure-strategy configuration. Harness states "Steps do not have a default failure strategy" (they inherit the stage's), and each stage has a default failure strategy that can be edited. The accompanying text does not establish the default failure action, so the Registry does not claim automatic rollback is universally enabled or universally disabled by default.
Licensing
Licensing per verification feature is not recorded here.
External model or provider
Harness's own analysis; no external model provider documented. Metric analysis: Harness documents "The ML model (Symbolic Aggregate Approximation)" and baseline/deviation analysis with standard-deviation-based results; the customer chooses the sensitivity boundary (documented as roughly 1σ High, 2σ Medium, 3σ Low). This is statistical/model-derived comparison against a baseline, not open-ended AI reasoning. Log analysis: machine-learning clustering/pattern analysis classifying events as Known, Unknown and Unexpected Frequency, which Harness says "can not be done by any fixed" rules — the stronger ML evidence. The runtime signal evaluated is derived from Harness analysis rather than being merely a customer-authored raw fixed threshold. SAX is attributed only where Harness documents it (metric analysis) and is not generalised to every verification type or health source.
Limitations and uncertainty
Negative control: Threshold Analysis [No ML] and Fail Fast threshold paths are outside this capability and are not evidence of ML-directed rollback. Not every Harness verification uses AI or machine learning; not every unhealthy verification causes rollback; rollback is not always automatic; human intervention is possible. AI Verify (v1) and AI Verify (v2) are documented separately; v2 documentation shows a StageRollback step in its example pipeline. The Registry does not claim: that AI invents remediation or generates rollback commands; that Harness autonomously administers production generally; that rollback universally restores infrastructure, runtime configuration, databases or application data, external side effects or unrelated services; that every target uses the same runtime identity; that rollback is exactly-once or transactional across clusters or regions; that every AI Verify result uses the same underlying model; or that AI independently selects arbitrary deployment operations. Rollback scope depends on configuration and deployment strategy: no universal maximum blast radius; rollback does not necessarily affect an entire service, nor only a canary subset. Not publicly established: exact ML architecture across every verification type; training data; model version; exact algorithm for every health-source/provider combination; universal risk-score formula; universal confidence threshold; exact weighting between ML-derived results and other conditions; whether every AI Verify result uses the same underlying model; exact runtime principal for every supported deployment target; universal maximum rollback blast radius; universal rollback retry count; exactly-once rollback; duplicate rollback suppression; universal rollback idempotency; rollback transactionality; cross-cluster atomicity; cross-region atomicity; complete restoration after partial rollback; universal restoration of infrastructure state; universal restoration of application runtime configuration; database or application-data restoration; complete model-decision provenance; universal retention of exact model input/output; universal automatic escalation following rollback failure.

Evidence