diff --git a/enhancements/builds/volume-secrets.md b/enhancements/builds/volume-secrets.md
index 5378ce8d9ae..d9d5e4cc1e6 100644
--- a/enhancements/builds/volume-secrets.md
+++ b/enhancements/builds/volume-secrets.md
@@ -40,7 +40,7 @@ There are a few undesirable aspects to this:
 selected.
 2) Requires extra work by the user in the Dockerfile, so each Dockerfile must be customized
 
-This enhancement proposes to use buildah's capability to mount a volume at build time.  The content mounted into the build pod would be then mounted into the container processing the Dockerfile, making that content available within the container so Dockerfile commands could reference it.  No explicit `ADD` would be required, and since mounted content is not committed to the resulting image, no `RUN rm` equivalent is required to clean up the injected content.
+This enhancement proposes to introduce an option to use buildah's capability to mount a volume at build time.  The content mounted into the build pod would be then mounted into the container processing the Dockerfile, making that content available within the container so Dockerfile commands could reference it.  No explicit `ADD` would be required, and since mounted content is not committed to the resulting image, no `RUN rm` equivalent is required to clean up the injected content.
 
 
 ## Motivation
@@ -50,10 +50,11 @@ This enhancement proposes to use buildah's capability to mount a volume at build
 * Simplify how users consume secret + configmap content in builds
 * Increase the security of protected content being injected to images
 * Simplify use cases like mounting subscription entitlement credentials into a build so subscription content can be pulled down during a build while not including the credentials in the resulting image.
+* Eventually extend this api to allow the mounting of traditional volumes (such as those backed by persistent storage)
 
 ### Non-Goals
 
-* This enhancement is not related to the frequently requested "build volumes" feature which would make it possible to mount a volume during a build and read/write content on that volume during the build such as to cache dependencies.
+* This enhancement should not result in a change of behavior for users of the existing secret/configmap injection api.
 
 
 ## Proposal
@@ -62,13 +63,15 @@ This enhancement proposes to use buildah's capability to mount a volume at build
 
 The enabled use cases are essentially identical to what can be done with the configmap/secret input api in builds today, but with a better user experience and security as discussed above.  It does not enable a new use case that is not already possible today, except that layer squashing will not be required.
 
+Future extensions to this enhancement could enable the use case of providing build input content from a persistent volume and allowing the build to store/cache content for future builds on such a volume.  Those will be discussed in the future enhancement at that time.
+
 ### Implementation Details/Notes/Constraints [optional]
 
-We will need to introduce a new field in the build api which allows the user to indicate that they want to use this mechanism to inject their configmap/secret content, rather than the existing mechanism.
+We will need to introduce a new mechanism in the build api which allows the user to indicate that they want to inject "volume" content into the build.  Initially the only allowed volume types will be configmaps and secrets.  The api will otherwise be similar to the existing secret/configmap injection api in which users identify the configmap/secret and the target path for injection.  For now there is no plan to expose the entirety of the kubernetes volume mount api which allows for things like mounting specific keys or denoting them as required/optional.
 
-The build pod will continue to mount the content as it already does, however the logic that generates the dockerfile(for s2i) and invokes buildah(for both dockerfile + s2i builds) will need to change to not augment the dockerfile, but instead to pass volume mount paths to buildah.  It will mount the content from the path it was mounted into the build pod, and mount it to the destination path provided by the user (the same path where the logic previously injected it via the dockerfile `ADD` command).
+The build controller will construct the build-pod to mount the requested configmaps+secrets, similar to how it handles the existing injection requests.  The significant new behavior will be in the logic that generates the dockerfile(for s2i) and invokes buildah(for both dockerfile + s2i builds) which will need to change to not augment the dockerfile, but instead to pass volume mount paths to buildah.  It will mount the content from the path it was mounted into the build pod, and mount it to the destination path provided by the user (the same path where the logic previously injected it via the dockerfile `ADD` command).
 
-proposed api:
+proposed api (the existing secrets+configmaps apis are shown only for comparison purposes, they are not changing):
 
 ```
 apiVersion: v1
@@ -80,16 +83,23 @@ items:
     namespace: p1
   spec:
     source:
+      volumes:
+      - type: Secret
+        reference:
+          name: mySecretName
+        destinationDir: /etc/subscriptions
+      - type: ConfigMap
+        reference: 
+          name: myConfigMapName
+        destinationDir: /tmp/config
       secrets:
       - secret: 
-          name: mySecret
-        destinationDir: /etc/subscriptions
-        useVolume: true
+          name: myOtherSecret
+        destinationDir: /tmp/creds
       - configMaps:
         configMap:
-          name: myConfigMap
+          name: myOtherConfigMap
         destinationDir: /tmp/config
-        useVolume: false # default
 ```
 
 ### Risks and Mitigations
@@ -126,4 +136,5 @@ Additional user complexity in choosing when to enable this behavior.  It is also
 
 ## Alternatives
 
-N/A
+Updating the existing injection apis to have a "asVolume" field was considered as it would be a simpler implementation (more code reuse) but it was rejected as there is a long term goal to allow builds to mount traditional volumes as well.  The existing injection api can't easily be extended to support such a thing, so the design proposed in this enhancement is a better stepping stone to that goal.
+