diff --git a/Pipfile b/Pipfile
index 92b24cc7..440626cd 100644
--- a/Pipfile
+++ b/Pipfile
@@ -12,6 +12,7 @@ pymdown-extensions = "*"
 mdx-include = "*"
 yamllint = "*"
 mkdocs-markdownextradata-plugin = "*"
+mkdocs-mermaid-plugin = {git = "https://github.com/pugong/mkdocs-mermaid-plugin"}
 
 [requires]
 python_version = "3"
diff --git a/Pipfile.lock b/Pipfile.lock
index 1a1b1d11..0e287ffe 100644
--- a/Pipfile.lock
+++ b/Pipfile.lock
@@ -1,7 +1,7 @@
 {
     "_meta": {
         "hash": {
-            "sha256": "6c4a8328ad57f41f512fc2074af0ed1289739efa04506c6360c5c7b41fc56685"
+            "sha256": "c8236ff5987aa198bcb48698f6edbe72defdd6423f467932d79b38278133976c"
         },
         "pipfile-spec": 6,
         "requires": {
@@ -16,6 +16,15 @@
         ]
     },
     "default": {
+        "beautifulsoup4": {
+            "hashes": [
+                "sha256:034740f6cb549b4e932ae1ab975581e6103ac8f942200a0e9759065984391858",
+                "sha256:945065979fb8529dd2f37dbb58f00b661bdbcbebf954f93b32fdf5263ef35348",
+                "sha256:ba6d5c59906a85ac23dadfe5c88deaf3e179ef565f4898671253e50a78680718"
+            ],
+            "index": "pypi",
+            "version": "==4.7.1"
+        },
         "click": {
             "hashes": [
                 "sha256:2335065e6395b9e67ca716de5f7526736bfa6ceead690adf616d925bdc622b13",
@@ -115,6 +124,10 @@
             "index": "pypi",
             "version": "==4.1.1"
         },
+        "mkdocs-mermaid-plugin": {
+            "git": "https://github.com/pugong/mkdocs-mermaid-plugin",
+            "ref": "abf14392b0ed0c7022210b32c4e7c9c3e4c5c68a"
+        },
         "pathspec": {
             "hashes": [
                 "sha256:54a5eab895d89f342b52ba2bffe70930ef9f8d96e398cccf530d21fa0516a873"
@@ -166,6 +179,13 @@
             ],
             "version": "==1.12.0"
         },
+        "soupsieve": {
+            "hashes": [
+                "sha256:6898e82ecb03772a0d82bd0d0a10c0d6dcc342f77e0701d0ec4a8271be465ece",
+                "sha256:b20eff5e564529711544066d7dc0f7661df41232ae263619dede5059799cdfca"
+            ],
+            "version": "==1.9.1"
+        },
         "tornado": {
             "hashes": [
                 "sha256:1174dcb84d08887b55defb2cda1986faeeea715fff189ef3dc44cce99f5fca6b",
diff --git a/docs/kit/README.md b/docs/kit/README.md
index 81c4ecc3..dd059fc8 100644
--- a/docs/kit/README.md
+++ b/docs/kit/README.md
@@ -12,7 +12,7 @@ This is the Kit Coordinator's documentation. The Kit Coordinator is responsible
 Role  |   Volunteer   |   Location of Documentation
 ------|---------------|----------------------------
 Kit Software Coordinator | Richard Barlow | [Docs](/kit/software)
-Kit Logistics Coordinator | Richard Barlow | [Docs](https://www.gitbook.com/read/book/srobo-legacy/student-robotics-kit-logistics)
+Kit Logistics Coordinator | Richard Barlow | [Docs](/kit/logistics)
 Kit Support Coordinator | Richard Barlow | [Docs](/kit/support)
 Hardware Development Coordinator | [unfilled] |
 Hardware Production Coordinator | Richard Barlow | [Docs](/hw-prod-coord)
diff --git a/docs/kit/logistics/README.md b/docs/kit/logistics/README.md
new file mode 100644
index 00000000..56c4edfe
--- /dev/null
+++ b/docs/kit/logistics/README.md
@@ -0,0 +1,19 @@
+---
+original:
+  authors: Richard Barlow
+  url: https://srobo-legacy.gitbooks.io/student-robotics-kit-logistics
+---
+# Kit Logistics Documentation
+
+This is the documentation of the Student Robotics Kit Logistics Coordinator.
+
+The responsibilities of the Kit Logistics Coordinator are as follows:
+
+* To store the kit
+* To manage the transportation/shipping of the kit
+* To manage the organisation's third party post handling service
+* To maintain a record of the location and state of all Student Robotics assets
+
+To fulfil these responsibilities the Kit Logistics Coordinator also does the following
+
+* Maintain a suite of logistics software
diff --git a/docs/kit/logistics/asset-tracking.md b/docs/kit/logistics/asset-tracking.md
new file mode 100644
index 00000000..a3ee1630
--- /dev/null
+++ b/docs/kit/logistics/asset-tracking.md
@@ -0,0 +1,125 @@
+---
+original:
+  authors: Richard Barlow
+  url: https://srobo-legacy.gitbooks.io/student-robotics-kit-logistics/asset-tracking.html
+---
+# Asset Tracking
+
+One of the responsibilities of the Kit Logistics Coordinator is to maintain a record of the location and state of all SRs assets. This is generally referred to as asset tracking. To allow SR to operate it is important that the location and state of all of its assets are known at all times.
+
+This chapter documents the high-level organisation aspects around SR asset tracking. It is not intended as a comprehensive user manual for the Inventory system, but rather how SR uses the system to track its assets.
+
+See the page on [logistics-software](./logistics-software.md) for details of the inventory's datastore and tooling required to use it.
+
+## The Inventory
+
+To record all of the necessary information regarding SR assets, all[^1] assets are tracked in the Inventory. Unfortunately, due to historical use of the term, SR uses the term *Inventory* to refer to its asset tracking system. Normally inventory refers to a record of things that an organisation sells whereas assets are things that an organisation owns and uses to operate; tracked in its asset tracking system. It is not a big problem, but it is an unusual quirk to be aware of.
+
+Each asset, for example an individual webcam, has a corresponding record in the Inventory. Within this record various properties of the asset are held such that it is possible to unambiguously identify the matching asset from its Inventory record and conversely, identify the matching Inventory record from the asset. There is a one-to-one mapping of assets to Inventory records.
+
+Each type of asset is identified by its *name*; for example a Logitech C270 webcam has the name `webcam-logitech-c270`. All assets of the same type have the same name. When creating assets that do not have an existing name in the Inventory, care must be taken to ensure that the new name given to the asset is suitably descriptive. This ensures that it does not clash with future assets that are similar, but not the same; for example an asset with the name `usb-charger` is not descriptive enough, but `usb-charger-a-500ma` is.
+
+The Inventory primarily records the location of each asset, its value, its physical and functional condition, its asset code and a history of any changes made to any of these properties. Secondary to these properties, certain assets have extra information recorded such as MAC address (for assets that have an Ethernet or Bluetooth PHY), serial number and modification flags.
+
+To provide the one-to-one mapping between assets and their Inventory records, each asset/record pair have an *asset code*, which uniquely identifies them. An important part of maintaining this one-to-one mapping is ensuring that the asset code is suitably marked onto the asset such that it can be read in the future.
+
+Only property of SR is tracked in the Inventory; meaning that property of third parties must not be tracked in the Inventory.
+
+### Asset Lifecycle
+
+For each asset that SR owns there is a reasonably well defined sequence of stages that it flows through during its lifetime. This flow is shown in the diagram below.
+
+```mermaid
+graph LR
+  create(Creation)
+  commission(Commission)
+  use(Use)
+  test(Test)
+  repair(Repair)
+  modify(Modify)
+  decommission(Decommission)
+  disposal(Disposal)
+
+  create-->commission
+  commission-->use
+  use-->modify
+  use-->test
+  use-->decommission
+  modify-->test
+  test-->repair
+  test-->use
+  test-->decommission
+  repair-->test
+  decommission-->disposal
+```
+
+#### Creation
+
+When an asset is purchased or manufactured, a record must be entered into the Inventory. At this point a new asset code is automatically generated. The asset code **must** be marked onto the asset[^2]. The asset code can be marked in the following ways:
+
+  * Printed paper label with QR code and text
+  * Dymo label with code128 barcode and text
+  * Handwritten with permanent marker
+  * UHF RFID tag[^3]
+  * Programmed onto the asset (e.g. such that it is possible to read over USB)
+
+More than one of the above techniques can be used to provide redundancy.
+
+The ideal marking solution is both human and machine readable and should be durable. These criteria should be considered when deciding how to mark a particular asset. Programming the asset code onto the asset, where possible, provides a very high level of durability as there is no label or pen that can be damaged; However one has to physically plug a cable in to read the code. QR codes and barcodes have the advantage that physical contact with the asset is not required, but they do require the asset to be visible. UHF RFID tags provide the added benefit of allowing the asset code to be read even when they are not visible; for instance when it is in a box.
+
+#### Commission
+
+Some assets will require commissioning after they have been added to the Inventory. This can be best explained with an example: When a newly manufactured motor board is added to the Inventory it is yet to be programmed or fully tested (although it may have had some basic end-of-line testing performed upon it). Once it has been added to the Inventory, in the *Creation* stage, it is ready to be programmed and tested before being used. This initial programming and testing of the motor board is part of its *commissioning* process.
+
+Not all assets will require commissioning. Generally these are things such as USB hubs, where it is assumed that the manufacturer has suitably tested their product and there is no further programming required.
+
+Once an asset has been commissioned, its physical and functional condition must be updated appropriately in its record. In the case of assets that do not require any special commissioning procedure to be carried out, it should be assumed that they are both physically and functionally working and their records updated as such.
+
+#### Use
+
+Once an asset has been commissioned, or has been tested and shown to be working, it is ready to be used for its intended purpose. For the majority of assets this means that it will become part of a kit and ultimately be used by a team.
+
+During the *use* stage of an assets lifetime the majority of the updates to its record in the Inventory will be to keep track of its physical location; for example with a particular team. Occasionally there may also be other updates to its record required, such as adding a note to its description.
+
+#### Test
+
+The Inventory should, as far as is possible, represent the current state of all assets. However as time passes, the recorded physical and functional condition of a given asset will diverge from reality. To help rectify this, assets are regularly tested. For most assets this occurs once each year at the [Kit Collation Event][kit-collation-event], run by the [Hardware Production Coordinator][hardware]. Assets that have been repaired or modified must also undergo testing.
+
+As in the *commission* stage, an asset's physical and functional condition must be updated appropriately in its record once it has been tested. If the asset is in full working order it is ready for use. If the asset is broken then it may be possible to repair it. In some situations it is either not cost effective or not possible to repair an asset. When this occurs, the asset is no longer useful to SR and will be *decommissioned* and *disposed* of.
+
+[kit-collation-event]: ../hardware/kit-collation.md
+[hardware]: ../hardware/README.md
+
+#### Repair
+
+If an asset is found to be broken, it may be possible to repair it. An example of this is a motor board that has a cracked case. It is trivial to replace the broken parts of the case and therefore allow the motor board to once again be used (after being retested).
+
+#### Modify
+
+Throughout the lifetime of an asset it may be necessary to perform modifications to it. This may be to add extra functionality, improve reliability or to fix a known problem. For most assets the opportunity to perform these modifications is at the Kit Collation Event, run by the Hardware Production Coordinator. If modifications are required they will perform them as necessary.
+
+When modifications are made to an asset it is important to track the changes in its Inventory record. These generally take the form of *modification flags* that indicate if a particular asset has been modified. If a modification across all assets of a given type is planed, for example soldering on an extra component to all motor boards, then all motor board Inventory records should be updated to indicate that none of them have received the modification. Once each asset is modified, its Inventory record must be updated appropriately.
+
+#### Decommission
+
+If an asset is broken and unrepairable or if an asset is simply no longer required then it must be decommissioned and then disposed of. The Kit Logistics Coordinator must only decommission and dispose of an asset when explicitly instructed to do so by the person responsible for the asset. **TODO: Define who is responsible for each type of asset**
+
+It must first be determined if the asset is to be sold/given away or if it is to be thrown away, as this affects the decommissioning process. Some assets will have specific decommissioning requirements, however in all cases there are common steps that must be taken.
+
+For assets that are to be sold or given to a third party all SR logos and 'property of' messages must be removed/obliterated. This ensures that future owners and users of the assets do not mistakenly think that it is property of SR and that SR itself does not mistakenly think that it is property belonging to SR.
+
+Once an asset has been fully decommissioned its Inventory record must be updated with a *modification flag* that indicates that it has been decommissioned.
+
+#### Disposal
+
+Once an asset has been decommissioned, it must be either sold/given away or thrown away, depending upon what was previously agreed when starting the decommissioning process.
+
+If an asset is to be sold the Kit Logistics Coordinator will work with the person previously responsible for that asset to determine the best way to sell the asset. If the estimated value of the asset at the time of selling is above £50 then the trustees are to be be consulted.
+
+If an asset is to be thrown away the Kit Logistics Coordinator will work with the person previous responsible for that asset to determine if there are any special requirements regarding its disposal; for example WEEE regulations for electronics. Also if the value of the asset, as shown in its Inventory record, is above £50 then the trustees are to be consulted.
+
+Once an asset has been disposed of, either via selling/giving away or by throwing away, its Inventory record must be removed from the Inventory. Only records that have a decommissioned modification flag should be removed from the Inventory.
+
+[^1]: This is not strictly true as certain low-value assets are not tracked. A general rule-of-thumb is that anything under £5 is not tracked.
+[^2]: There was historically a concept of 'deferred labelling', where a record was added to the Inventory and the asset labelled at a later time. This approach is no longer used as it can result in assets going unlabelled.
+[^3]: Currently in the planning stage.
diff --git a/docs/kit/logistics/kit-storage.md b/docs/kit/logistics/kit-storage.md
new file mode 100644
index 00000000..d11286fe
--- /dev/null
+++ b/docs/kit/logistics/kit-storage.md
@@ -0,0 +1,8 @@
+---
+original:
+  authors: Richard Barlow
+  url: https://srobo-legacy.gitbooks.io/student-robotics-kit-logistics/kit-storage.html
+---
+# Kit Storage
+
+Between Kickstart and the Competition most of SR's assets are 'stored' with teams. Otherwise assets are stored either at a storage facility in Newbury or, between the Kit Collation Event and the Kit Packing Event, at a storage facility close to the location of the aforementioned events.
diff --git a/docs/kit/logistics/kit-transport.md b/docs/kit/logistics/kit-transport.md
new file mode 100644
index 00000000..b7c2bd1b
--- /dev/null
+++ b/docs/kit/logistics/kit-transport.md
@@ -0,0 +1,14 @@
+---
+original:
+  authors: Richard Barlow
+  url: https://srobo-legacy.gitbooks.io/student-robotics-kit-logistics/kit-transport.html
+---
+# Kit Shipping
+
+Part of the Kit Logistics Coordinator's responsibilities cover moving either whole or parts of kits around the UK and the world. This is generally referred to as shipping (even though it rarely involves ships!). All movement of kit is managed by the Kit Logistics Coordinator, so please do not ship anything without first speaking to them. You can contact them at: [logistics@studentrobotics.org](mailto:logistics@studentrobotics.org).
+
+Almost all shipping requirements happen at well defined points throughout the Student Robotics calendar. When kits or parts therefore need to be shipped specific procedures are followed as detailed in the [Procedures](./transport/procedures.md) chapter.
+
+When kits or parts of kit are being shipped they must be suitably packaged to prevent them from being damaged. Details of the packaging requirements are detailed in the [Packaging](./transport/packaging.md) chapter.
+
+Some parts of the kit require special attention when being shipped. The [Couriers](./transport/couriers.md) chapter includes information on these requirements along with some general information about the parts commonly shipped.
diff --git a/docs/kit/logistics/logistics-software.md b/docs/kit/logistics/logistics-software.md
new file mode 100644
index 00000000..4cc97db4
--- /dev/null
+++ b/docs/kit/logistics/logistics-software.md
@@ -0,0 +1,15 @@
+---
+original:
+  authors: Richard Barlow
+  url: https://srobo-legacy.gitbooks.io/student-robotics-kit-logistics/logistics-software.html
+---
+# Logistics Software
+
+To fulfil the multitude of responsibilities, the Kit Logistics Coordinator uses various pieces of custom software. The software projects used and maintained by the Kit Logistics Coordinator are listed below.
+
+## Software Projects
+
+| Name            | Project URL | Notes |
+| --------------- | ----------- | ----- |
+| Inventory Tools | [https://github.com/srobo/tools/](https://github.com/srobo/tools/) | This project currently contains a mishmash of tools. The Inventory tools need teasing out. See https://srtools.readthedocs.io/en/latest/inventory/ for details of the inventory related commands |
+| Inventory       | [https://github.com/srobo/inventory](https://github.com/srobo/inventory) | This is not a software project in itself. It represents the current state of all SR assets. |
diff --git a/docs/kit/logistics/post-handling.md b/docs/kit/logistics/post-handling.md
new file mode 100644
index 00000000..d11b36ba
--- /dev/null
+++ b/docs/kit/logistics/post-handling.md
@@ -0,0 +1,20 @@
+---
+original:
+  authors: Richard Barlow
+  url: https://srobo-legacy.gitbooks.io/student-robotics-kit-logistics/post-handling.html
+---
+# Post Handling
+
+These are the procedures related to the Kit Logistics Coordinator's post handing responsibilities.
+
+## Handling received mail
+
+If specified, request that the first page is scanned and then notify the person as defined in the following table.
+
+| Addressee | Scan first page? | Email |
+| :--- | :--- | :--- |
+| Treasurer | Yes | treasurer@studentrobotics.org |
+
+## Topping up UK Postbox
+
+UK Postbox requires topping up with credit. Budget for this comes from either the `srXXXX/post` or the `srXXXX/kits/shipping` budget lines depending on what it will generally be used for. Obviously it's not possible to know exactly how the credit will ultimately be spent so it's not critical. Since it is not possible to extract money back out of UK Postbox, top ups should be sufficient for the foreseeable future only.
diff --git a/docs/kit/logistics/research.md b/docs/kit/logistics/research.md
new file mode 100644
index 00000000..dd186ad3
--- /dev/null
+++ b/docs/kit/logistics/research.md
@@ -0,0 +1,18 @@
+---
+original:
+  authors: Richard Barlow
+  url: https://srobo-legacy.gitbooks.io/student-robotics-kit-logistics/research.html
+---
+# Research
+
+The following sections document various bits of research that have been carried out by the Kit Logistics Coordinator while fulfilling their responsibilities.
+
+## Return Shipping Bag
+
+| Size (mm) | Actual size (mm) | 18l RUB fit | 9l RUB (non-XL) fit |
+| --- | --- | --- | --- |
+| 425x600 |  | \[untested\] | \[untested\]. I suspect that it will be good, but I need to get a sample bag. |
+| 525x600 | 524x610 | Does not fit | Fits easily with the box aligned with the bag. Is a tight, but comfortable, fit with the box sideways relative to the bag. It very nearly fits two boxes in sideways, but is a little too short. |
+| 575x700 | 583x714 | Perfect easy fit with the box aligned with the bag | Easily fits two boxes either side-by-side or stacked (preferred due to its rigidity) |
+| 600x900 | 600x900 | Easily fits with the box aligned with the bag | Easily fits three boxes. Two stacked and one on its side. It is not a particularly solid arrangement. |
+| 700x850 | 700x850 | Easily fits in both orientations | Fits four boxes, stacked, pretty much perfectly. |
diff --git a/docs/kit/logistics/transport/couriers.md b/docs/kit/logistics/transport/couriers.md
new file mode 100644
index 00000000..d7a7fe1d
--- /dev/null
+++ b/docs/kit/logistics/transport/couriers.md
@@ -0,0 +1,21 @@
+---
+original:
+  authors: Richard Barlow
+  url: https://srobo-legacy.gitbooks.io/student-robotics-kit-logistics/kit-transport/couriers.html
+---
+# Couriers
+
+We have confirmed that the following couriers are happy handling packages containing lithium polymer batteries:
+
+* Interlink [http://www.interlinkdirect.co.uk/](http://www.interlinkdirect.co.uk/)
+
+Kit data for couriers:
+
+* Dimensions: 48cm x 39cm x 20cm
+* Weight: 6kg (A kit weighs 4.95kg [ref](../../kit-definition.md). 6kg gives some headroom)
+* Value (for insurance): £500
+* Batteries: Lithium Ion. Packed with equipment. Batteries less than 100Wh.
+
+In all circumstances a shipment of a kit must have at least £500 worth of insurance.
+
+Note that the above package details are repeated in the loan extension instructions in [return-shipping-pack.git](https://github.com/srobo/return-shipping-pack/tree/master/instructions) and therefore should be updated there when the details change.
diff --git a/docs/kit/logistics/transport/packaging.md b/docs/kit/logistics/transport/packaging.md
new file mode 100644
index 00000000..526954b9
--- /dev/null
+++ b/docs/kit/logistics/transport/packaging.md
@@ -0,0 +1,63 @@
+---
+original:
+  authors: Richard Barlow
+  url: https://srobo-legacy.gitbooks.io/student-robotics-kit-logistics/kit-transport/packaging.html
+---
+# Packaging
+
+This information on packaging of kits and kit parts is for internal use only. The Kit Logistics Coordinator will use this information to instruct volunteers and third parties as necessary.
+
+## Packaging Info
+
+* Kits should generally be shipped in the while 18l Really Useful Box (RUB).
+* All parts of the kit should be suitably protected either in Jiffy bags or bubble wrap. The Return Shipping Pack includes a new set of jiffy bags.
+* Batteries **must** be placed inside a small brown jiffy bag and the jiffy bag placed inside the charging bag.
+* In general no more than two batteries should be shipped in each RUB (to ease shipping restrictions).
+* Damaged batteries must not be shipped.
+* Any empty space in the box should be filled with paper or bubble wrap. No packing peanuts; They're messy. The Return Shipping Pack includes sufficient paper.
+* The box should be sealed with cable ties and, if available high quality tape over the handles (not selotape or insulating tape). The Return Shipping Pack includes cables ties, but no tape (as it's difficult to obtain a tiny roll of high quality tape).
+
+## Return Shipping Pack
+
+When teams have to return a kit to us we provide them with a return shipping pack. This kit contains the following:
+
+| Item | Quantity | URL | Notes |
+| :--- | :--- | :--- | :--- |
+| 575x700mm polythene bag | 1 | [UK Packaging ref 08220](http://www.ukpackaging.com/postal-packaging/polythene-mailing-bags/grey-polythene-mailing-bags-575x700mm-60mu) | [Bag size research](../research.md#return-shipping-bag) |
+| 160x4.8mm cable tie | 5 | [Cableties Online](https://www.cabletiesonline.co.uk/cable-ties-b-w/cable-ties-160mm-x-4.html) | Two per handle. One spare. |
+| 112x80mm caution lithium ion battery label | 1 | [Limpet Labels](http://www.limpetlabels.co.uk/shop/view/293_Caution_Lithium_Battery_Labels/755_Caution_Lithium_Ion_Battery_Labels_%28112_x_80mm%29) |  |
+| A6 plain document wallet | 2 | [UK Packaging ref 10008](http://www.ukpackaging.com/document-wallets-a6-document-enclosed-wallets-plain) | One to use for address label. One spare. |
+| 750mm wide kraft paper | 2m | [UK Packaging ref 11042](http://www.ukpackaging.com/kraft-paper-rolls-imitation-kraft-kraft-paper-rolls-imitation-kraft-750mmx220m) |  |
+| 120x215mm (internal) gold jiffy bag | 4 | [UK Packaging ref 09033](http://www.ukpackaging.com/arofol-classic-postal-bags-gold-2) |  |
+| 170x245mm (internal) white jiffy bag | 4 | [UK Packaging ref 09312](http://www.ukpackaging.com/jiffy-earth-aware-airkraft-white-ak1-170x245mm-50-pack) |  |
+| 220x320mm (internal) white jiffy bag | 1 | [UK Packaging ref 09314](http://www.ukpackaging.com/postal-packaging/jiffy-bags/jiffy-earth-aware-airkraft-white-ak3-220x320mm-50-pack) | To put the whole return shipping pack into. |
+| Return shipping pack instructions | 1 | [Revision SR2017-2](https://github.com/srobo/return-shipping-pack/releases/download/SR2017-2/return-shipping-pack-instructions.pdf) |  |
+| Loan extension instructions | 1 | [Revision SR2017-2](https://github.com/srobo/return-shipping-pack/releases/download/SR2017-2/loanext-instructions.pdf) | Only included in return shipping packs handed out at the end of the competition. |
+| Kit list | 1 | [Kit Definition](../../kit-definition.md) | Only included in return shipping packs handed out at the end of the competition. Remove 'disclaimer'  and the wire from the list. |
+
+### Instruction Notes
+
+1. Check all parts are present (use list provided and notify the local teams coordinator of any missing items).
+2. Place parts into jiffy bags (do not seal unless specified):
+   1. Large white **\[photo of four bags with the parts in front\]:**
+      1. 1x tablet
+      2. 1x battery charger
+      3. 1x battery charger power supply, 1x webcam, 1x tablet charger
+      4. 1x power board, 1x servo board
+   2. Small brown **\[photo of four bags with the parts in front\]**:
+      1. 2x batteries
+      2. 2x motor boards, 1x ruggeduio with screw shields plugged in
+      3. 2x USB hubs, 1x brain board
+      4. Remaining loose items: wifi dongles, usb memory stick, camcons (7.5, 5 and 3.81mm), screwdriver, brain board power cable. **seal**.
+3. Place jiffy bag containing the batteries into the battery charging bag **\[photo of jiffy bag partially in charging bag\]**
+4. Tear the brown paper into two equally sized pieces
+5. Scrunch up one piece of brown paper and place in the bottom of the RUB **\[photo of scrunched up paper in the bottom of RUB\]**
+6. Place battery charging bag, jiffy bags and all cables (full size USB, micro USB and any wire) into the RUB **\[photo of stuff in RUB\]**
+7. Scrunch up the other piece of brown paper and place on top of the stuff **\[photo of scrunched up paper on top\]**
+8. Fit the lid onto the RUB and seal handles with four cable ties (do not cut the cable ties as the sharp corners could tear the bag) **\[photo of cable tie being threaded through, photo of loose cable tie, photo of complete handle demonstrating tail direction\]**
+9. Place the sealed RUB into the bag **\[photo of RUB partially in the bag\]**
+10. Seal the bag closed **\[photo of the sealed bag highlighting it being tight\]**
+11. Stick the LiPo sticker onto the bag
+12. Place the supplied shipping label into the document wallet and stick the document wallet onto the bag (don't forget to remove the narrow backing strip too) **\[photo of lipo sticker and shipping label in document wallet\]**.
+13. Hand the package to reception/who ever it will be collected from.
+14. Notify your local teams coordinator that the kit is ready for collection.
diff --git a/docs/kit/logistics/transport/procedures.md b/docs/kit/logistics/transport/procedures.md
new file mode 100644
index 00000000..8638bb8c
--- /dev/null
+++ b/docs/kit/logistics/transport/procedures.md
@@ -0,0 +1,117 @@
+---
+original:
+  authors: Richard Barlow
+  url: https://srobo-legacy.gitbooks.io/student-robotics-kit-logistics/kit-transport/procedures.html
+---
+# Procedures
+
+These are the procedures that the Kit Logistics Coordinator follows to perform their Kit Shipping responsibilities. No one else is expected to follow these procedures, they are for internal documentation only.
+
+## Shipping kits to Kickstarts
+
+To provide sufficient time for problems/delays, kits should be shipped to Kickstart locations no later than 1 week before Kickstart. Shipping the kits many weeks in advance may not be possible due to limited storage requirements at some Kickstart locations.
+
+First ensure that the Kickstart Event Coordinator is aware of the paperwork requirements (handout forms and disclaimers). Request the following information from the Kickstart Event Coordinator:
+
+* Name of Local Kickstart Event Coordinator
+* Email address of Local Kickstart Event Coordinator
+* Number of teams attending
+* Name of person able to receive the kit (if not the Local Kickstart Event Coordinator)
+* Email address of person able to receive the kit (if not the Local Kickstart Event Coordinator)
+* Phone number of person able to receive the kit
+* Address to ship the kit to
+
+For each Kickstart:
+
+1. Ensure that the Local Kickstart Event Coordinator, or the person that they are delegating kit management to, has received the necessary training (to be defined).
+2. Identify the kits to be shipped in the Inventory and move them into an appropriate `in-transit` sub directory (e.g. `in-transit/to-oxford-ks`).
+3. Instruct UK Postbox to forward the correct items to the recipient.
+4. Once UK Postbox have forwarded on the kits, email the LKEC and the recipient (if not the LKEC) with the tracking number/link and a list of kit asset numbers shipped to them. Ask them to report back when they have received the shipment and doubled checked that they have the expected kits.
+5. Once the kits have been delivered, move them in the Inventory to an appropriate sub directory (e.g. `kickstart-venues/oxford`).
+6. Email details of what kits are where to the Kickstart Event Coordinator so that they can prepare handout forms for each of the Local Kickstart Event Coordinators.
+
+After Kickstart, request scanned copies of the handout form and disclaimers from all of the Kickstarts from the Kickstart Event Coordinator (who will then request them from the Local Kickstart Coordinators). Move each kit into an appropriate sub directory in the Inventory based upon which team it was given to (e.g. move a kit to `teams/2017/srz`).
+
+## Shipping kits to teams that didn't attend a Kickstart
+
+The operations manual currently requires that the Kit Logistics Coordinator ensures that kits are available to be collected by a courier no later than 2 week after Kickstart.
+
+Begin by requesting the following information from the Team Coordinator for the teams that didn't attend a Kickstart and ask them to confirm that the details are correct via the appropriate local teams coordinator:
+
+* Name of local teams coordinator
+* Email of local teams coordinator (so that any further queries and an email containing a tracking link doesn't have to go via the Team Coordinator)
+* Name of recipient
+* Email of recipient
+* Phone number of recipient (ideally a mobile number as that's what couriers prefer)
+* Address including:
+  * School name
+  * Number (if applicable)
+  * Street
+  * Town/City
+  * County
+  * Postcode
+
+For each team that needs a kit:
+
+1. Identify the kit to be shipped in the Inventory and move it to an appropriate `in-transit` sub directory (e.g. `in-transit/to-srz`).
+2. Once the details have been confirmed, instruct UK Postbox to forward the correct item to the team.
+3. Once UK Postbox have forwarded on the kit, email the local teams coordinator with the tracking number/link so that they can pass it onto the team. Get them to ask the team to inform them when the kit has been delivered.
+4. Once the kit has been delivered, move the kit in the Inventory to the appropriate `team` sub directory (e.g. `teams/2017/srz`).
+
+## Managing kits not collected at Kickstart
+
+Some teams may not turn up at Kickstart, therefore leaving their kit uncollected. This kit needs to either be stored safely by someone nearby or returned to UK Postbox. The kit will most likely make its way to a team (either the originally intended recipient or otherwise) in the week or two after Kickstart.
+
+If a responsible person in attendance at the Kickstart event (for example the Local Kickstart Coordinator) is willing to store the kit for a week or two, and is able to make it available for courier collection, then this is preferable.
+
+If it is not possible to store the kit locally, it must be returned to UK Postbox ASAP. A [Return Shipping Pack](#return-shipping-pack) must be used to package the kit for return. Someone (possibly the venue) will need to make the kit available for courier collection in the day or two following Kickstart.
+
+## Reallocating kits from drop-outs
+
+We need to ship kits from one team to another when a team drops out. TBD.
+
+## Shipping spares/replacements
+
+When parts of the kit break teams need replacements. The Kit Logistics Coordinator needs to ship these spares/replacements to teams when instructed to do so by the Kit Support Coordinator.
+
+Begin by requesting the following information from the Team Coordinator for the team that needs replacement parts shipping to them and ask them to confirm that the details are correct via the appropriate local teams coordinator:
+
+* Name of local teams coordinator
+* Email of local teams coordinator (so that any further queries and an email containing a tracking link doesn't have to go via the Team Coordinator)
+* Name of recipient
+* Email of recipient
+* Phone number of recipient (ideally a mobile number as that's what couriers prefer)
+* Address including:
+
+  * School name
+  * Number (if applicable)
+  * Street
+  * Town/City
+  * County
+  * Postcode
+
+* Identify the replacement parts to be shipped in the Inventory (as defined by the Kit Support Coordinator) and move them to an appropriate `in-transit` sub directory (e.g. `in-transit/to-srz`).
+
+* Package the parts into a cardboard box, using Jiffy bags, bubblewrap or similar to protect the parts.
+
+* Once the details have been confirmed, arrange for the package to be collected from yourself and delivered to the team.
+
+* Once you have the tracking number from the courier, email the local teams coordinator with the tracking number/link so that they can pass it onto the team. Get them to ask the team to inform them when the kit has been delivered.
+
+* Once the kit has been delivered, move the kit in the Inventory to the appropriate `team` sub directory (e.g. `teams/2017/srz`).
+
+## Shipping kits to storage at the end of the competition
+
+At the end of the competition we have the majority of the kits returned to us. The Competition Team Coordinator is responsible for managing the return process. The Kit Logistics Coordinator can aid in this process and is responsible for shipping the kits to storage after they have been returned. TBD.
+
+## Ensuring the timely return of kits not returned at the competition
+
+Some teams will have been given permission to retain their kit for a while after the competition. The teams are responsible for arranging and paying for a courier to return the kit to us. The Kit Logistics Coordinator is responsible for assisting teams in this process and ensuring that all kits are returned by the 1st June of the same year that the competition was held in. TBD.
+
+## Shipping of non-team kits and development tools to volunteers
+
+Non-team kits (those that are classed as development, support, PR or local) and development tools need to be shipped around as deemed appropriate by the person responsible for their allocation. That being the Kit Coordinator for development kits and tools, the Kit Support Coordinator for support kits, the PR coordinator for PR kits and the Team Coordinator for local kits. TBD.
+
+## Shipping of non-kit assets
+
+Most assets are kit related. However, a few assets are not kits or parts thereof. This is mostly competition hardware such as arena walls. The Kit Logistics Coordinator is also responsible for shipping these non-kit assets when required. TBD.
diff --git a/mkdocs.yml b/mkdocs.yml
index 22235147..61756aaf 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -32,11 +32,19 @@ extra:
     - type: twitter
       link: https://twitter.com/studentrobotics
 
+extra_javascript:
+  - https://unpkg.com/mermaid@7.1.2/dist/mermaid.min.js
+
 # Extensions
 markdown_extensions:
+  # Note: the markdownmermaid plugin doesn't work properly if we enable either
+  # of the following extensions, so we keep them disabled. If we turn out to
+  # need code blocks in this project, we can re-evaluate this then.
+  # - markdown.extensions.codehilite
+  # - pymdownx.superfences
+
+  - footnotes
   - markdown.extensions.admonition
-  - markdown.extensions.codehilite:
-      guess_lang: false
   - markdown.extensions.def_list
   - markdown.extensions.toc:
       permalink: true
@@ -52,7 +60,6 @@ markdown_extensions:
   - pymdownx.mark
   - pymdownx.progressbar
   - pymdownx.smartsymbols
-  - pymdownx.superfences
   - pymdownx.tasklist:
       custom_checkbox: true
   - pymdownx.tilde
@@ -63,3 +70,4 @@ markdown_extensions:
 plugins:
   - search
   - markdownextradata
+  - markdownmermaid