Evidence you can verify, with boundaries you can trust.
KrevoPilot publishes dated technical evidence for diagnosis accuracy and documents the controls implemented for customer data, access and optimization. We distinguish verified results from operating targets and outcomes that still require customer history.
Evidence summary
A technical evidence summary for buyers and reviewers. It is not a universal accuracy guarantee, an uptime claim, a certification, or a substitute for contractual security and privacy terms.
Published Krevo AI investigation benchmark
On 23 August 2026, Krevo AI correctly diagnosed all 14 controlled Kubernetes failure scenarios in the published corpus through the normal agent, platform and investigation path.
| Recorded evidence | Published value |
|---|---|
| Strict diagnosis accuracy | 14 / 14 (100%) |
| Semantic diagnosis accuracy | 14 / 14 (100%) |
| Application commit | 7144d8a881936185e427aa15da4a3096e9618088 |
| Agent / Helm chart | 2.0.34 / 0.1.34 |
| Kubernetes server | v1.36.1 |
| Evidence freshness | Snapshot age 24.7 seconds; validity limit 180 seconds |
For the covered, deliberately broken scenarios, the primary diagnosis matched the expected failure class, used compatible evidence and provided an appropriate remediation direction.
The result does not cover every Kubernetes failure, multi-fault incident, external managed service, missing-telemetry case or novel production condition.
Security and customer-data controls
Current documented retention periods include 7 days for full snapshots, 14 days for raw metrics, 90 days for hourly optimization rollups, 180 days for operational events/state and 30 days for sanitized incident evidence. Backup windows and contractual deletion terms are disclosed separately.
Optimization is measured after the change
KrevoPilot separates estimated opportunity from realized savings. A recommendation does not become a verified outcome merely because a user applied it.
Savings are reported as realized only after the changed configuration has enough healthy post-change evidence. A regression is identified instead of being counted as success.
Operational readiness
The production package includes independent health monitoring, database backup and verification procedures, a restore-drill workflow, weekly reliability reporting, incident severity guidance and a release checklist.
| Control | Status | Evidence treatment |
|---|---|---|
| Service and dependency health probes | Implemented | Results are retained by the configured monitor. |
| Database backup verification | Implemented | Backup creation, integrity and age are checked. |
| Restore drill | Procedure available | Operators must run and retain dated drill evidence. |
| Customer-facing uptime | Accumulating | No achieved percentage is claimed until an independent observation window exists. |
| External customer outcomes | Pilot validation in progress | SoftKAI early-access pilot notes are published with a clear disclosure. Final outcomes and any testimonial remain subject to customer approval. |
Evidence boundaries
An internal test is not customer validation; estimated savings are not realized savings; a configured monitor is not an achieved uptime record; and a bounded benchmark is not universal incident accuracy.
- Generated commands, patches and YAML remain review-first and must be approved by an authorized operator.
- Investigation quality depends on the evidence available from the selected cluster and privacy configuration.
- Security documentation describes implemented product controls; certifications and contractual commitments are stated only when separately completed.
- Each benchmark claim is dated and tied to exact software versions so later releases can be assessed independently.