Update ADR025-use-aasm-to-manage-form-state.md

ADR/ADR025-use-aasm-to-manage-form-state.md

@@ -10,11 +10,13 @@ Date: YYYY-MM-DD
 
 ## Context
 
+### Before
+
 Initially, there only three "states" that a form could be in, "Draft", "Live" and a combination of the two "Live with draft". These states were not hardcoded and we inferred by a combination of attribute  
 
-Draft - All "Form" records are draft
-Live - A "Form" record has a snapshot of the form and associated children records stored in `made_live_forms` table. A form can have `made_live_form` records but we only ever return the latest live form.
-Live with draft - This is calculated by checking the forms `updated_at` timestamp is after `live_at` which means there has been some changes to the form since it went live.
+1. Draft - All "Form" records are draft
+2. Live - A "Form" record has a snapshot of the form and associated children records stored in `made_live_forms` table. A form can have `made_live_form` records but we only ever return the latest live form.
+3. Live with draft - This is calculated by checking the forms `updated_at` timestamp is after `live_at` which means there has been some changes to the form since it went live. A form coudl return back to Live when the users makes the changes live
 
 ```mermaid
 stateDiagram
@@ -25,6 +27,38 @@ stateDiagram
 
 ```
 
+#### Pros
+- easy at first to implement
+- no state to track in the database
+
+#### Cons
+- not scalable to include new states in the future
+- developers have to remember when doing data migrations/editting to try not to trigger the `updated_at` timestamp to be updated
+- difficult to "rollback" a state
+
+We received a tech support request from users after a small change to how "What happens next" column which triggered `updated_at` to be updated to a time after the form went live. The users asked why their forms were now being shown as having a draft version when nothing had changed.
+It was time for us to look for a better solution.
+
+We needed something that
+- manage & track the state of each form
+- allowed us to use guards to ensure that forms coudl not be left in an invalid state (example live forms that didn't have `made_live_forms` records
+
+A [spike was completed](https://github.com/alphagov/forms-api/pull/414) to investigate how easy it would be to implement a state machine gem such as [AASM](https://github.com/aasm/aasm). This proved to be simple enough to do and gave us the benefits of not using
+
+### Current
+
+```mermaid
+---
+ title: Form states and events called to transition to state
+---
+stateDiagram-v2
+    Draft --> Live : make_live!
+    Draft --> Deleted : delete_form!
+    live_with_draft: Live with draft
+    Live --> live_with_draft : create_draft_from_live_form!
+    live_with_draft --> Live : make_live!
+
+```
 
 ## Decision