diff --git a/handbook/l/life-wallet.html b/handbook/l/life-wallet.html
index a7d2dde6b..57d15f475 100644
--- a/handbook/l/life-wallet.html
+++ b/handbook/l/life-wallet.html
@@ -13,10 +13,16 @@ CUCC Expo Handbook: Wallet Process UML Diagrams
 <div class="centre">
 <img alt="wallet process lifecycle diagram" src="../i/life-wallet.jpg"  /></div>
 
-<p>This diagram was created online using the free software at <a href="https://app.creately.com/diagram/4nGSj2FkKGg/edit">https://app.creately.com/</a>
+<p>This "activity" diagram was created online using the free software at <a href="https://app.creately.com/diagram/4nGSj2FkKGg/edit">https://app.creately.com/</a>
 
 <p>
 You can edit your own version to revise this when it becomes outdated.
+
+<p>We also have a "<a href="seq-wallet.html">sequence diagram</a> which shows clearly the sequence of wallet actions in a time-line.
+
+<p>Both "activity" and "sequence" diagrams are part of the UML software specifiction system. We also have a "<a href="trogclass-1.html">class</a>" diagram for troggle.
+That page also defines the "essential", "specification" and "implementation" levels at which troggle is designed and maintained.
+
 <p>
 Statcharts are a standard diagram in the analysis of complex systems. 
 They are  used by the more professional analysts when planning a new software system. They are not quite the same thing as a finite state machine:
@@ -26,8 +32,8 @@ They are  used by the more professional analysts when planning a new software sy
 <li><a href="https://en.wikipedia.org/wiki/UML_state_machine">wikipedia.org/wiki/UML_state_machine</a>
 </ul>
 <p><em>"The Statechart diagram is one of the five UML diagrams used to model the dynamic nature of a system. They define different states of an object during its lifetime and these states are changed by events. Statechart diagrams are useful to model the reactive systems. Reactive systems can be defined as a system that responds to external or internal events.</em>
-<p>They were devised by David Harel, Weizmann Instiutute, in his paper: <a href="https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf">STATECHARTS: A VISUAL FORMALISM FOR
-COMPLEX SYSTEMS</a> Science of Computer Programming 8 (1987) 231-274.
+<p>They were devised by David Harel, Weizmann Instiutute, in his paper: <a href="https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf">Statecharts: A Visual Formalism For Complex Systems</a> Science of Computer Programming 8 (1987) 231-274.
+Or for a quicker cheat-sheet, see <a href="https://instadeq.com/blog/posts/paper-didnt-read-statecharts-a-visual-formalism-for-complex-systems/">Paper; Didn't Read - Statecharts</a>
 <!--
 Wallet Lifecycle Statechart
 # Philip Sargent 20 May 2020
diff --git a/handbook/l/seq-wallet.html b/handbook/l/seq-wallet.html
index 9dd474a42..42957aa95 100644
--- a/handbook/l/seq-wallet.html
+++ b/handbook/l/seq-wallet.html
@@ -21,6 +21,12 @@ CUCC Expo Handbook: Wallet Process UML Diagrams
 <li><a href="https://www.tutorialspoint.com/uml/uml_interaction_diagram.htm">Sequence and Collaboration Diagrams</a>
 <li><a href="https://www.guru99.com/interaction-collaboration-sequence-diagrams-examples.html">Interaction, Collaboration, Sequence Diagrams</a>
 </ul>
+<p>We also have a "<a href="life-wallet.html">activity</a>" lifecycle diagram which shows clearly the states which a wallet can be in during its life.
+
+<p>Both "activity" and "sequence" diagrams are part of the UML software specifiction system. We also have a "<a href="trogclass-1.html">class</a>" diagram for troggle.
+That page also defines the "essential", "specification" and "implementation" levels at which troggle is designed and maintained.
+
+<h3>This diagram</h3>
 <p>This diagram was created online using the free software at <a href="https://www.websequencediagrams.com/">www.websequencediagrams.com/</a>.
 <p>
 You can edit your own version to revise this when it becomes outdated. <br>This is the entire source code that generates the diagram:
diff --git a/handbook/l/trogclass-1.html b/handbook/l/trogclass-1.html
index b838b83fd..dbfd54e07 100644
--- a/handbook/l/trogclass-1.html
+++ b/handbook/l/trogclass-1.html
@@ -21,8 +21,10 @@
 <p>So <strong>a survex (SVX) file</strong> is dated to a particular day during the expedition and usually has between 1 and 3 people associated with it.
 <p>A <strong>Logbook entry</strong> has several people involved and may relate to a cave. It will be dated to a day during the expedition.
 
+<p>Although the volume of data in troggle is small, the complexity is significantly intricate that "modern" (i.e. from the mid 1990s) system design tools are compact and useful.
+
 <h3>Design Diagrams</h3>
-<p>Analysis of expo and design of troggle is done using three levels:
+<p>Analysis of expo and design of troggle is done using <a href="#cookanddaniels">three levels</a>:
 <style>
 li {padding-left: 0;margin-left: 0;line-height:160%;}
 ul, ol {padding-inline-start: 1em;}
@@ -35,9 +37,13 @@ ul, ol {padding-inline-start: 1em;}
 <p>As anyone reading this has probably been on expo and you might think that we can skip the <strong>real-world level</strong>. Not so: the multiplicities (the number of participants in the association) of the relationships between the different cave survey artefacts can be surprising.
 <p>The <strong>specification level</strong> is where the action is. 
 This is where we decide which aspects of the real world <em>we will ignore</em> and what <em>extra concepts</em> we need to make things work. 
-<p>So we ignore who is resident at top-camp (even though today we record this religiously because of the tax implications for the GastHof at base). We do need to track the in-computer associations between survex files: the *include tree, what directories they live in, what wallet-directory they relate to, and all the individual survex blocks of survey measurements within each survex file.
+<p>So <em>we ignore</em> who is resident at top-camp (even though today we record this religiously because of the tax implications for the GastHof at base). We <em>do</em> need to track the in-computer associations between survex files: the <var>*include</var> tree, what directories they live in, what wallet-directory they relate to, and all the individual survex blocks of survey measurements within each survex file.
+
+<p>We only need <strong>implementation-level</strong> diagrams for tiny, tricky issues. Python is very clear so serves as its own implementation specification. However Django does need some explanation even to a competent python programmer if they have not used it before.
+
+<p>For a fundamental background to system specification the classic work of <a href="http://www.syntropy.co.uk/syntropy/designing-object-systems.pdf">Cook and Daniels</a> (online PDF, 400 pages) cannot easily be improved upon (start reading at page 10, second paragraph).
+
 
-<p>We only need <strong>implementation-level</strong> diagrams for tiny, tricky issues. Python is very clear so serves as its own implementation specification. However Django does need some explanation.
 <h3>Class Diagrams</h3>
 <p>A Class Diagram is one the the basic types of structural diagram (as opposed to behavioral diagrams) used to understand complex systems.
 <ul>
@@ -45,11 +51,16 @@ This is where we decide which aspects of the real world <em>we will ignore</em>
 <li><a href="https://www.tutorialspoint.com/uml/uml_class_diagram.htm">UML - Class Diagram</a>
 </ul>
 <p>
-The purpose of class diagram is to model the static view of an application. 
+The purpose of class diagram is to model the static view of an application: the unchanging structure.
 
+<h3>Other UML Diagrams documenting Expo systems</h3>
+<p>Class diagrams describe structure, but there are useful diagrams that describe <em>behaviour</em> too. Not much of our process is complicated enough to need them though.
+<p>The <a href="life-wallet.html">wallet lifecycle</a> is a "<a href="https://en.wikipedia.org/wiki/Interaction_overview_diagram">interaction</a>" diagram showing the states and transitions between the states for a plastic wallet holding original caving notes and the software equivalent directory. The <a href="seq-wallet">wallet process</a> is a "<a href="https://en.wikipedia.org/wiki/Sequence_diagram">sequence</a>" diagram showing which actors (people) interact with a wallet during its lifecycle: inserting pages from the waterproof notebook, taking the notes and sketches and scanning the, processing the survey data to produce centreline plots etc.
+<p>The hand-drawn sketch title "Packages" on the <a href="../troggle/trogarch.html">troggle architecture</a> page is a UML "deployment" diagram.
+<p>See <a href="https://www.martinfowler.com/tags/uml.html">Fowlers pages on UML</a> for more examples of UML in use.
 
 <h3>Online free class diagram editor</h3>
-<p>This diagram was created online using the YUML free software at <a href="https://yuml.me/mkay2100/edit/Troggle-1">https://yuml.me//</a>.
+<p>The Class diagram on this page was created online using the YUML free software at <a href="https://yuml.me/mkay2100/edit/Troggle-1">https://yuml.me//</a>.
 <p>
 You can edit your own version to revise this when it becomes outdated. <br>This is the entire source code that generates the diagram:
 <pre><code style ="font-size:x-small">
@@ -91,7 +102,47 @@ You can edit your own version to revise this when it becomes outdated. <br>This
 [PersonExpedition{bg:yellowgreen}]
 
 </code></pre>
-
+<h3 id="cookanddaniels">Cook & Daniels - Three Levels</h3>
+<p>From <a href="http://www.syntropy.co.uk/syntropy/designing-object-systems.pdf">Cook and Daniels</a> (online PDF, 400 pages, pp10-11):
+<div style="text-align: left; font-size: smaller; margin-left: 7%; margin-right:15%">
+<p>
+"In this book we present three kinds of object-oriented model. The first kind, which
+we call <em>the essential model</em>, considers the model to be a description of some real or
+imaginary situation, which may or may not contain software. We use the word
+situation rather than system because ‘system’ has so many possible meanings including
+the software we may be trying to build, and rather than world to emphasise that we are
+considering purposeful systems situated in a context rather than trying to describe all of
+some supposedly objective reality. <em>The purpose of building the essential model is to
+understand and establish the facts about this situation.</em> The building blocks which we
+use to build essential models are objects (actually object types) and events (actually
+event types). An essential model is built by drawing annotated diagrams, and
+interpreted as descriptions of sets, functions and sequences with meanings in the
+situation being described.
+<p>
+In the second kind of model, called <em>the specification model</em>, we are concerned with
+specifying software. To create a specification model it is necessary to establish <em>which
+parts of the overall situation will be implemented in software</em>. In some cases this might
+be a large part of the situation, whereas in others it might not be a part at all. The
+activity of specifying exactly what is to be implemented in software is quite different
+from the activity of establishing the facts about the overall situation; however both of
+these activities would conventionally fall under the heading of ‘analysis’. Like
+essential models, specification models deal with objects and events and are built by
+drawing annotated diagrams. They are interpreted as a description of the abstract
+stimulus–response behaviour of the software. The specification model describes
+software at a high level of abstraction, and in particular says nothing about internal
+sequencing or concurrency. An important part of building a specification model is the
+allocation among object types of responsibility for aspects of software behaviour.
+<p>
+The third kind of model, <em>the implementation model</em>, is concerned with establishing
+patterns of control flow within the software. In this model we take into account the
+fact that computer programs have a limited number of well-defined flows of control,
+which execute at a finite speed. The building blocks for implementation models are
+objects and messages. Object interactions are described as messages sent from one
+object to another, and the implementation model describes message sequencing and
+concurrency control. Annotated diagrams are used again, although in the 
+implementation model our repertoire of diagrams is richer than for the other kinds of
+model."
+</div>
 <hr />
 </body>
 </html>
\ No newline at end of file
diff --git a/handbook/troggle/trogarch.html b/handbook/troggle/trogarch.html
index 8581453bd..954951ee6 100644
--- a/handbook/troggle/trogarch.html
+++ b/handbook/troggle/trogarch.html
@@ -55,7 +55,7 @@ See the <a href="https://docs.djangoproject.com/en/3.0/misc/design-philosophies/
 <h3>Troggle parsers and input files</h3>
 <div class="onright">
 <figure>
-<a href="https://djangobook.com/mdj2-django-structure/"><img src="mtv_drawing2.jpg"></a>
+<a href="https://djangobook.com/mdj2-django-structure/"><img src="../i/mtv_drawing2.jpg"></a>
 <br><figcaption>Django server and webpage (client)</figcaption>
 </figure>
 </div>