diff --git a/notes/hat.md b/notes/hat.md
index a3675a9d928fa3d903c59e7cc19db3613b9a3e4c..702e3ce7a5832924f56d6fae865d1854f03e56cf 100644
--- a/notes/hat.md
+++ b/notes/hat.md
@@ -11,30 +11,29 @@ Correctness anomalies
     - 1SR “one-copy serializability”
         - any read will return the most recent write to that data item, regardless of which replicas are read or written
         - doesn’t fix all problems
-    - 
     
 ## The Anomalies
 
-the immortal write -
+*the immortal write* -
 
 ![](https://paper-attachments.dropbox.com/s_9C40D1E627431C359DFC050423F865DB110CEF11D9FA101F15E75C20CDD3C4D3_1639005186338_image.png)
 
 - tempting to leverage time travel to create an immortal blind write, which enables strightforward conflict resolution without violating the serializability guarantee
 
-the stale read
+*the stale read* -
 
 ![](https://paper-attachments.dropbox.com/s_9C40D1E627431C359DFC050423F865DB110CEF11D9FA101F15E75C20CDD3C4D3_1639005248966_image.png)
 
 - in single-server system little incentive to read older versions
 - in distributed system, most recent version costs latency
 
-the causal reverse
+*the causal reverse* -
 
 ![](https://paper-attachments.dropbox.com/s_9C40D1E627431C359DFC050423F865DB110CEF11D9FA101F15E75C20CDD3C4D3_1639023882254_image.png)
 
 - serialization order doesn’t respect potential causality of non-conflicting writes (to different data, for example)
 
-SumUp
+### SumUp
 
 - all can occur in 1SR
 - none occur w/ strict serializability,
@@ -43,14 +42,13 @@ SumUp
 
 
 # Highly Available
-
 ```
  authors: Peter Bailis, Alan Fekete, Ali Ghodsi, Joseph M. Hellerstein, Ion Stoica
     title: "HAT, not CAP: Towards Highly Available Transactions"
     where: HotOS 2013
 ```
 
-### Definitions, in the context of Partitions:
+### Definitions
 
 - **high availability:**
   - each user that can contact a non-failing server eventually receives
@@ -72,7 +70,7 @@ SumUp
 ```
 Read should not ever return '1', and shouldn't return '3' if T2 aborts
 
-"**dirty writes**"
+- "**dirty writes**"
 A *dirty write* occurs when one transaction overwrites a value that has previously been
 written by another still in-flight transaction. Why bad? Could violate consistency
 guarantees. Assume invariant *x == y*:
@@ -100,7 +98,7 @@ Both preserve consistency in isolation, but not w/ this schedule and dirty write
 - impl both w/ buffering
 
 ----
-### Unachievable isolation levels
+### Unachievable isolation levels with partitions:
 - snapshot isolation,
   - read from consistent cut
   - commit only if items from writeset not committed by another T since snapshot
@@ -130,7 +128,7 @@ violation of consistency, such as "x == y""
      T1: t = x;  y = t
      T2: t = y;  x = t
 ```
-Can happen w/ snapshot isolation.
+Can happen w/ snapshot isolation even w/o partitions.
 
 - Serializability:
   - optimistic requires global validation
@@ -148,6 +146,11 @@ Can happen w/ snapshot isolation.
 
 ### HAT-compliant:
 
-![pic](hat.png)
+![pic](hat1.png)
+
+### Partial ordering
+![pic](hat2.png)
 
+- Blue is sticky available
+- Red is unavailable
 ----
diff --git a/notes/hat1.png b/notes/hat1.png
new file mode 100644
index 0000000000000000000000000000000000000000..a02445922a4bf2b2a67b998e200b6de3b0d8c3c8
Binary files /dev/null and b/notes/hat1.png differ
diff --git a/notes/hat2.png b/notes/hat2.png
new file mode 100644
index 0000000000000000000000000000000000000000..d2910bf93c653452127ad624a1614cc3385b5620
Binary files /dev/null and b/notes/hat2.png differ