Skip to main content
A maintenance policy defines when Korve reviews a project, the categories and environments in scope, and the hard ceiling for unattended actions.
Schedules are hourly, daily, or weekly. A manual run may narrow the saved categories and environments but cannot expand them. Equivalent active runs conflict instead of duplicating work. Policy updates use expectedVersion; reload after a 409 rather than overwriting another operator’s change.

​
Findings and evidence

Runs retain findings in security, reliability, performance, and cost, with severity, stable resource identity, recommendation, and first/last observed times. Evidence is immutable, redacted, and records whether it came from a metric, log, configuration, query, or verification step.

​
Remediation boundaries

The auto-remediation policy is an exact operation-id allowlist plus a read or write maximum risk and per-run action cap. Dangerous and destructive operations always require a human decision. The current failed-deployment reliability workflow proposes a bounded deploys.create retry and always records it as approval required, even if the policy allowlists that operation. Use the dashboard to approve or reject the exact action version with a reason. The session-only decision rechecks role, tenant, billing, target state, and schema before execution. A successful retry must reach ready before the action succeeds; a failed verification retains the last ready deployment as rollback evidence when one exists.
The audit trail is append-only across policy changes, runs, findings, decisions, execution, verification, and rollback. CLI and OAuth/API-key agents can inspect it; cancellation and action decisions remain session-only.