diff --git a/.golangci.yaml b/.golangci.yaml
index 354eb970..488e676e 100644
--- a/.golangci.yaml
+++ b/.golangci.yaml
@@ -42,8 +42,8 @@ linters-settings:
       alias: $1$2
     - pkg: sigs.k8s.io/controller-runtime
       alias: ctrl
-    - pkg: github.com/operator-framework/rukpak/api/v1alpha1
-      alias: rukpakv1alpha1
+    - pkg: github.com/operator-framework/rukpak/api/v1alpha2
+      alias: rukpakv1alpha2
   goimports:
     local-prefixes: github.com/operator-framework/rukpak
 
diff --git a/api/v1alpha2/bundledeployment_types.go b/api/v1alpha2/bundledeployment_types.go
index 2e44be59..ab1395e8 100644
--- a/api/v1alpha2/bundledeployment_types.go
+++ b/api/v1alpha2/bundledeployment_types.go
@@ -27,9 +27,8 @@ var (
 )
 
 const (
-	TypeHasValidBundle = "HasValidBundle"
-	TypeHealthy        = "Healthy"
-	TypeInstalled      = "Installed"
+	TypeHealthy   = "Healthy"
+	TypeInstalled = "Installed"
 
 	ReasonBundleLoadFailed          = "BundleLoadFailed"
 	ReasonCreateDynamicWatchFailed  = "CreateDynamicWatchFailed"
diff --git a/docs/provisioners/helm.md b/docs/provisioners/helm.md
index 6ed20d00..3cde3146 100644
--- a/docs/provisioners/helm.md
+++ b/docs/provisioners/helm.md
@@ -3,7 +3,7 @@
 ## Summary
 
 The `helm` provisioner is one of the [provisioners](https://github.com/operator-framework/rukpak/tree/main/internal/provisioner) of RukPak.
-It is able to instantiate a given `helm+v3` bundle with a specified helm chart onto a cluster where it then installs the content. It does so by reconciling `Bundle` and `BundleDeployment` types that have
+It is able to instantiate a given `helm+v3` bundle with a specified helm chart onto a cluster where it then installs the content. It does so by reconciling `BundleDeployment` types that have
 the `spec.provisionerClassName` field set to `core-rukpak-io-helm`. This field must be set to the correct provisioner
 name in order for the `helm` provisioner to see and interact with the bundle.
 
@@ -25,7 +25,7 @@ all present the same content, a directory containing a helm chart, in a differen
 The `helm` provisioner can install and make available a specific `helm+v3` bundle in the cluster. To do this, the `helm` provisioner will retrieve the configured helm chart, instantiate a Bundle onto the cluster, and eventually install the desired helm chart on the cluster.
 
 ```yaml
-apiVersion: core.rukpak.io/v1alpha1
+apiVersion: core.rukpak.io/v1alpha2
 kind: BundleDeployment
 metadata:
   name: my-ahoy
@@ -55,30 +55,21 @@ spec:
       service:
         type: ClusterIP
         port: 80
-  template:
-    metadata:
-      labels:
-        app: my-ahoy
-    spec:
-      provisionerClassName: core-rukpak-io-helm
-      source:
-        http:
-          url: https://github.com/helm/examples/releases/download/hello-world-0.1.0/hello-world-0.1.0.tgz  
-        type: http
+    source:
+      http:
+        url: https://github.com/helm/examples/releases/download/hello-world-0.1.0/hello-world-0.1.0.tgz  
+      type: http
 ```
 
 For the helm chart, the values file embedded in the `config` can be applied during the installation of the chart.
 
-> Note: the generated Bundle will contain the BundleDeployment's metadata.Name as a prefix, followed by
-> the hash of the provided template.
-
 As the bundle content is retrieved and stored onto the cluster via the defined storage mechanism, the bundle status
 will be updated to Unpacked, indicating that all its contents have been stored on-cluster.
 
 ```console
-$ kubectl get bundle -l app=my-ahoy
+$ kubectl get bundledeployment -l app=my-ahoy
 NAME                 TYPE   PHASE      AGE
-my-ahoy-5764594dc8   http   Unpacked   33s
+my-ahoy   http   Unpacked   33s
 ```
 
 Now that the bundle has been unpacked, the provisioner is able to create the resources in the bundle on the cluster.
@@ -91,8 +82,6 @@ NAME      ACTIVE BUNDLE        INSTALL STATE           AGE
 my-ahoy   my-ahoy-5764594dc8   InstallationSucceeded   48s
 ```
 
-> Note: Creation of more than one BundleDeployment from the same Bundle will likely result in an error.
-
 ## Quick Start
 
 ### Setup
@@ -127,33 +116,27 @@ make run
 
 ### Installing the sample chart
 
-From there, create some Bundles and BundleDeployment types to see the provisioner in action. For an example helm chart to
+From there, create some BundleDeployment types to see the provisioner in action. For an example helm chart to
 use, the [helm/examples](https://github.com/helm/examples) is a good example.
 
 Create the sample BundleDeployment referencing the desired sample helm chart in Bundle configuration:
 
 ```bash
 kubectl apply -f -<<EOF
-apiVersion: core.rukpak.io/v1alpha1
+apiVersion: core.rukpak.io/v1alpha2
 kind: BundleDeployment
 metadata:
   name: my-ahoy
 spec:
   provisionerClassName: core-rukpak-io-helm
-  template:
-    metadata:
-      labels:
-        app: my-ahoy
-    spec:
-      provisionerClassName: core-rukpak-io-helm
-      source:
-        http:
-        git:
-          ref:
-            branch: main
-          repository: https://github.com/akihikokuroda/examples
-          directory: ./charts
-        type: git
+  source:
+    http:
+    git:
+      ref:
+        branch: main
+      repository: https://github.com/akihikokuroda/examples
+      directory: ./charts
+    type: git
 EOF
 ```
 
@@ -166,18 +149,18 @@ EOF
 bundledeployment.core.rukpak.io/my-ahoy created
 ```
 
-Next, check the Bundle status via:
+Next, check the BundleDeployment status via:
 
 ```bash
-kubectl get bundle -l app=my-ahoy
+kubectl get bundledeployment -l app=my-ahoy
 ```
 
-Eventually the Bundle should show up as Unpacked:
+Eventually the BundleDeployment should show up as Unpacked:
 
 ```console
-$ kubectl get bundle -l app=my-ahoy
-NAME                 TYPE   PHASE      AGE
-my-ahoy-5764594dc8   git    Unpacked   33s
+$ kubectl get bundledeployment -l app=my-ahoy
+NAME            PHASE      AGE
+my-ahoy         Unpacked   33s
 ```
 
 Check the BundleDeployment status to ensure that the installation was successful:
@@ -190,8 +173,8 @@ A successful installation will show InstallationSucceeded as the `INSTALL STATE`
 
 ```console
 $ kubectl get bundledeployment my-ahoy
-NAME      ACTIVE BUNDLE        INSTALL STATE           AGE
-my-ahoy   my-ahoy-5764594dc8   InstallationSucceeded   48s
+NAME         INSTALL STATE           AGE
+my-ahoy      InstallationSucceeded   48s
 ```
 
 From there, ensure that the helm chart is installed and the operator is present on the cluster:
@@ -239,7 +222,7 @@ Add a values file into the BundleDeployment to override some default values:
 
 ```bash
 kubectl apply -f -<<EOF
-apiVersion: core.rukpak.io/v1alpha1
+apiVersion: core.rukpak.io/v1alpha2
 kind: BundleDeployment
 metadata:
   name: my-ahoy
@@ -269,19 +252,13 @@ spec:
       service:
         type: ClusterIP
         port: 80
-  template:
-    metadata:
-      labels:
-        app: my-ahoy
-    spec:
-      provisionerClassName: core-rukpak-io-helm
-      source:
-        git:
-          ref:
-            branch: main
-          repository: https://github.com/akihikokuroda/examples
-          directory: ./charts
-        type: git
+source:
+  git:
+    ref:
+      branch: main
+    repository: https://github.com/akihikokuroda/examples
+    directory: ./charts
+  type: git
 EOF
 ```
 
@@ -313,7 +290,7 @@ Change this a value in the values file.  Update the `nameOverride` to `name1`
 
 ```bash
 kubectl apply -f -<<EOF
-apiVersion: core.rukpak.io/v1alpha1
+apiVersion: core.rukpak.io/v1alpha2
 kind: BundleDeployment
 metadata:
   name: my-ahoy
@@ -343,19 +320,13 @@ spec:
       service:
         type: ClusterIP
         port: 80
-  template:
-    metadata:
-      labels:
-        app: my-ahoy
-    spec:
-      provisionerClassName: core-rukpak-io-helm
-      source:
-        git:
-          ref:
-            branch: main
-          repository: https://github.com/akihikokuroda/examples
-          directory: ./charts
-        type: git
+  source:
+    git:
+      ref:
+        branch: main
+      repository: https://github.com/akihikokuroda/examples
+      directory: ./charts
+    type: git
 EOF
 ```
 
@@ -397,7 +368,7 @@ Now the helm chart version is `hello-world-0.1.0`.  Change the git branch to `v0
 
 ```bash
 kubectl apply -f -<<EOF
-apiVersion: core.rukpak.io/v1alpha1
+apiVersion: core.rukpak.io/v1alpha2
 kind: BundleDeployment
 metadata:
   name: my-ahoy
@@ -427,19 +398,13 @@ spec:
       service:
         type: ClusterIP
         port: 80
-  template:
-    metadata:
-      labels:
-        app: my-ahoy
-    spec:
-      provisionerClassName: core-rukpak-io-helm
-      source:
-        git:
-          ref:
-            branch: v0.1.1
-          repository: https://github.com/akihikokuroda/examples
-          directory: ./charts
-        type: git
+  source:
+    git:
+      ref:
+        branch: v0.1.1
+      repository: https://github.com/akihikokuroda/examples
+      directory: ./charts
+    type: git
 EOF
 ```
 
diff --git a/docs/provisioners/plain.md b/docs/provisioners/plain.md
index 0fd5ed30..52e9e901 100644
--- a/docs/provisioners/plain.md
+++ b/docs/provisioners/plain.md
@@ -9,7 +9,7 @@ manifests in a given directory. For more information on the `plain+v0` format, s
 the [plain+v0 bundle spec](/docs/bundles/plain.md).
 
 The `plain` provisioner is able to unpack a given `plain+v0` bundle onto a cluster and then instantiate it, making the
-content of the bundle available in the cluster. It does so by reconciling `Bundle` and `BundleDeployment` types that have
+content of the bundle available in the cluster. It does so by reconciling `BundleDeployment` types that have
 the `spec.provisionerClassName` field set to `core-rukpak-io-plain`. This field must be set to the correct provisioner
 name in order for the `plain` provisioner to see and interact with the bundle.
 
@@ -36,45 +36,29 @@ The `plain` provisioner will unpack the provided Bundle onto the cluster, and ev
 available on the cluster.
 
 ```yaml
-apiVersion: core.rukpak.io/v1alpha1
+apiVersion: core.rukpak.io/v1alpha2
 kind: BundleDeployment
 metadata:
   name: my-bundle-deployment
 spec:
   provisionerClassName: core-rukpak-io-plain
-  template:
-    metadata:
-      labels:
-        app: my-bundle
-    spec:
-      source:
-        type: image
-        image:
-          ref: my-bundle@sha256:xyz123
-      provisionerClassName: core-rukpak-io-plain
-```
-
-> Note: the generated Bundle will contain the BundleDeployment's metadata.Name as a prefix, followed by
-> the hash of the provided template.
-
-First, the Bundle will be in the Pending stage as the provisioner sees it and begins unpacking the referenced content:
-
-```console
-$ kubectl get bundle my-bundle
-NAME           TYPE    PHASE      AGE
-my-bundle      image   Pending    3s
+  source:
+    type: image
+    image:
+      ref: my-bundle@sha256:xyz123
+  provisionerClassName: core-rukpak-io-plain
 ```
 
 Then eventually, as the bundle content is unpacked onto the cluster via the defined storage mechanism, the bundle status
 will be updated to Unpacked, indicating that all its contents have been stored on-cluster.
 
 ```console
-$ kubectl get bundle my-bundle
-NAME           TYPE    PHASE      AGE
-my-bundle      image   Unpacked   10s
+$ kubectl get bundledeployment my-bundle
+NAME                    TYPE    PHASE      AGE
+my-bundle-deployment    image   Unpacked   10s
 ```
 
-Now that the bundle has been unpacked, the provisioner is able to create the resources in the bundle on the cluster.
+Now that the bundledeployment has been unpacked, the provisioner is able to create the resources in the bundle on the cluster.
 These resources will be owned by the corresponding BundleDeployment. Creating the BundleDeployment on-cluster results in an
 InstallationSucceeded Phase if the application of resources to the cluster was successful.
 
@@ -84,8 +68,6 @@ NAME                   ACTIVE BUNDLE    INSTALL STATE           AGE
 my-bundle-deployment   my-bundle        InstallationSucceeded   11s
 ```
 
-> Note: Creation of more than one BundleDeployment from the same Bundle will likely result in an error.
-
 ## Running locally
 
 ### Setup
@@ -106,29 +88,23 @@ make run
 
 ### Installing the Combo Operator
 
-From there, create some Bundles and BundleDeployment types to see the provisioner in action. For an example bundle to
+From there, create some BundleDeployment types to see the provisioner in action. For an example bundle to
 use, the [combo operator](https://github.com/operator-framework/combo) is a good candidate.
 
 Create the combo BundleDeployment referencing the desired combo Bundle configuration:
 
 ```bash
 kubectl apply -f -<<EOF
-apiVersion: core.rukpak.io/v1alpha1
+apiVersion: core.rukpak.io/v1alpha2
 kind: BundleDeployment
 metadata:
   name: combo
 spec:
   provisionerClassName: core-rukpak-io-plain
-  template:
-    metadata:
-      labels:
-        app: combo
-    spec:
-      provisionerClassName: core-rukpak-io-plain
-      source:
-        image:
-          ref: quay.io/operator-framework/combo-bundle:v0.0.1
-        type: image
+  source:
+    image:
+      ref: quay.io/operator-framework/combo-bundle:v0.0.1
+    type: image
 EOF
 ```
 
@@ -141,20 +117,6 @@ EOF
 bundledeployment.core.rukpak.io/combo created
 ```
 
-Next, check the Bundle status via:
-
-```bash
-kubectl get bundle -l app=combo
-```
-
-Eventually the Bundle should show up as Unpacked:
-
-```console
-$ kubectl get bundle -l app=combo
-NAME               TYPE    PHASE      AGE
-combo-7cdc7d7d6d   image   Unpacked   10s
-```
-
 Check the BundleDeployment status to ensure that the installation was successful:
 
 ```bash
@@ -218,43 +180,27 @@ combo-operator   1/1     1            1           15s
 
 Let's say the combo operator released a new patch version, and we want to upgrade to that version.
 
-> Note: Upgrading a BundleDeployment involves updating the desired Bundle template being referenced.
-
 Update the existing `combo` BundleDeployment resource and update the container image being referenced:
 
 ```bash
 kubectl apply -f -<<EOF
-apiVersion: core.rukpak.io/v1alpha1
+apiVersion: core.rukpak.io/v1alpha2
 kind: BundleDeployment
 metadata:
   name: combo
 spec:
   provisionerClassName: core-rukpak-io-plain
-  template:
-    metadata:
-      labels:
-        app: combo
-    spec:
-      provisionerClassName: core-rukpak-io-plain
-      source:
-        image:
-          ref: quay.io/operator-framework/combo-bundle:v0.0.2
-        type: image
+  source:
+    image:
+      ref: quay.io/operator-framework/combo-bundle:v0.0.2
+    type: image
 EOF
 ```
 
-Once the newly generated Bundle is reporting an Unpacked status, the BundleDeployment `combo` resource should now
-point to the new Bundle (now named `combo-7ddfd9fcd5` instead of `combo-7cdc7d7d6d` previously). The combo-operator
-deployment in the combo namespace should also be healthy and contain a new container image:
-
-```console
-$ kubectl get bundles -l app=combo
-NAME               TYPE    PHASE      AGE
-combo-7ddfd9fcd5   image   Unpacked   10s
-
+```
 $ kubectl get bundledeployment combo
-NAME    ACTIVE BUNDLE      INSTALL STATE           AGE
-combo   combo-7ddfd9fcd5   InstallationSucceeded   10s
+NAME       INSTALL STATE           AGE
+combo      InstallationSucceeded   10s
 
 $ kubectl -n combo get deployment
 NAME             READY   UP-TO-DATE   AVAILABLE   AGE
diff --git a/docs/provisioners/registry.md b/docs/provisioners/registry.md
index 367d0f77..c5f1e4bf 100644
--- a/docs/provisioners/registry.md
+++ b/docs/provisioners/registry.md
@@ -9,15 +9,11 @@ manifests organized in the legacy Operator Lifecycle Manger (OLM) format. For mo
 the [OLM packaging doc](https://olm.operatorframework.io/docs/tasks/creating-operator-manifests/).
 
 The `registry` provisioner is able to convert a given `registry+v1` bundle onto a cluster in the `plain+v0` format. Instantiation of the
-bundle is then handled by the `plain` provisioner in order to make the content available in the cluster. It does so by reconciling `Bundle`
+bundle is then handled by the `plain` provisioner in order to make the content available in the cluster. It does so by reconciling `BundleDeployment`
 types that have the `spec.provisionerClassName` field set to `core-rukpak-io-registry`. This field must be set to the correct provisioner
-name in order for the `registry` provisioner to see and interact with the bundle. Creating a `BundleDeployment` of that `Bundle` would then
-require that you have set the `BundleDeployment` property `spec.provisionerClassName` field to `core-rukpak-io-plain`. For a concrete example
+name in order for the `registry` provisioner to see and interact with the bundle. For a concrete example
 of this in action, see the [use cases section](#use-cases)
 
-> Note: Not all `registry+v1` content is supported. This mainly applies to `registry+v1` bundles that enable `AllNamespaces` mode
-or include a webhook.
-
 ## Use cases
 
 ### Install and apply a specific version of a `registry+v1` bundle
@@ -29,49 +25,32 @@ or include a webhook.
 The `registry` provisioner can convert and make available a specific `registry+v1` bundle as a `plain+v0` in the cluster.
 
 Simply create a `BundleDeployment` resource that contains the desired specification of a Bundle resource.
-The `registry` provisioner will unpack the provided Bundle onto the cluster, and the `plain` provisioner
+The `registry` provisioner will unpack the provided BundleDeployment onto the cluster, and the `plain` provisioner
 will eventually make the content available on the cluster.
 
 ```yaml
-apiVersion: core.rukpak.io/v1alpha1
+apiVersion: core.rukpak.io/v1alpha2
 kind: BundleDeployment
 metadata:
   name: my-bundle-deployment
 spec:
-  provisionerClassName: core-rukpak-io-plain
-  template:
-    metadata:
-      labels:
-        app: my-bundle
-    spec:
-      source:
-        type: image
-        image:
-          ref: my-bundle@sha256:xyz123
-      provisionerClassName: core-rukpak-io-registry
-```
-
-> Note: The generated Bundle will contain the BundleDeployment's metadata.Name as a prefix, followed by
-> the hash of the provided template.
-
-First, the Bundle will be in the Pending stage as the provisioner sees it and begins unpacking the referenced content:
-
-```console
-$ kubectl get bundle my-bundle
-NAME           TYPE    PHASE      AGE
-my-bundle      image   Pending    3s
+  source:
+    type: image
+    image:
+      ref: my-bundle@sha256:xyz123
+  provisionerClassName: core-rukpak-io-registry
 ```
 
 Then eventually, as the bundle content is unpacked onto the cluster via the defined storage mechanism, the bundle status
 will be updated to Unpacked, indicating that all its contents have been stored on-cluster.
 
 ```console
-$ kubectl get bundle my-bundle
-NAME           TYPE    PHASE      AGE
-my-bundle      image   Unpacked   10s
+$ kubectl get bundledeployment my-bundle-deployment
+NAME                      TYPE    PHASE      AGE
+my-bundle-deployment      image   Unpacked   10s
 ```
 
-Now that the bundle has been unpacked, the provisioner is able to create the resources in the bundle on the cluster.
+Now that the bundledeployment has been unpacked, the provisioner is able to create the resources in the bundle on the cluster.
 These resources will be owned by the corresponding BundleDeployment. Creating the BundleDeployment on-cluster results in an
 InstallationSucceeded Phase if the application of resources to the cluster was successful.
 
@@ -81,8 +60,6 @@ NAME                   ACTIVE BUNDLE      INSTALL STATE           AGE
 my-bundle-deployment   my-bundle          InstallationSucceeded   11s
 ```
 
-> Note: Creation of more than one BundleDeployment from the same Bundle will likely result in an error.
-
 ## Running locally
 
 ### Setup
@@ -110,22 +87,16 @@ Create the `prometheus` BundleDeployment referencing the desired `prometheus` Bu
 
 ```bash
 kubectl apply -f -<<EOF
-apiVersion: core.rukpak.io/v1alpha1
+apiVersion: core.rukpak.io/v1alpha2
 kind: BundleDeployment
 metadata:
   name: prometheus
 spec:
-  provisionerClassName: core-rukpak-io-plain
-  template:
-    metadata:
-      labels:
-        app: prometheus
-    spec:
-      provisionerClassName: core-rukpak-io-registry
-      source:
-        type: image
-        image:
-          ref: quay.io/operatorhubio/prometheus:v0.47.0--20220325T220130
+  provisionerClassName: core-rukpak-io-registry
+  source:
+    type: image
+    image:
+      ref: quay.io/operatorhubio/prometheus:v0.47.0--20220325T220130
 EOF
 ```
 
@@ -138,20 +109,6 @@ EOF
 bundledeployment.core.rukpak.io/prometheus created
 ```
 
-Next, check the Bundle status via:
-
-```bash
-kubectl get bundle -l app=prometheus
-```
-
-Eventually the Bundle should show up as Unpacked:
-
-```console
-$ kubectl get bundle -l app=prometheus
-NAME                    TYPE    PHASE      AGE
-prometheus-5699cbff6   image   Unpacked   14s
-```
-
 Check the BundleDeployment status to ensure that the installation was successful:
 
 ```bash
@@ -162,8 +119,8 @@ A successful installation will show InstallationSucceeded as the `INSTALL STATE`
 
 ```console
 $ kubectl get bundledeployment prometheus
-NAME         ACTIVE BUNDLE           INSTALL STATE           AGE
-prometheus   prometheus-5699cbff6    InstallationSucceeded   10s
+NAME             INSTALL STATE           AGE
+prometheus       InstallationSucceeded   10s
 ```
 
 From there, check out the prometheus operator BundleDeployment and ensure that the operator is present on the cluster:
@@ -212,43 +169,30 @@ prometheus-operator   1/1     1            1           15s
 
 Let's say the `prometheus` operator released a newer release and we want to upgrade to that version.
 
-> Note: Upgrading a BundleDeployment involves updating the desired Bundle template being referenced.
-
 Update the existing `prometheus` BundleDeployment resource and update the container image being referenced:
 
 ```bash
 kubectl apply -f -<<EOF
-apiVersion: core.rukpak.io/v1alpha1
+apiVersion: core.rukpak.io/v1alpha2
 kind: BundleDeployment
 metadata:
   name: prometheus
 spec:
-  provisionerClassName: core-rukpak-io-plain
-  template:
-    metadata:
-      labels:
-        app: prometheus
-    spec:
-      provisionerClassName: core-rukpak-io-registry
-      source:
-        type: image
-        image:
-          ref: quay.io/operatorhubio/prometheus:v0.47.0--20220413T184225
+  provisionerClassName: core-rukpak-io-registry
+  source:
+    type: image
+    image:
+      ref: quay.io/operatorhubio/prometheus:v0.47.0--20220413T184225
 EOF
 ```
 
-Once the newly generated Bundle is reporting an Unpacked status, the BundleDeployment `prometheus` resource should now
-point to the new Bundle (now named `prometheus-7f4f468d94` instead of `prometheus-5699cbff6` previously). The prometheus-operator
+The prometheus-operator
 BundleDeployment in the prometheus-system namespace should also be healthy and contain a new container image:
 
-```console
-$ kubectl get bundles -l app=prometheus
-NAME                    TYPE    PHASE      AGE
-prometheus-7f4f468d94   image   Unpacked   2m15s
-
+```
 $ kubectl get bundledeployment prometheus
-NAME         ACTIVE BUNDLE           INSTALL STATE           AGE
-prometheus   prometheus-7f4f468d94   InstallationSucceeded   2m47s
+NAME            INSTALL STATE           AGE
+prometheus      InstallationSucceeded   2m47s
 
 $ kubectl -n prometheus-system get bundledeployment
 NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
@@ -260,7 +204,7 @@ prometheus-operator   1/1     1            1           3m6s
 To clean up from the installation, simply remove the BundleDeployment from the cluster. This will remove all references
 resources including the BundleDeployment, RBAC, and the operator namespace.
 
-> Note: There's no need to manually clean up the Bundles that were generated from a BundleDeployment resource. The plain provisioner places owner references on any Bundle that's generated from an individual BundleDeployment resource.
+> Note: There's no need to manually clean up the resources that were generated from a BundleDeployment. The provisioner places owner references on any Bundle that's generated from an individual BundleDeployment resource.
 
 ```bash
 # Delete the prometheus BundleDeployment
diff --git a/internal/controllers/bundledeployment/bundledeployment.go b/internal/controllers/bundledeployment/bundledeployment.go
index 99668466..e3c9ab12 100644
--- a/internal/controllers/bundledeployment/bundledeployment.go
+++ b/internal/controllers/bundledeployment/bundledeployment.go
@@ -287,7 +287,7 @@ func (c *controller) reconcile(ctx context.Context, bd *rukpakv1alpha2.BundleDep
 	bundleFS, err := c.storage.Load(ctx, bd)
 	if err != nil {
 		meta.SetStatusCondition(&bd.Status.Conditions, metav1.Condition{
-			Type:    rukpakv1alpha2.TypeHasValidBundle,
+			Type:    rukpakv1alpha2.TypeInstalled,
 			Status:  metav1.ConditionFalse,
 			Reason:  rukpakv1alpha2.ReasonBundleLoadFailed,
 			Message: err.Error(),