diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.0.5.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.0.5.page.md
index 0e399079..d42ff843 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.0.5.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.0.5.page.md
@@ -20,6 +20,4 @@ topic: TRN-Core-1.0.5
-
-
-### Previous Releases
\ No newline at end of file
+
\ No newline at end of file
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/toc.yaml b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/toc.yaml
index 0acf544b..b5da70f7 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/toc.yaml
+++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/toc.yaml
@@ -2,32 +2,30 @@
filename: Index.page.md
- name: 1.2.2-alpha
filename: 1.2.2-alpha.page.md
-- name: 1.2.1-alpha
- filename: 1.2.1-alpha.page.md
- name: 1.1.6
filename: 1.1.6.page.md
-- name: 1.1.5
- filename: 1.1.5.page.md
- name: 1.0.6
filename: 1.0.6.page.md
-- name: 1.0.5
- filename: 1.0.5.page.md
-- name: 1.1.4
- filename: 1.1.4.page.md
-- name: 1.0.4
- filename: 1.0.4.page.md
+- name: 1.2.1-alpha
+ filename: 1.2.1-alpha.page.md
- name: 1.2.0-alpha
filename: 1.2.0-alpha.page.md
+- name: 1.1.5
+ filename: 1.1.5.page.md
+- name: 1.1.4
+ filename: 1.1.4.page.md
- name: 1.1.3
filename: 1.1.3.page.md
-- name: 1.0.3
- filename: 1.0.3.page.md
- name: 1.1.2
filename: 1.1.2.page.md
- name: 1.1.1
filename: 1.1.1.page.md
- name: 1.1.0
filename: 1.1.0.page.md
+- name: 1.0.5
+ filename: 1.0.5.page.md
+- name: 1.0.4
+ filename: 1.0.4.page.md
- name: 1.0.3
filename: 1.0.3.page.md
- name: 1.0.0
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Requestors.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Requestors.page.md
index 8c3c8228..d3ae76f8 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Requestors.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Requestors.page.md
@@ -10,7 +10,7 @@ The below details the specific guidance around the use of resources required to
_Note that Requesters will also have to build the capability to receive and process the Validation Response payloads._
For Example Validation Request bundles see:
-* [Validation Request - 999 to CAS New](https://simplifier.net/nhsbookingandreferrals/86e3371d-1c15-4862-9552-d9560f8292db)
+* [Validation Request - 999 to CAS New](https://simplifier.net/nhsbookingandreferrals/86e3371d-1c15-4862-9552-d9560f8292ba-duplicate-8)
* [Validation Request - 999 to CAS AMPDS](https://simplifier.net/nhsbookingandreferrals/86e3371d-1c15-4862-9552-d9560f8292ba)
* [Validation Request - 999 to CAS Update to lower priority](https://simplifier.net/nhsbookingandreferrals/baebe535-9d6c-4b0f-8bc6-8f4b157d44ac)
* For additional example bundles please check [BaRS Example Bundles](https://simplifier.net/nhsbookingandreferrals/~resources?category=Example&exampletype=Bundle&sortBy=LastUpdateDate_desc)
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.6/Standard-Pattern-Composite-Messages/Use-Case-Categories.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.6/Standard-Pattern-Composite-Messages/Use-Case-Categories.page.md
index abbc1d6c..f12a8624 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.6/Standard-Pattern-Composite-Messages/Use-Case-Categories.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.6/Standard-Pattern-Composite-Messages/Use-Case-Categories.page.md
@@ -20,7 +20,8 @@ The use case category is used in the initial content negotiation phase:
When a Sender makes a request for MessageDefinitions, the MessageDefinitions returned by the Receiver will contain a use case category code (from the use case categories code system) under Message.Definition.useContext.code. The Sender **must** read this field to verify the Receiver supports the use case workflow they require. The use case category code will also be included in:
* the Sender's service request under ServiceRequest.category
* the Sender’s booking request under Appointment.ServiceCategory
- If this is not a use case supported by the Receiver, they will respond with an error (Operation Outcome).
+
+If this is not a use case supported by the Receiver, they will respond with an error (Operation Outcome).
The sequence of events occurs as follows:
* the Sender requests the MessageDefinitions
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Standard-Pattern-Composite-Messages/Use-Case-Categories.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Standard-Pattern-Composite-Messages/Use-Case-Categories.page.md
index bf5a53cb..939affc5 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Standard-Pattern-Composite-Messages/Use-Case-Categories.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Standard-Pattern-Composite-Messages/Use-Case-Categories.page.md
@@ -20,7 +20,8 @@ The use case category is used in the initial content negotiation phase:
When a Sender makes a request for MessageDefinitions, the MessageDefinitions returned by the Receiver will contain a use case category code (from the use case categories code system) under Message.Definition.useContext.code. The Sender **must** read this field to verify the Receiver supports the use case workflow they require. The use case category code will also be included in:
* the Sender's service request under ServiceRequest.category
* the Sender’s booking request under Appointment.ServiceCategory
- If this is not a use case supported by the Receiver, they will respond with an error (Operation Outcome).
+
+If this is not a use case supported by the Receiver, they will respond with an error (Operation Outcome).
The sequence of events occurs as follows:
* the Sender requests the MessageDefinitions
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Standard-Pattern-Composite-Messages/Use-Case-Categories.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Standard-Pattern-Composite-Messages/Use-Case-Categories.page.md
index 07ab4a60..428580cc 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Standard-Pattern-Composite-Messages/Use-Case-Categories.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Standard-Pattern-Composite-Messages/Use-Case-Categories.page.md
@@ -20,7 +20,8 @@ The use case category is used in the initial content negotiation phase:
When a Sender makes a request for MessageDefinitions, the MessageDefinitions returned by the Receiver will contain a use case category code (from the use case categories code system) under Message.Definition.useContext.code. The Sender **must** read this field to verify the Receiver supports the use case workflow they require. The use case category code will also be included in:
* the Sender's service request under ServiceRequest.category
* the Sender’s booking request under Appointment.ServiceCategory
- If this is not a use case supported by the Receiver, they will respond with an error (Operation Outcome).
+
+If this is not a use case supported by the Receiver, they will respond with an error (Operation Outcome).
The sequence of events occurs as follows:
* the Sender requests the MessageDefinitions