Add ADR for form abstraction design

docs/adr/adr-013-inferring-la-from-postcode.md

@@ -1,12 +1,12 @@
-### ADR - 012: Inferring LA from postcode
+### ADR - 013: Inferring LA from postcode
 
 We use ONS data to infer local authority from postcode in the property information section.
-The Office for National Statistics (ONS) publishes the National Statistics 
-Postcode Lookup (NSPL) and ONS Postcode Directory (ONSPD) datasets, 
-which may be used to find a local authority district for a postcode when compiling statistics. 
+The Office for National Statistics (ONS) publishes the National Statistics
+Postcode Lookup (NSPL) and ONS Postcode Directory (ONSPD) datasets,
+which may be used to find a local authority district for a postcode when compiling statistics.
 
 We're using postcodes.io API with postcodes_io gem.
 Postcodes.io uses OS and ONS data which is updated as soon as new data becomes available.
 
-We are not using OS places API due to the lack of data. 
+We are not using OS places API due to the lack of data.
 Closest datapoint to LA in OS places api is ADMINISTRATIVE_AREA which does not always match with local authority.

docs/adr/adr-014-annual-form-changes.md

@@ -0,0 +1,14 @@
+### ADR - 014: Annual form changes
+
+Given that the data collection form changes annually and that the data collection windows overlap by several months to allow for late submissions of data from the previous year, we need to be able to run at least two different versions of a form concurrently. We can do this in one of at least two ways:
+
+1. Use our existing routing logic: Make new questions for a given year dependent on the answer to the tenancy start date question, and for tweaks to the wording of existing questions and/or answer options etc, split it into two questions in the definition with each being dependent on the corresponding answer to the start date question.
+
+2. Have a separate form definition file per year, and load the question details from the correct one based on the answer to the start date question.
+
+We chosen option 2 which has the following impact:
+
+- It results in a lot of duplication across form definition files since the bulk of the form is likely to be the same across following years, but this duplication is likely to be predominantly copy and paste and unlikely to add significant effort
+- It makes it easier to reason about removing no longer needed logic and versions since files whose data collection windows have closed can be safely deleted without fear of impacting running data collections
+- The form definition files themselves are already long and complex so splitting them up where possible makes them easier to reason about individually
+- It is easy to move back to option 1 if this path is deemed not to work well