krnali Ops: from a finding to a checked outcome.

The observer remains read-only

Ops runs inside the customer's environment. Its operator reads Kubernetes state and supported signals, learns bounded local baselines, and writes krnali-owned Findings and Baselines. It does not gain permission to edit customer workloads or execute inside a pod.

The core works without a language model. Measurements, forecast values, confidence scores and source-health states come from deterministic code. An unavailable source is an unavailable source, not evidence that everything is healthy.

Current: clearer findings and investigations

The operator detects crash loops, image and configuration failures, HPA saturation, node pressure and rollout regression. Reactive detectors now resolve their own findings after the symptom has been absent for a measured quiet window. Acknowledging a finding in the portal does not declare the workload recovered.

Cross-stack investigations group related symptoms across workloads and namespaces. They retain supporting and contradicting evidence, competing explanations, unknowns and the next checks. A pattern shared by several workloads is a reason to investigate together; it is not proof of a common cause.

Memory forecasts now have explicit fit, freshness and horizon gates. Unsupported forecasts remain historical and unassessable. The confidence score is a deterministic score, not a calibrated probability of failure.

The portal separates new and returned findings from work being handled and retained history. Its optional “Explain this workload” panel can use a customer-run, Ollama-compatible model endpoint. Numbers in the explanation must be present in the supplied evidence; that check does not verify every prose claim. The panel is optional and off by default.

Current: a separate path for authorised fixes

krnali-act is installed and authorised separately from the observer. The current registered action raises a Deployment container's memory limit. It is a typed operation with a measured target, a preview, approval, outcome verification and rollback handling.

Source identity and freshness are checked before preview and execution. The portal shows the actual proposed change and the authority required to approve it. The default is one human approval per fix.

A person can grant standing permission for a supported action class after supervised use. That permission is explicit and revocable. It does not let the system invent a new action class or give itself broader authority.

Real-cluster checks have exercised an approved raise, a completed rollout, verification of the live limit and human rollback. Negative paths include unapproved inaction and identity denial. A successful test of one bounded action is not a claim of general autonomous remediation.

In integration: retain the operational history

The next work is about continuity. Attributed decisions and outcome reviews should survive a portal replacement. Investigation cases should retain what was checked and what remains unknown. Historical memory evidence should carry its units, window, source and freshness into the finding.

Work on those capabilities exists in integration branches, together with bounded customer operational context and recurrence reviews. It is not yet part of the default-branch product. Broader source coverage and calibration need their own evidence before they become a release claim.

Try Ops with us

Ops remains in private preview. Installation is arranged directly with founding teams, and the source repository remains private. The public EUDI message verifier repository is a separate Labs project; its publication does not change Ops access.

For the preview, tell us the cluster you run and the operational problem you are trying to understand. We can then work through whether the current capability fits it.