diff --git a/scenarios/adoption/uni06zeta.yml b/scenarios/adoption/uni06zeta.yml
new file mode 100644
index 0000000000..36f6ce673b
--- /dev/null
+++ b/scenarios/adoption/uni06zeta.yml
@@ -0,0 +1,102 @@
+---
+# By default, the OSP VMs will run using a default image.
+# In upstream, it's usually latest centos-stream-9
+# For downstream, it's usually rhel-9.4 image, depending on
+# the job configuration.
+#
+# Since OSP infra must use an older RHEL image, you can override it
+# by setting "osp_base_img_url" to point to the downstream QCOW2 image,
+# and "osp_base_img_sha256" holding the SHA256SUM of the image.
+#
+# We can't automatically discover the image, the role/module sets the
+# value globally, and it would clash with the needs for RHOSO images.
+
+# Use anchor to avoid repetitions. This block is common to all of OSP nodes.
+_osp_img_data: &osp_base_conf
+  image_local_dir: "{{ cifmw_basedir }}/images/"
+  disk_file_name: osp-base.qcow2
+  image_url: "{{ osp_base_img_url | default(cifmw_discovered_image_url) }}"
+  sha256_image_name: >-
+    {{ osp_base_img_sha256 | default(cifmw_discovered_hash) }}
+
+
+libvirt_manager_patch_layout:
+  vms:
+    # Let's remove the default computes, since we want to adopt the
+    # OSP ones
+    compute:
+      amount: 0
+    osp-undercloud:
+      <<: *osp_base_conf
+      amount: 1
+      memory: 16
+      cpus: 8
+      disksize: 80
+      nets:
+        - ocpbm
+        - osp_trunk
+    osp-controller:
+      <<: *osp_base_conf
+      amount: 3
+      memory: 16
+      cpus: 8
+      disksize: 80
+      nets:
+        - ocpbm
+        - osp_trunk
+    osp-compute:
+      <<: *osp_base_conf
+      amount: 2
+      memory: 4
+      cpus: 4
+      disksize: 20
+      extra_disks_num: 2
+      extra_disks_size: 30G
+      nets:
+        - ocpbm
+        - osp_trunk
+
+networking_mapper_definition_patch:
+  networks:
+    external:
+      network: "192.168.32.0/20"
+      vlan: 99
+      mtu: 1496
+  group-templates:
+    computes:
+      network-template:
+        # ensure this range does not collide with osp-computes one, even if we
+        # don't create any vms for the compute group (the computes for
+        # greenfield jobs) we need to make sure their ip ranges do not overlap
+        range:
+          start: 200
+          length: 1
+    osp-controllers:
+      network-template:
+        range:
+          start: 103
+          length: 3
+      networks: &osp_nets
+        ctlplane: {}
+        external:
+          trunk-parent: ctlplane
+        internalapi:
+          trunk-parent: ctlplane
+        tenant:
+          trunk-parent: ctlplane
+        storage:
+          trunk-parent: ctlplane
+        storagemgmt:
+          trunk-parent: ctlplane
+    osp-computes:
+      network-template:
+        range:
+          start: 106
+          length: 2
+      networks: *osp_nets
+    osp-underclouds:
+      network-template:
+        range:
+          start: 100
+          length: 1
+      networks: *osp_nets