diff --git a/client-webserver/REDIS b/client-webserver/REDIS
new file mode 100644
index 000000000..9699276c0
--- /dev/null
+++ b/client-webserver/REDIS
@@ -0,0 +1,64 @@
+Database structure and procedures for the CA server
+===================================================
+
+This is information about how sessions and their progress are
+represented inside the Redis database and what daemons should do
+to advance the progress of a session.
+
+Note that all values in Redis are normally stored as strings,
+so references to "int" mean that the value in the database should
+be INTERPRETED as an integer, not that it is natively stored as
+one.
+
+
+Sessions:
+---------
+
+hash:  sessionid, "created" → int
+       sessionid, "live" → "True", "False"
+       sessionid, "csr" → str
+       sessionid, "state" → str
+       sessionid, "challenges → int
+
+list: session:names → str
+
+
+Challenges:
+-----------
+
+hash: sessionid:n, "challtime" → int
+      sessionid:n, "type" → int
+      sessionid:n, "name" → str
+      sessionid:n, "satisfied" → "True","False"
+      sessionid:n, "failed" → "True","False"
+      sessionid:n, "data" → str                   # This is problematic.
+
+
+Queues:
+-------
+
+list: active-requests
+list: pending-makechallenge
+list: pending-testchallenge
+list: pending-issue
+list: pending-done
+
+
+Daemons should FIRST pop sessions from a queue (and check whether the
+thing that was pending has already been done?); then do the thing that
+was pending; then change the session's state to the next state; then
+push the session ID onto the next queue.
+
+If the server crashes, then upon reinitalization the server can go
+through everything in active-requests and push it onto the appropriate
+pending-whatever queue for its state if it isn't already in that queue.
+
+How do sessions get removed from the pending-done queue?  (The server
+can tell when it's told a client about a certificate issuance, but not
+whether the client has received the good news.)  Do we need to have
+clients send a "thanks" message to let the server know that they've
+received the cert?  This could still lead to cases where the client has
+received a cert but the CA never finds out about it because the client
+crashes or goes offline afterward.  However, without the acknowledgement
+we could have the opposite problem (the client hasn't gotten a cert, but
+the CA thinks it has).