diff --git a/notes/salt.md b/notes/salt.md
new file mode 100644
index 0000000000000000000000000000000000000000..8d259fabffef8d4a9d41cdfde3cbac41db792828
--- /dev/null
+++ b/notes/salt.md
@@ -0,0 +1,123 @@
+# SALT
+
+"offering atomicity and isolation at the same granularity is the very reason why ACID
+transactions are ill-equipped .....(performance vs programmability)"
+
+**Pareto Principle:** 80% of effects from 20% of causes
+
+-splitting ACID transactions up very good for concurrency
+ - bad for isolation
+- key issue is to provide isolation at a finer granularity, same atomicity
+ - nested transactions give subtrans' atomicity, isolate entire thing
+
+## Background
+
+ANSI iso levels:
+- read-uncommitted
+- read-committed (assumed goal for paper)
+- repeatable read
+- serializable
+
+Issues:
+- dirty writes: overwrite uncomitted
+- dirty reads: read from uncommitted
+- non-repeatable reads
+- phantom
+
+## BASE transactions
+ - **alkaline** subtransactions
+ - no other transactions can see state of *uncommitted alkaline subtrans*
+ - **committed** alk subtrans state viewable by other BASE or alkaline transactions
+ - *not visible* until entire BASE commit.
+ - **salt isolation** allows control of internal states visibility (among other BASE transactions)
+ - each alkaline sub has associated *exception*
+ - *BASE transactions look like ACID transactions to other ACID transactions*
+ - **accepted** once any alkaline trans commits,
+ - accepted implies commit of entire BASE
+ - i.e. all operations successfully executed *or bypassed because of some exception*
+ - aborted only if they encounter an error before the transaction is accepted (unlike ACID)
+
+## Isolation
+
+*"If two operations in different transactions conflict, then the temporal dependency
+ that exists between the earlier and the later of these operations must extend to the
+ entire transaction"* (allows SALT to work w/ different isolation levels)
+
+*Isolation:* Let Q be the set of operation types {read, range-read, write} and let L and S
+be subsets of Q . Further, let o1 in txn1 and o2 in txn2, be two operations, respectively
+of type T1 ∈ L and T2 ∈ S , that access the same object in a conflicting
+(i.e. non read-read) manner. **If o1 completes before o2 starts, then txn1 must decide
+before o2 starts.**
+
+Isolation property holds if at least one is ACID, or both are alkaline.
+
+
+
+
+
+## Salt Isolation
+**Salt Isolation**:
+The Isolation property holds as long as (a) at least one of txn<sub>1</sub> and
+txn<sub>2</sub> is an ACID transaction or (b) both txn<sub>1</sub> and txn<sub>2</sub> are alkaline
+subtransactions.
+
+So:
+- ACID transactions isolated from all other
+- Alkaline subtrans isolated from ACID and other alkaline
+- BASE expose states at alkaline boundaries to other BASE
+
+
+- Design
+ - locks (because high contention)
+ - type
+ - ACID - conflict with alkaline and saline
+ - alkaline - conflict w/ ACID and other alkaline
+ - saline: conflict with ACID locks (except for read/read) only
+ - lock duration
+ - *long term* (life of trans, 2PL)
+ - *short-term* (just the op)
+ - acquire only an alkaline lock at operation start
+ - “downgrade†it to saline at end of subtransaction, hold until after the end of the BASE transaction.
+ - no multi-version concurrency
+
+
+
+## Indirect Dirty Reads
+<p>
+
+
+<p>
+Fixed by:
+
+- **Read-after-write across transactions** A BASE transaction B<sub>r</sub> that reads a value x, which has been written by another BASE<sub>w</sub> transaction, cannot release its saline lock on x until B<sub>w</sub> has released its own saline lock on x.
+
+- **Write-after-read within a transaction** An operation O<sub>w</sub> that writes a value x cannot
+ release its saline lock on x until all previous read operations within the **same** BASE
+ transaction have released their saline locks on their respective objects.
+
+These two ensure uncommitted writes keep locks until all prior read locks also released.
+
+<p>
+
+## Forward Logging
+- after BASE knows it will commit (because a subsaline committed), log entire BASE
+- prevents cascades that would have occurred because of saline visibility
+
+### Banking, again
+
+
+
+
+## Performance
+
+
+
+
+
+
+## Comments
+
+- Kaitlyn - How easy to find the performance-critical transactions? Complicated, better ways to do it?
+- Dhanvee - Really worth it to start w/ Base adn ACID-ifying?
+
+
diff --git a/notes/saltAcidApp.png b/notes/saltAcidApp.png
new file mode 100644
index 0000000000000000000000000000000000000000..22a4423b87329eb2d969e41848395dba6b148cf9
Binary files /dev/null and b/notes/saltAcidApp.png differ
diff --git a/notes/saltBanking.png b/notes/saltBanking.png
new file mode 100644
index 0000000000000000000000000000000000000000..96199dcedf99754c272345557dc9c85782273b5a
Binary files /dev/null and b/notes/saltBanking.png differ
diff --git a/notes/saltConcurrent.png b/notes/saltConcurrent.png
new file mode 100644
index 0000000000000000000000000000000000000000..aa06bb45bf53ea1d8fd8e621f6c563c66f4a11ca
Binary files /dev/null and b/notes/saltConcurrent.png differ
diff --git a/notes/saltFig4.png b/notes/saltFig4.png
new file mode 100644
index 0000000000000000000000000000000000000000..bd7fb5c3529961c93417460b3d0ac32873bef62c
Binary files /dev/null and b/notes/saltFig4.png differ
diff --git a/notes/saltFig5.png b/notes/saltFig5.png
new file mode 100644
index 0000000000000000000000000000000000000000..a4bd6cf9f31a86c2ff40848e526d2d83a6311a9a
Binary files /dev/null and b/notes/saltFig5.png differ
diff --git a/notes/saltLocks.png b/notes/saltLocks.png
new file mode 100644
index 0000000000000000000000000000000000000000..256a75aa929c17dd1f39900570e70dca7060617c
Binary files /dev/null and b/notes/saltLocks.png differ
diff --git a/notes/saltPerf1.png b/notes/saltPerf1.png
new file mode 100644
index 0000000000000000000000000000000000000000..0a96f040b107a7d270c330842b547d4870ec4f1c
Binary files /dev/null and b/notes/saltPerf1.png differ
diff --git a/notes/saltPerf2.png b/notes/saltPerf2.png
new file mode 100644
index 0000000000000000000000000000000000000000..1fc7713001c39b1f793c49a10025859b4abfadd8
Binary files /dev/null and b/notes/saltPerf2.png differ
diff --git a/notes/saltSets.png b/notes/saltSets.png
new file mode 100644
index 0000000000000000000000000000000000000000..54ec59e8a6c9b1c54e20beb81c6041aada40f777
Binary files /dev/null and b/notes/saltSets.png differ
diff --git a/notes/tango.md b/notes/tango.md
new file mode 100644
index 0000000000000000000000000000000000000000..9d72e448ea8cfe979e31dbc001e0ea409ba3fb85
--- /dev/null
+++ b/notes/tango.md
@@ -0,0 +1,64 @@
+# Tango Distributed Data Structures over a Shared Log
+
+## Why?
+Existing systems build abstractions for computing over massive data sets:
+- hadoop
+- Spark
+
+
+Need **"application metadata"**, with *persistence* and *high availability*.
+- maps
+- counters
+- queues
+- graphs
+- job assignments
+- network topologies
+.....
+
+
+## How?
+
+- client modifies object by appending an update to the log
+- accesses the object by sync'ing local view w/ log
+- *elasticity* - scaling throughput of linearizable reads by adding new views,
+ w/o slowing write throughput. ("until saturation")
+- transaction **atomicity** and **isolation** from log
+- *streams* to filter log seen at clients
+
+
+
+## Transactions:
+
+- optimistic concurrency control
+ - writes entered in log as speculative
+ - commit record contains a read set w/ versions.
+ - transaction *succeeds* if read objects current at commit record.
+ - each reader deterministically evaluates commit record
+ - **read transactions**:
+ - nothing inserted in log
+ - locally track time (offset) of first read (start of transaction), and last read (end of transaction)
+ - commit/abort by as in ordinary read/write transactions
+ - write transactions always commit.
+- can use fine-grained per-app versions
+ - opaque key parameters in helper funcs
+- crashed client's transaction aborted by others appending crash record
+
+
+### Streams
+
+- per-object stream
+- transaction commits *multi-appended* to all relevant streams
+- *remote-write* transactions
+- decision records
+- a client executing a transaction must insert a decision record for a transaction if there’s some other client in the system that hosts an object in its write set but not all the objects in its read set. "
+- generating clients can not do a remote read in trans (would require RPCs...)
+
+
+
+### Comments/Questions
+
+- (claude) why metadata?
+
+
+
+
diff --git a/notes/tango1.png b/notes/tango1.png
new file mode 100644
index 0000000000000000000000000000000000000000..3bc2e32ff0af24c8ba0c7a8e0e14fa6ad9e84b76
Binary files /dev/null and b/notes/tango1.png differ
diff --git a/notes/tangoDecisions.png b/notes/tangoDecisions.png
new file mode 100644
index 0000000000000000000000000000000000000000..78388150c3de9e3d2d062d7d86e6bd132112f1e6
Binary files /dev/null and b/notes/tangoDecisions.png differ
diff --git a/notes/tangoTrans.png b/notes/tangoTrans.png
new file mode 100644
index 0000000000000000000000000000000000000000..5611c0e3df27337ff1959bc4b62bca880c0394dd
Binary files /dev/null and b/notes/tangoTrans.png differ