Trust Model

Progressive trust levels for Kubernetes automation

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

Level	Name	Description	Who Acts
0	OBSERVE	Read cluster state, no writes	Operator
1	RECOMMEND	Generate suggestions, human applies	CLI
2	PROPOSE	Create PRs/proposals, human approves	CLI + Operator
3	DEPLOY-DEV	Deploy to dev/staging, human promotes	Future
4	DEPLOY-PROD	Deploy anywhere with approval gates	Future
5	AUTONOMOUS	Make decisions without human intervention	Future

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 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

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.

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.

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.

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.