diff --git a/README.md b/README.md
index e24e683..17758fe 100644
--- a/README.md
+++ b/README.md
@@ -1,59 +1,26 @@
 # sealed-secrets
 
-GitOps source-of-truth repository for the cluster Sealed Secrets controller.
+GitOps source for the cluster Sealed Secrets controller.
 
-This repo follows the same dormant-bootstrap pattern as the other application
-repositories, but the runtime payload is a pinned upstream Helm chart instead of
-raw kustomize manifests. The controller is installed in `kube-system` with the
-name `sealed-secrets-controller` so `kubeseal` works with its default controller
-name assumptions.
+## Current deployment
 
-## Layout
-
-```text
-.
-├── .gitea/
-│   └── workflows/validate.yaml
-├── .gitignore
-├── bootstrap/
-│   ├── applicationset.yaml
-│   └── config.yaml
-├── manifest/
-│   └── overlays/
-│       └── production/
-│           └── helm-values/
-│               └── values.yaml
-└── README.md
-```
-
-## Bootstrap activation model
-
-1. Prepare the repo on `init`.
-2. Keep `bootstrap/config.yaml` set to `enabled: false` while validating.
-3. Promote the repo to `main`.
-4. Change `bootstrap/config.yaml` to `enabled: true` on `main`.
-5. Let the bootstrap workflow apply `bootstrap/applicationset.yaml`.
-
-## Controller decisions
-
-- Namespace: `kube-system`
+- Bootstrap: `enabled: true`, applied from `main`
+- Argo application: `sealed-secrets-production`
+- Target namespace: `kube-system`
 - Helm chart: `bitnami-labs/sealed-secrets`
-- Chart version pin: `2.18.5`
-- Controller name override: `sealed-secrets-controller`
+- Chart version: `2.18.5`
+- Helm release name: `sealed-secrets-controller`
 
-The name override matters because the chart defaults to `sealed-secrets`, while
-`kubeseal` expects `sealed-secrets-controller` unless you pass explicit flags.
+## Runtime
+
+Argo CD renders the upstream Helm chart with values from
+`manifest/overlays/production/helm-values/values.yaml`. The controller name is
+kept as `sealed-secrets-controller` so `kubeseal` works with its default
+controller-name assumptions.
 
 ## Secret migration workflow
 
-1. Install `kubeseal` locally.
-2. Fetch the controller cert:
-   `kubeseal --fetch-cert --controller-namespace kube-system > sealed-secrets.pem`
-3. Convert an existing Secret manifest:
-   `kubeseal --format yaml --cert sealed-secrets.pem < secret.yaml > sealed-secret.yaml`
-4. Commit the resulting `SealedSecret` manifest in the owning app repo.
-5. Remove the old SOPS-backed secret generator entry only after the app is
-   syncing from the new `SealedSecret` path.
-
-Use the default `strict` scope unless a secret must survive renames inside the
-same namespace. Avoid `cluster-wide` scope unless there is a concrete need.
+Fetch the controller cert with `kubeseal --fetch-cert --controller-namespace
+kube-system`, seal app secrets into the owning app repo, then remove old
+SOPS/KSOPS secret generator entries only after the app syncs from the new
+`SealedSecret` path.