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..f491de7d 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,44 +55,23 @@ 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
-NAME                 TYPE   PHASE      AGE
-my-ahoy-5764594dc8   http   Unpacked   33s
-```
-
-Now that the bundle 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.
+As the bundle content is retrieved and stored onto the cluster via the defined storage mechanism, the bundledeployment's `Install State` moves from `UnpackSuccessful` to `InstallationSucceeded`. 
+The install succeeded state indicates that the provisioner has created the resources in the bundle on the cluster. These resources will be owned by the corresponding BundleDeployment.
 
 ```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
 ```
 
-> Note: Creation of more than one BundleDeployment from the same Bundle will likely result in an error.
-
 ## Quick Start
 
 ### Setup
@@ -127,33 +106,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,21 +139,15 @@ 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:
-
-```console
-$ kubectl get bundle -l app=my-ahoy
-NAME                 TYPE   PHASE      AGE
-my-ahoy-5764594dc8   git    Unpacked   33s
-```
+Eventually the BundleDeployment's `Unpacked` status condition should be set to true. Followed by which, check the BundleDeployment's status to ensure that the installation was successful:
 
-Check the BundleDeployment status to ensure that the installation was successful:
+Eventually the BundleDeployment should show up as Unpacked:
 
 ```bash
 kubectl get bundledeployment my-ahoy
@@ -190,8 +157,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 +206,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 +236,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 +274,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 +304,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 +352,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 +382,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..bcf1d702 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,56 +36,28 @@ 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
-```
-
-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
+  source:
+    type: image
+    image:
+      ref: my-bundle@sha256:xyz123
+  provisionerClassName: core-rukpak-io-plain
 ```
 
-Now that the bundle 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.
+As the bundle content is retrieved and stored onto the cluster via the defined storage mechanism, the bundledeployment's `Install State` moves from `UnpackSuccessful` to `InstallationSucceeded`. 
+The install succeeded state indicates that the provisioner has created the resources in the bundle on the cluster. These resources will be owned by the corresponding BundleDeployment.
 
 ```console
 $ kubectl get bundledeployment my-bundle-deployment
-NAME                   ACTIVE BUNDLE    INSTALL STATE           AGE
-my-bundle-deployment   my-bundle        InstallationSucceeded   11s
+NAME                       INSTALL STATE           AGE
+my-bundle-deployment       InstallationSucceeded   11s
 ```
 
-> Note: Creation of more than one BundleDeployment from the same Bundle will likely result in an error.
-
 ## Running locally
 
 ### Setup
@@ -106,29 +78,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 +107,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
@@ -165,8 +117,8 @@ A successful installation will show InstallationSucceeded as the `INSTALL STATE`
 
 ```console
 $ kubectl get bundledeployment combo
-NAME    ACTIVE BUNDLE      INSTALL STATE           AGE
-combo   combo-7cdc7d7d6d   InstallationSucceeded   10s
+NAME      INSTALL STATE           AGE
+combo     InstallationSucceeded   10s
 ```
 
 From there, check out the combo operator deployment and ensure that the operator is present on the cluster:
@@ -218,43 +170,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..4b560ba9 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,60 +25,31 @@ 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
-```
-
-Now that the bundle 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.
+As the bundle content is retrieved and stored onto the cluster via the defined storage mechanism, the bundledeployment's `Install State` moves from `UnpackSuccessful` to `InstallationSucceeded`. 
+The install succeeded state indicates that the provisioner has created the resources in the bundle on the cluster. These resources will be owned by the corresponding BundleDeployment.
 
 ```console
 $ kubectl get bundledeployment my-bundle-deployment
-NAME                   ACTIVE BUNDLE      INSTALL STATE           AGE
-my-bundle-deployment   my-bundle          InstallationSucceeded   11s
+NAME                          INSTALL STATE           AGE
+my-bundle-deployment          InstallationSucceeded   11s
 ```
 
-> Note: Creation of more than one BundleDeployment from the same Bundle will likely result in an error.
-
 ## Running locally
 
 ### Setup
@@ -110,22 +77,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 +99,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 +109,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 +159,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 +194,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(),