diff --git a/document/archive/Application_state.pdf b/document/archive/Application_state.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..322bddf898804cdc1f1185253469da2b379f8d83
Binary files /dev/null and b/document/archive/Application_state.pdf differ
diff --git a/document/archive/README.md b/document/archive/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..4dacc2ec19b4e117c9684263db99a0207fdaae68
--- /dev/null
+++ b/document/archive/README.md
@@ -0,0 +1,71 @@
+# VIPS Field Observation App
+This is some old documentation - kept in case we need it for reference
+
+## Misc
+* [First draft of application state management](./docs/Application_state.pdf)
+
+### Synchronization management
+The basic design of synchronization is illustrated below
+![Synchronization design](./docs/synchronization.png "Synchronization design")
+
+There are two modes of synchronization
+#### One-way synchronization
+This is information that flows only from VIPSLogic and to the app:
+* Crop categories
+* Pests
+* Crops
+* crop-pest combinations
+
+##### Triggers
+* LocalStorage does not have the requested resource (e.g. the CropCategory list). Typically when the app is launched for the very first time and the user logs in
+* A different user logs in. The user may come from another organization, where there are different lists
+* The timestamp on the server indicates that the information has changed. For crop categories, pests, crops and crop-pest combinations, the latest update of the info on the server happened at the time stamp served by the web service endpoint `[VIPSLOGIC]/rest/observation/organismsystemupdated`. This timestamp should be checked every time the app starts (and there is a valid login)
+
+
+#### Two-way synchronization
+These objects may change both in the app and through editing using the VIPSLogic admin system. Therefore, updates in the app must be propagated to the other place
+* Observations
+* Places (POIs)
+
+##### Synchronization process
+TODO: The Observation and PointOfInterest (place) entities must both get a "lastUpdated" property
+The synchronization process is simply put a POST request from the app to the server. All objects of one type (Observations or POIs) are represented by a list in LocalStorage. The list is POSTed to a server endpoint. The server handles all the changes and return the updated state to the app, which then in turn updates its list in LocalStorage.
+
+![2-way sync](./docs/sync_2way.png "2-way sync")
+
+In addition to the existing properties of Observation and PointOfInterest, the following are specific to the synchronization process
+* lastUpdated (Date) - stored in DB
+* synchronized (Boolean) - used in the app and on the server when synchronizing
+* force to sync (Boolean) - sync will break the rules. Apply force
+* force update (Boolean) - used to update the object in DB when lastUpdated on server > lastUpdated in the app
+* delete (Boolean) indicates that the object should be deleted on the server
+
+Let's assume that this list of observations is on the app
+
+Observation         |id  |lastUpdated|Synchronized|ForceToSync  | Force   |Delete
+-----------         |----|-----------|------------|-------------|-----   |------
+Apple scab in apple | 43 |2020-05-01 | True       |             |NULL  | False
+Septoria in wheat   | 101|2021-02-12 | False      |   NULL      |NULL  | False
+Blight in potato    |NULL|2021-02-18 | False      |   NULL      |NULL  | False
+
+And let's say that on the server the state is:
+
+Observation         |id  |lastUpdated|
+-----------         |----|-----------|
+Apple scab in apple | 43 |2020-05-01 |
+Septoria in wheat   | 101|2021-02-18 |
+
+
+* The observation with id=43 will not be stored, since it's already synchronized. However, if the lastUpdated on the server is after 2020-05-01, the updated version of it will be returned And the lastUpdated locally will be updated too.
+* The observation with id=101 will not be updated, since the lastUpdated in the app is before the lastUpdated on the server. However, the updated version will not be returned either, since the local state is NOT SYNCED. It will be returned unchanged but with the ForceToSync set to True
+* The observation with id=NULL is a new observation, and will therefore be created and returned with a freshly generated database id
+
+So the returned result is this:
+
+Observation         |id  |lastUpdated|Synchronized|ForceToSync  | Force   |Delete
+-----------         |----|-----------|------------|-------------|-----   |------
+Apple scab in apple | 43 |2020-05-01 | True       |   NULL      |NULL    | False
+Septoria in wheat   | 101|2021-02-12 | False      |   True      |NULL    | False
+Blight in potato    |563 |2021-02-18 | True       |   NULL      |NULL    | False
+
+Now, the user will see that the obs 101 has not been updated, and the ForceToSync=True should make it highlighted. The user should actively choose whether to force save the app version or to pull the updated version from the server. So if the user ticks of "Force" in his list for obs 101, a sync will take place and the database version will be overriden by the one in the app.
diff --git a/document/archive/sync_2way.png b/document/archive/sync_2way.png
new file mode 100644
index 0000000000000000000000000000000000000000..e17e799d2f006c21f7200d20376bd40c0e3491fe
Binary files /dev/null and b/document/archive/sync_2way.png differ
diff --git a/document/archive/synchronization.png b/document/archive/synchronization.png
new file mode 100644
index 0000000000000000000000000000000000000000..585b8b1558b2a44b8db390c63555e060bb258dbd
Binary files /dev/null and b/document/archive/synchronization.png differ