diff --git a/RFC/variable-replacement-matrix.md b/RFC/variable-replacement-matrix.md
new file mode 100644
index 000000000..fe9ab7b88
--- /dev/null
+++ b/RFC/variable-replacement-matrix.md
@@ -0,0 +1,127 @@
+Given the following bundle.yaml and tests.yaml example, we could use the variables defined in the tests.yaml to build our test matrix, reducing the repetition in our charms.
+
+bundle.yaml:
+```yaml
+series: *series
+applications:
+  ceph-osd:
+    charm: ceph-osd
+    options:
+      source: *source
+  ceph-mon:
+    charm: cs:ceph-mon
+    options:
+      source: *source
+relations:
+  - - ceph-mon
+    - ceph-osd
+```
+tests.yaml:
+```yaml
+charm_name: ceph-osd
+base_bundle:
+  - bundle
+# gate_bundles:
+#   --snip--
+# smoke_bundles:
+#   --snip--
+# dev_bundles:
+#   --snip--
+configure: []
+tests:
+  - zaza.openstack.charm_tests.ceph.tests.CephTest
+
+# The below section is entirely optional and will be used as a transform
+# on the {gate,smoke,dev}_bundles sections at the beginning. The matrix below
+# would transform into, basically: 
+# gate_bundles:
+#   - bionic-stein
+#   - bionic-rocky
+#   - bionic-queens
+#   - xenial-queens
+#   - xenial-pike
+#   - xenial-ocata
+#   - xenial-mitaka
+#   - trusty-mitaka
+# smoke_bundles:
+#   - bionic-queens
+# dev_bundles:
+#   - cosmic-rocky
+#   - disco-stein
+matrix:
+  series:
+    - disco:
+        -  source|openstack-origin:
+            - stein:
+                - dev: true
+                - gate: false
+    - cosmic:
+        -  source|openstack-origin:
+            - rocky:
+                - dev: true
+                - gate: false
+    - bionic:
+        -  source|openstack-origin:
+            - stein
+            - rocky
+            - queens:
+              - smoke: true
+    - xenial:
+        -  source|openstack-origin:
+            - queens
+            - pike
+            - ocata
+            - mitaka
+    - trusty:
+        -  source|openstack-origin:
+            - mitaka
+```
+
+An alternate method for mapping in the `matrix` section to the `*-bundle` section could be:
+```yaml
+base-bundle:
+  bundle
+# The mode_map key would be used as a replace map to identify
+# the pattern to transform the matrix variables into the bundle
+# mappings for dev/smoke/gate
+mode_map: "*series-*openstack-origin"
+gate_bundles:
+  - bionic-stein
+  - bionic-rocky
+  - bionic-queens
+smoke_bundles:
+  - bionic-queens
+dev_bundles:
+  - cosmic-rocky
+  - disco-stein
+matrix:
+  series:
+    - disco:
+        -  source|openstack-origin:
+            - stein
+    - cosmic:
+        -  source|openstack-origin:
+            - rocky
+    - bionic:
+        -  source|openstack-origin:
+            - stein
+            - rocky
+            - queens
+```
+
+In addition to mapping the bundles to be run, the above would additionally add the following section to the bundle.yaml (`bundle.yaml` in the above config):
+
+```yaml
+variables:
+  series: &series disco
+  source: &source stein
+  openstack-origin: &openstack-origin stein
+```
+
+Where the [disco / stein] combination is an entry generated by the `matrix` values in tests.yaml.
+
+While this method would increase the length of the tests.yaml (potentially considerably), It would almost entirely remove the repetition mapping each U-OS combination to a new bundle.
+
+It is also possible that the `base-bundle` section could be extended to allow for mapping different base bundles depending on the variables in the matrix section. I think that this would be valuable when considering bundles that change deployed applications per release, or for restricting some applications to a subset of releases.
+
+After combining these variables in their "base" bundle, we could render the base bundle in addition to overlays as the primary bundle to deploy.
\ No newline at end of file