diff --git a/specs/wallaby/reset-state-robustification.rst b/specs/wallaby/reset-state-robustification.rst
new file mode 100644
index 00000000..5aa42bee
--- /dev/null
+++ b/specs/wallaby/reset-state-robustification.rst
@@ -0,0 +1,158 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+===========================
+Reset State Robustification
+===========================
+
+https://blueprints.launchpad.net/cinder/+spec/reset-state-robustification
+
+Problem description
+===================
+
+I have seen a number of users get volumes into "invalid" states by
+not understanding how resetting the state of a volume interacts
+with resetting the state of attachments.
+
+For example, on a volume with an attachment, run
+"cinder reset-state --state available <vol>"
+
+What now?
+
+Use Cases
+=========
+
+Help prevent users who aren't Cinder experts from shooting themselves
+in the foot with reset-state.
+
+Proposed change
+===============
+
+If a user requests to reset the state of a volume to something that
+Cinder knows is not a valid state of the universe, reject the request
+with a reason.
+
+If volume1 has an attachment active.
+$ cinder reset-state --state available volume1
+ERROR: Cannot reset-state to available because attachments still exist.
+
+$ cinder reset-state --state available volume1 --attach-status detached
+(command succeeds)
+
+Cases to block:
+   1. volume reset to available w/ attachments
+   2. snapshot reset to in-use with volume in available
+
+
+Sometimes a knowledgeable operator may need to reset the state anyway
+and then manually make the current state valid. cinder-manage is the
+place where forcing a change will be allowed instead of '--force'
+flag in the API.
+
+Alternatives
+------------
+
+- Hope users don't do these things.
+- Handle the "reset to available while attached case" by forcefully
+  detaching the volumes instead of rejecting the request.
+
+Data model impact
+-----------------
+
+None
+
+REST API impact
+---------------
+
+os-reset-status actions on volumes, snaps, backups, groups,
+will now return a 400 in some cases where they would previously
+succeeded.  This does not require a microversion bump.
+
+Security impact
+---------------
+
+None
+
+Active/Active HA impact
+-----------------------
+
+These checks in reset-state could concievably race against updates in
+a cluster.  Will determine what that means when we get further into
+implementation.
+
+
+Notifications impact
+--------------------
+
+None
+
+Other end user impact
+---------------------
+
+None
+
+Performance Impact
+------------------
+
+None
+
+Other deployer impact
+---------------------
+
+Improves safety for deployers trying to clean up from issues in
+their cloud.
+
+Developer impact
+----------------
+
+None
+
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+  TusharTgite
+
+Other contributors:
+  eharney
+
+Work Items
+----------
+
+* Implement a check for the
+  reset-state to available while attached case
+* Add code to cinder-manage to handle the case
+  where an operator needs to override the API
+  and reset the state anyway.
+* Research other sensible cases we could prevent for
+  volumes, snaps, groups, etc.
+* Tempest test for a couple of the big cases
+
+
+Dependencies
+============
+
+None
+
+Testing
+=======
+
+* New tempest tests
+
+
+Documentation Impact
+====================
+
+* Should document common cases where this fails.
+
+References
+==========
+
+* Original proposal: https://review.opendev.org/c/openstack/cinder-specs/+/682456