+ It works out why a workload is failing, then opens a pull request.

Yet another LLM SRE operator. It watches a Kubernetes cluster, groups the symptoms of one failure together, finds the manifest in your GitOps repository that produced the object, and proposes a minimal patch with the evidence it rests on. It never changes the cluster.

An operator that edits your cluster to fix it creates two problems. The change is invisible to the repository that is supposed to describe the cluster, and the next reconcile undoes it. YALSO does not do that. Every fix it proposes arrives the way any other change does: as a pull request that a human reads and merges.

The consequence is that a wrong answer costs a review, not an outage. That trade is the whole design, and the rest of this page is what follows from it.

Citation

Every statement in the analysis must cite a piece of evidence that was actually collected, and every hunk must cite evidence that reaches the field it changes. A finding that cites nothing is not a finding.

Verification

A second model call is shown the analysis and the same evidence and asked whether it holds. Agreement is required, and it is unanimous across every judgement in the reply: one disagreement refuses the analysis.

Minimality

The patch is bounded in hunks and in changed lines, and it may not repeat a change to a field it has already touched. A fix that rewrites a file is not a fix.

A language model will produce a confident answer whether or not it has grounds for one. These exist because that is the failure mode. A refusal is recorded on the incident with its reason, so a gate that fires is visible rather than silent.

helm install yalso ./charts/yalso \
  --namespace yalso-system --create-namespace \
  --set api.enabled=true

Then apply a YalsoConfig named default naming your model endpoint and the repositories it may propose against, and read the status conditions. The chart refuses a values file that oversteps: a key shaped like a credential, a key that belongs in a custom resource, and a replica count are each rejected at render time with the reason.

helm test yalso -n yalso-system --logs

It is a retention window, not a history

Resolved issues and finished incidents are pruned on the schedule the configuration sets. Nothing can answer a question about a record that has already expired, and the API says so in its own description.

It can only patch what a manifest declares

A rendered Helm chart committed to a repository is patchable, because the object is a file. A chart rendered at deploy time is not: a patch to rendered output does not survive the next render, so the operator declines it and explains instead.

Because the reasoning came from a language model, and a reviewer who cannot check it is being asked to trust it. Every proposal carries the evidence each statement cites, the gates that ran, the hashes of the evidence and the rules that produced it, and a section headed Not claimed.

github.com/lukaszraczylo/yalso — MIT licensed. Written in Go on controller-runtime, distributed as a multi-architecture image and a Helm chart.