diff --git a/handbook/troggle/cavelengths.html b/handbook/troggle/cavelengths.html
new file mode 100644
index 000000000..6d613b63a
--- /dev/null
+++ b/handbook/troggle/cavelengths.html
@@ -0,0 +1,143 @@
+Cave lengths
+Lengths of Caves
+How we measure and record the lengths of our discoveries
+
+This needs to be reformatted and turned into proper documentaiton.
+
+
+
+Re: SMK length and depth over time / at the end of each Expo
+_EXPO-2025
+
+Wookey
+Attachments
+Fri, 25 Oct 2024, 03:16
+to Rebecca, me
+
+On 2024-10-24 10:58 +0100, Rebecca Lawson wrote:
+> Do we have this saved anywhere?
+
+
+We have alll the years since 2012 recored in this spreadsheet:
+loser/.git/tree/docs/smklengths.ods
+
+There isn't a handy web-page with historical info SFAIK. We did used
+to have a 'longanddeep' page which I think had this info on, but I
+think it's gone, and maybe it only ever had the current info (and our
+place in world tables)?
+
+> I've seen various graphs in talks where it
+> has been used, taken I guess just from the survex data and I know Wookey
+> usually reports this data each year to the Austrians but it isn't
+> necessarily that easy to extract out just SMK.
+
+
+This is the main reason its important to keep it possible to process subsets of the loser dataset, so that we can process
+'smk-system.svx' to easily get the length for that subset, and also the individual caves.
+
+For getting the lenght there are two ways to run at it:
+
+- process smk-system.svx, or
+
- process all the caves that are part of smk.svx and add them up.
+
+They should produce the same number give or take a couple of metres,
+but I've not checked to see how many years that's actually true for,
+and right now it turns out they differ by 39m for 2024.
+
+smk-system doesn't get as much use as it used to so is prone to
+bitrot, but it is currently working and says 138802 adjusted. Whilst
+smklengths all added up says 138763, which is pretty close (39m) but
+not exactly the same. That's usually what happens and it takes a bit
+of detective work to find out what's out of whack.
+
+In practice '2' is more useful because when there are discrepancies
+(and in my experience there usually are) it's easier to work out where
+when you do it cave by cave, than when you just have the whole thing
+with an unexplained difference 'somewhere'
+
+There is a script to help with this:
+
+https://expo.survex.com/repositories/loser/.git/tree/docs/smklengths
+
+and also this which just gets the length of any given cave::
+https://expo.survex.com/repositories/loser/.git/tree/docs/cavelength
+either
+./cavelength 258
+or
+./cavelength 359 1626
+to run it on the non-default area (new for last year that feature).
+
+(for all this stuff, if using Windows or MacOS do it in a terminal/Windows-on-Linux console)
+
+> Wookey, how easy is it to generate SMK and non-SMK finds per year?
+
+It's pretty easy to just run smklengths:
+cd loser/docs
+./smklengths
+in a loser checkout for any year.
+
+And you can use the tags to get the 'right' checkouts for each 'the data has been sorted out for the year by now' point:
+post-2017
+post-2023
+etc
+https://expo.survex.com/repositories/loser/.git/refs/
+
+so to get the answer for 2017 you do:
+cd loser
+git checkout post-2017
+cd docs
+./smklengths
+git switch - (to get back from 'detached head' state to whatever you had checked-out before.
+
+
+
+You could do the same thing with immense amounts of pointing and clicking, but it would be very tedious.
+
+I've just done this for current head and updated the smklengths.ods
+sheet for 2024, but that 39m discrepancy needs resolving before it can
+be considered 'final'. Also the ARGE data was never merged for 2023
+(nor 2024 yet) so the length is very likely wrong for that reason
+too.
+
+You can also just run:
+
+cavern smk-system.svx
+
+and compare the difference post-2023 to 'latest' with
+git checkout post-2023
+cavern smk-system.svx
+git switch -
+cavern smk-system.svx
+And see what the difference is.
+
+To get 'a' non-smk length is basically the same, but you need to subtract the smklength numbers you just got above, to get the 'all the other finds' number
+git checkout post-2023
+cavern 1623-and-1626
+git switch -
+cavern 1623-and-1626
+
+
+The script docs/lengthdiff is an old pre-git script to automate this. That could be updated to make this a bit less manual.
+
+The catch with this process is that it won't include any caves which
+have been surveyed but not properly connected into the dataset.
+
+All of this really boils down to the fact that cavern only reports the
+length of a processed dataset, and only when you process it. It's not
+recorded in the .3d file so aven can't show you, nor can it have a
+cumulative tally for all displayed caves. If we had that functionality
+then there would be a relatively painless point-and-click way to get
+current lengths. (You'd still need to check out a historical version
+as well to get _differences_ from one year to the next.
+
+Presumably you are asking this because you think the dataset is 'done'
+for 2024 now? In which case we can check lengths look good, tidy up a
+few things and tag 'post-2024'. We can move that along if we find
+issues later. I should also sort out the ARGE stuff with Thomas.
+
+Hope all that makes sense.
+
+Wookey
+--
+Principal hats: Debian, Wookware
+http://wookware.org/