Remove support for the v1 launch pattern

.github/CODEOWNERS

@@ -1,11 +1,9 @@
 docs/jwt_profile.md @ONSdigital/eq-runner @ONSdigital/sdc-rmras @ONSdigital/census-response-management
 
 docs/respondent_management_to_electronic_questionnaire_runner.md @ONSdigital/eq-runner @ONSdigital/sdc-rmras @ONSdigital/census-response-management
-docs/rm_to_eq_runner_payload_v1.md @ONSdigital/eq-runner @ONSdigital/sdc-rmras @ONSdigital/census-response-management
 docs/rm_to_eq_runner_payload_v2.md @ONSdigital/eq-runner @ONSdigital/sdc-rmras @ONSdigital/census-response-management
 
 docs/electronic_questionnaire_runner_to_downstream.md @ONSdigital/eq-runner @ONSdigital/sdx
-docs/eq_runner_to_downstream_payload_v1.md @ONSdigital/eq-runner @ONSdigital/sdx
 docs/eq_runner_to_downstream_payload_v2.md @ONSdigital/eq-runner @ONSdigital/sdx
 docs/eq_runner_data_versions.md @ONSdigital/eq-runner @ONSdigital/sdx
 
@@ -14,8 +12,6 @@ docs/survey_data_exchange_to_respondent_account_services.md @ONSdigital/sdx @ONS
 examples/rm_to_eq_runner/* @ONSdigital/eq-runner @ONSdigital/sdc-rmras @ONSdigital/census-response-management
 examples/eq_runner_to_downstream/* @ONSdigital/eq-runner @ONSdigital/sdx
 
-schemas/launch_v1.json @ONSdigital/eq-runner @ONSdigital/sdc-rmras @ONSdigital/census-response-management
 schemas/launch_v2.json @ONSdigital/eq-runner @ONSdigital/sdc-rmras @ONSdigital/census-response-management
 
-schemas/submission_v1.json @ONSdigital/eq-runner @ONSdigital/sdx
 schemas/submission_v2.json @ONSdigital/eq-runner @ONSdigital/sdx

docs/electronic_questionnaire_runner_to_downstream.md

@@ -1,6 +1,6 @@
 # Electronic Questionnaire Runner Response To Downstream
 
-All submitted survey responses and feedback for a collection exercise (a periodic questionnaire within a survey series) are transformed into data formats described below for downstream processing and analysis. The downstream data format can be defined in two ways, version 1 (v1) and 2 (v2) (See: [Payload Formats][payload_formats]). The format used is derived by the `version` that was provided in the launch JWT token. For backwards compatibility, tokens that do not provide a `version` are assumed to be v1. For more information on launch tokens, see [RM to EQ][rm_to_eq_runner].
+All submitted survey responses and feedback for a collection exercise (a periodic questionnaire within a survey series) are transformed into data formats described below for downstream processing and analysis. Currently, only the v2 downstream data format is supported (See: [Payload Formats][payload_formats]). The format used is derived by the `version` that was provided in the launch JWT token. For more information on launch tokens, see [RM to EQ][rm_to_eq_runner].
 
 The data structures created by EQ Runner (e.g. the answer store) are designed and optimised primarily for the purposes of generic functionality within the Runner application. As a general principle, the extent of the transform carried out by Runner on submitted response data beyond its native data models, as well as on claims received by the launching system, is minimal. It is not the responsibility of Runner to carry out bespoke data transforms. Historically, SDX has been responsible for more extensive and complex data transforms.
 
@@ -18,17 +18,8 @@ When the Runner GCS submitter is used, an object containing the response ciphert
 - For `feedback` objects, the object ID is named with a uniquely generated UUID.
 
 The GCS response object contains associated [metadata][gcs_metadata] which can be used in a Pub/Sub messaging strategy for further event driven processes (e.g. receipting and triggering ingestion flow).
-For both v1 and v2 data formats, the metadata will always contain a `tx_id` and a `case_id`.
-For v2, additional receipting metadata may be added, which were defined by `survey_metadata.receipting_keys` from the JTW launch token.
-
-### Example v1 GCS metadata
-
-```json
-{
-	"tx_id": "6fcf3ddc-a685-4aa1-8fcf-3e38aed5cbf7",
-	"case_id": "2859a8b5-34c3-4603-aad9-78198d8341c9"
-}
-```
+Metadata will always contain a `tx_id` and a `case_id`.
+Additional receipting metadata may be added, which are defined by `survey_metadata.receipting_keys` from the JTW launch token.
 
 ### Example v2 GCS metadata
 
@@ -49,11 +40,10 @@ For v2, additional receipting metadata may be added, which were defined by `surv
 
 ## Payload Formats
 
-The overall structure of the downstream payload can be one of two formats depending on the `version` that was provided in the launch token. This is not to be confused with runner's `data_version` which is responsible for the structure of the `data` property within the payload.
+The downstream payload format is set using the `version` that was provided in the launch token, currently only v2 is supported. This is not to be confused with runner's `data_version` which is responsible for the structure of the `data` property within the payload.
 
-For more information on the difference between the v1 and v2 payload, consult the documents below.
+The v2 payload format is documented below.
 
-1. [EQ Runner to Downstream Payload v1][eq_runner_to_downstream_payload_v1]
 2. [EQ Runner to Downstream Payload v2][eq_runner_to_downstream_payload_v2]
 
 ## JWT envelope / transport

docs/respondent_management_to_electronic_questionnaire_runner.md

@@ -5,14 +5,11 @@ This data is wrapped inside a JSON Web Token (JWT) which is attached to the end
 This creates a clean interface for any respondent management system to integrate with the EQ Runner.
 
 ## JWT payload
+The structure of the JWT payload that the RM system uses can be defined using the version property.
+The only current supported version for launching EQ Runner is v2 (Support for the deprecated v1 version has been removed).
+From v2, the JWT payload is required to define a `version` property with the associated version.
+The downstream data is structured based on the version property provided, for information regarding downstream data formats, see [EQ Runner to Downstream][eq_runner_to_downstream].
 
-The structure of the JWT payload that the RM system uses can be defined in two ways, version 1 (v1) **[DEPRECATED]** and 2 (v2).
-The latest and the recommended version for launching EQ Runner is v2.
-From v2, the JWT payload is required to define a `version` property with the associated version. To ensure backwards compatibility, the absence of this property indicates the token is v1.
-Depending on the value defined by the `version` property, the downstream data will also be structured in 2 different ways.
-For information regarding downstream data formats, see [EQ Runner to Downstream][eq_runner_to_downstream].
-
-- [RM to EQ Runner Payload v1][rm_to_eq_runner_payload_v1] **[DEPRECATED]**
 - [RM to EQ Runner Payload v2][rm_to_eq_runner_payload_v2]
 
 ## JWT envelope / transport
@@ -29,5 +26,4 @@ This endpoint takes a JWT in the same way as `/session` but with `roles` includi
 
 [jwt_profile]: jwt_profile.md "JWT Profile Definition"
 [eq_runner_to_downstream]: electronic_questionnaire_runner_to_downstream.md "Electronic Questionnaire Runner to Downstream Definition"
-[rm_to_eq_runner_payload_v1]: rm_to_eq_runner_payload_v1.md "RM to EQ Runner Payload v1 Definition"
 [rm_to_eq_runner_payload_v2]: rm_to_eq_runner_payload_v2.md "RM to EQ Runner Payload v2 Definition"