Add ADR for iiif indexing

Co-authored-by: Trey Pendragon <tpendragon@princeton.edu>

architecture-decisions/0003-synchronization-via-rabbitmq.md

@@ -18,6 +18,11 @@ Figgy will send create/update/delete messages to a fanout RabbitMQ Exchange.
 Pomegranate will register a durable queue which listens to that exchange and
 process messages using [Sneakers](https://github.com/jondot/sneakers).
 
+The message will contain the following information:
+ * Collection slugs the object is a member of
+ * Manifest URL of the object
+ * change event (create / update / delete)
+
 ## Consequences
 
 * If Sneakers workers stop processing, then new documents don't make it in to

architecture-decisions/0004-index-from-iiif-manifests.md

@@ -0,0 +1,33 @@
+# 4. Indexing from IIIF Manifests
+
+Date: Archaeological
+
+## Status
+
+Accepted
+
+## Context
+
+Objects in Pomegranate need to get their metadata from Figgy, where they are
+administered. Spotlight ships with a IIIF-based indexer. Figgy already produces
+IIIF manifests to support viewing the objects. However the metadata bucket
+doesn't contain rich enough metadata for pomegranate use cases.
+
+Figgy (plum, at the time) didn't have an API at the time this decision was made. Manifests were the
+only way to get data out. Today Figgy has a graphql API.
+
+## Decision
+
+We will use the IIIF Manifests to pull data from Figgy into Pomegranate. The
+Manifest gives us the manifest url (used for presenting a viewer), the thumbnail
+iiif image url, and the jsonld metadata location (via seeAlso).
+
+## Consequences
+
+* We have to do multiple queries for each index action.
+
+* Efficiency of synchronization is bound to the efficiency of generating
+  manifests
+
+* Access authorization must be negotiated via headers, where an API might be more
+  straightforward.