Skip to main content
Dorgu uses a progressive trust model that governs how much autonomy the system has over your cluster. Every action Dorgu takes maps to a specific trust level, and the system is designed so you can adopt it incrementally — starting with zero-risk observation and gradually enabling more automation as confidence grows.

​
Progressive Trust Levels

​
Current Implementation

Dorgu implements Levels 0 through 2. Levels 3 through 5 are planned. CLI (Level 1-2: RECOMMEND / PROPOSE)
  • Analyzes application source code and generates Kubernetes manifests
  • Produces ApplicationPersona CRDs that describe the desired operational profile
  • Proposes changes by generating files that a human reviews, commits, and deploys through existing GitOps workflows
  • Applies an approved remediation to the running workload, when that workload is Dorgu’s to change. When you run dorgu remediation approve, the CLI translates the fix you reviewed into a Deployment patch and applies it with your credentials, after showing you the exact namespace, Deployment, container, and fields, and asking for confirmation. If something else reconciles that Deployment, it declines instead and hands you the owner-shaped steps (see ownership)
Operator (Level 0-2: OBSERVE / RECOMMEND / PROPOSE)
  • Observes cluster state by watching Deployments, Pods, Nodes, and integration resources (ArgoCD, Prometheus)
  • Detects incidents, diagnoses root cause, and proposes an ordered fix as a RemediationAction — always in phase Pending, always requiring human approval
  • Validates running workloads against their ApplicationPersona constraints
  • Recommends improvements by writing suggestions to the persona’s status.recommendations field
  • Proposes changes through admission webhook warnings (advisory mode) or denials (enforcing mode)
  • Applies an approved remediation’s patch to the ApplicationPersona spec, then verifies the outcome and rolls it back automatically if health regresses
Neither the CLI nor the Operator ever deploys, scales, or modifies a workload without a human decision.

​
Level 2 in practice

The healing loop is what Level 2 looks like end to end:
1

The operator proposes

A RemediationAction is created in Pending with approval.required: true, an ordered plan, per-step diffs, risk levels, and a confidence score. Nothing has changed in your cluster.
2

You review

dorgu remediation diff shows the whole proposal. You approve or reject.
3

Approval splits by authority

The operator, with its own service account, patches the ApplicationPersona spec — the desired-state record. The CLI, with your credentials, patches the Deployment. The privilege to change a workload never leaves your hands.
4

The operator verifies

It waits out the verification window, re-runs detection, and either completes the remediation or restores the pre-patch state.
Auto-approve graduation is not implemented. policies.selfHealing.mode on the ClusterPersona decides how far the loop goes on its own — observe proposes nothing, propose (the default) proposes and waits — but auto-approve is accepted only for forward compatibility: the operator logs a warning and treats it as propose. trustLevel (0–5) and RemediationAction’s approval.autoApproveRule are ignored entirely. Every remediation waits for a human, whatever the mode or trust level says. maxRemediationsPerHour and excludeNamespaces on that same policy are enforced.

​
Ownership is a second axis

Trust level answers how much autonomy has Dorgu earned. It is not the only question. The other one is whose workload is this, and the answer does not depend on trust at all. A Deployment that Helm, ArgoCD, or Flux reconciles already has an owner, and that owner’s next apply is what has to carry any fix. So for those workloads Dorgu is understanding and recommendation only, at every trust level. It detects, diagnoses, and tells you exactly what to change in your source of truth, and it does not patch the Deployment. There is no override flag. This is not a limitation grafted onto the trust model; it is the trust model applied honestly. Level 2 says “propose, a human approves”. A workload owned by Helm has already delegated its desired state to a pipeline, and writing around that pipeline is not something a per-remediation approval can make correct: the fix works, and the owner’s next deploy fails on a field-manager conflict. See the ownership model for how ownership is detected, exit code 4, and what the refusal looks like.

​
Non-Negotiable Invariant

The Dorgu Operator never creates or modifies Deployments, Services, or other workload resources. This is a foundational design constraint, not a configuration option.
And it is enforced by Kubernetes rather than by Dorgu’s own code. The operator’s ClusterRole grants get, list, watch on apps/deployments and nothing more, and no access to Secrets at all. A bug, a malicious AI-written plan, or a compromised operator pod still cannot patch a Deployment through that service account. The role is published in full, with the denied verbs called out and a kubectl auth can-i recipe to check it on your own cluster. The Operator is permitted to:
  • Read cluster state (Deployments, Pods, Nodes, ArgoCD Applications, Prometheus metrics)
  • Validate workloads against Persona constraints
  • Recommend changes via status fields, webhook warnings, and RemediationAction proposals
  • Update Persona CRD status and learned fields
  • Patch the ApplicationPersona spec — but only the fields in a RemediationAction a human has approved
The Operator is not permitted to:
  • Create, update, or delete Deployments
  • Create, update, or delete Services
  • Modify any workload resource in any way
Deployment remains the responsibility of your existing tools: ArgoCD, Flux, Helm, kubectl, or whatever you use today. Dorgu adds observability and guardrails on top of your existing workflow without replacing any part of it. The two halves of that guarantee are enforced in different places, and both are needed:

​
Why Progressive Trust

The progressive trust model exists because automation in production environments must be earned, not assumed. Start safe. Level 0 (OBSERVE) carries zero risk. The Operator only reads cluster state and writes to its own CRD status fields. You can install Dorgu and gain immediate visibility without changing any existing workflow. Build confidence. At Level 1-2 (RECOMMEND / PROPOSE), Dorgu generates suggestions and validates changes, but a human is always in the loop. You see what Dorgu would do before it does anything. Over time, as you validate that Dorgu’s recommendations are consistently correct, you develop trust in the system’s judgment. Enable gradually. Higher trust levels unlock more automation, but always with explicit opt-in. Moving from one level to the next is a deliberate decision, not an automatic escalation. This approach mirrors how trust works in any engineering organization: new team members start with limited access, prove their reliability through consistent good judgment, and gradually earn more responsibility.

​
Future Levels

Levels 3 through 5 are planned for future phases of Dorgu’s development. Level 3 (DEPLOY-DEV) will enable automated deployment to development and staging environments. Changes would still require manual promotion to production, giving teams a low-risk way to experience automated deployments. Level 4 (DEPLOY-PROD) will extend automated deployment to production, but with mandatory approval gates. Deployments would go through a proposal-review-approve workflow before execution. Level 5 (AUTONOMOUS) represents full autonomy, where the system can make deployment decisions without human intervention. This level will require extensive safeguards, including rollback triggers, blast radius limits, and comprehensive observability. It is a long-term goal, not a near-term priority. Each level will be opt-in per application and per environment, so you can run different trust levels for different workloads based on their criticality and your confidence in the system.