diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 997cf3b..0e3e635 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -87,15 +87,6 @@
# Specifications and Theory
- [Overview](./theory/index.md)
-
-- [Syndicated Actor Model]()
- - [Actors, Entities, Assertions and Messages]()
- - [Dataspaces]()
- - [Object-capabilities]()
- - [Privilege separation]()
- - [Attenuation of authority for security]()
- - [Attenuation of authority for privacy]()
-
+- [Syndicated Actor Model](./syndicated-actor-model.md)
- [Protocol specification](./protocol.md)
-
- [System layer analysis]()
diff --git a/src/syndicated-actor-model.md b/src/syndicated-actor-model.md
new file mode 100644
index 0000000..5e88962
--- /dev/null
+++ b/src/syndicated-actor-model.md
@@ -0,0 +1,490 @@
+# Syndicated Actor Model
+
+The Syndicated Actor Model (SAM) [[Garnock-Jones 2017][]] is an approach to concurrency based
+on the *Communicating Event-Loop Actor Model* [[De Koster et al 2016][]] as pioneered by E
+[[Miller 2006][]] and AmbientTalk [[Van Cutsem et al 2007][]].
+
+While other Actor-like models take message-passing as fundamental, the SAM builds on a
+different underlying primitive: *eventually-consistent replication of state* among actors.
+Message-passing follows as a derived operation.
+
+This fundamental difference integrates Tuplespace- [[Gelernter and Carriero 1992][]] and
+publish/subscribe-like ideas with concurrent object-oriented programming, and makes the SAM
+well-suited for building programs and systems that are reactive, robust to change, and graceful
+in the face of partial failure.
+
+**Outline.** This document first describes the primitives of SAM interaction, and then briefly
+illustrates their application to distributed state management and handling of partial failure.
+It goes on to present the idea of a *dataspace*, an integration of Tuplespace- and
+publish/subscribe-like ideas with the SAM. Finally, it discusses the SAM's generalization of
+*object capabilities* to allow for control not only over invocation of object behaviour but
+subscription to object state.
+
+Throughout, we will limit discussion to interaction among actors connected directly to one
+another: that is, to interaction within a single scope. Scopes can be treated as "subnets" and
+connected together: see the [Syndicate protocol specification](./protocol.md).
+
+For more on the SAM, on the concept of "conversational concurrency" that the model is a
+response to, and on other aspects of the larger project that the SAM is a part of, please see
+ and Garnock-Jones' [2017 dissertation][Garnock-Jones 2017].
+
+## Concepts and components of SAM interaction
+
+A number of inter-related ideas must be taken together to make sense of SAM interaction. This
+section will outline the essentials.
+
+For core concepts of Actor models generally, see De Koster *et al.*'s outstanding [2016 survey
+paper][De Koster et al 2016], which lays out a taxonomy of Actor systems as well as introducing
+solid definitions for terms such as "actor", "message", and so on.
+
+### Actors, Entities, Assertions and Messages
+
+The SAM is based around actors which not only exchange messages, but publish ("assert")
+selected portions of their internal state ("assertions") to their peers in a publish/subscribe,
+reactive manner. Assertions and messages in the SAM are [semi-structured
+data](https://en.wikipedia.org/wiki/Semi-structured_data): their structure allows for
+pattern-matching and [content-based
+routing](https://www.enterpriseintegrationpatterns.com/ContentBasedRouter.html).
+
+Assertions are published and withdrawn freely throughout each actor's lifetime. When an actor
+terminates, all its published assertions are automatically withdrawn. This holds for both
+normal and exceptional termination: crashing actors are cleaned up, too.
+
+An actor in the SAM comprises
+
+ - an *inbox*, for receiving events from peers;
+ - a *state*, "all the state that is synchronously accessible by that actor" ([De Koster et al 2016][]);
+ - a collection of *entities*; and
+ - a collection of *outbound assertions*, the data to be automatically retracted upon actor termination.
+
+The term "entity" in the SAM denotes a reactive object, owned by a specific
+actor.[^terminology-vs-e] Entities, not actors, are the unit of addressing in the SAM. Every
+published assertion and every sent message is targeted at some entity. Entities never outlive
+their actors—when an actor terminates, its entities become unresponsive—but may have lifetimes
+shorter than their owning actors.
+
+Local interactions, among objects (entities) within the state of the same actor, occur
+synchronously. All other interactions are considered "remote", and occur asynchronously.
+
+**"Message" as a derived concept.** A minimal theoretical Syndicated Actor Model includes
+*only* assertion publication and retraction. Message transmission is excluded because,
+theoretically, it can be *defined* as a "brief" assertion of the message body; that is, as an
+assertion, followed "almost immediately" by a matching retraction. This naturally captures a
+number of interesting properties of messages, including potential message loss and corruption
+as well as issues related to medium access control. While it is useful theoretically to view
+message exchange as a pattern (in the "software design pattern" sense) of assertion usage, the
+pattern is so common in practical programming that the SAM and its implementations include
+integrated support for messages as standard.[^analogy-with-function-call]
+
+### Turns
+
+Each time an event arrives at an actor's inbox, the actor takes a *turn*. [De Koster *et
+al.*][De Koster et al 2016] define turns as follows:
+
+> A turn is defined as the processing of a single message by an actor. In other words, a turn
+> defines the process of an actor taking a message from its inbox and processing that message
+> to completion.
+
+In the SAM, a turn comprises
+
+ - the *event* that triggers the turn and the *entity* addressed by the event,
+ - the entity's *execution* of its response to the event, and
+ - the collection of pending *actions* produced during execution.
+
+If a turn proceeds to completion without an exception or other crash, its pending actions are
+delivered to their target entities/actors. If, on the other hand, the turn is aborted for some
+reason, its pending actions are discarded. This transactional "commit" or "rollback" of a turn
+is familiar from other event-loop-style models such as Ken [[Yoo et al 2012][]].
+
+### Events and Actions
+
+SAM *events* convey a new assertion, retraction of a previously-established assertion, delivery
+of a message, or a request for synchronisation.
+
+In response to an event, an actor (entity) schedules *actions* to be performed at the end of
+the turn. Actions include not only publication and retraction of assertions, transmission of
+messages, and issuing of synchronisaton requests, but also termination of the running actor and
+creation of new actors to run alongside the running actor.
+
+### Entity References are Object Capabilities
+
+As mentioned above, entities are the unit of addressing in the SAM. Assertions and message
+bodies may include *references* to entities. Actors receiving such references may then use them
+as targets for later assertions and messages. Entity references act as [*object
+capabilities*](https://en.wikipedia.org/wiki/Object-capability_model), very similar to those
+offered by E [[Miller 2006][]].
+
+Entity references play many roles in SAM interactions, but two are of particular importance.
+First, entity references are used to simulate *functions* and *continuations* for encoding
+remote procedure calls (RPCs). Second, entity references can act like *consumers* or
+*subscribers*, receiving asynchronous notifications about state changes from peers.
+
+## Illustrative Examples
+
+To show some of the potential of the SAM, we will explore two representative examples: a
+distributed spreadsheet, and a cellular modem server.
+
+### Spreadsheet cell
+
+Imagine a collection of actors representing portions of a spreadsheet, each containing entities
+representing spreadsheet cells. Each cell entity publishes public aspects of its state to
+interested peers: namely, its current value. It also responds to messages instructing it to
+update its formula. In pseudocode:
+
+ ` 1:`**define entity** Cell(*formula*):
+ ` 2:` *subscribers* ← ∅
+ ` 3:` **on** assertion from a peer of interest in our value,
+ ` 4:` add *peer*, the entity reference carried in the assertion of interest, to *subscribers*
+ ` 5:` **on** retraction of previously-expressed interest from some *peer*,
+ ` 6:` remove *peer* from *subscribers*
+ ` 7:` **assert** subscriptions to other Cells (using entity references in *formula*)
+ ` 8:` **on** message conveying a new formula,
+ ` 9:` *formula* ← *newFormula*
+ `10:` **replace** subscription assertions using references in new *formula*
+ `11:` **on** assertion conveying updated contents relevant to *formula*,
+ `12:` *value* ← eval(*formula*)
+ `13:` **continuously**, whenever *value* or *subscribers* changes,
+ `14:` **assert** the contents of *value* to every peer in *subscribers*,
+ `15:` **retract**ing previously-asserted values
+
+Much of the subscription-management behaviour of Cell is generic: lines 2–6 managing the
+*subscribers* set and lines 13–14 iterating over it will be common to any entity wishing to
+allow observers to track portions of its state. This observation leads to the factoring-out of
+*dataspaces*, introduced below.
+
+### Cellular modem server
+
+Imagine an actor implementing a simple driver for a cellular modem, that accepts requests (as
+Hayes modem command strings) paired with *continuations* represented as entity references. Any
+responses the modem sends in reply to a command string are delivered to the continuation entity
+as a SAM message.
+
+ ` 1:`**define entity** Server():
+ ` 2:` **on** assertion Request(*commandString*, *replyEntity*)
+ ` 3:` output *commandString* via modem serial port
+ ` 4:` collect response(s) from modem serial port
+ ` 5:` **send** response(s) as a message to *replyEntity*
+
+ ` 6:`**define entity** Client(*serverRef*):
+ ` 7:` **define entity** *k*:
+ ` 8:` **on** message containing responses,
+ ` 9:` **retract** the Request assertion
+ `10:` (and continue with other tasks)
+ `11:` **assert** Request(`"AT+CMGS=..."`, *k*) to *serverRef*
+
+This is almost a standard continuation-passing style encoding of remote procedure
+call.[^rpc-sam-discussion] However, there is one important difference: the request is sent to
+the remote object not as a message, but as an *assertion*. Assertions, unlike messages, have a
+*lifetime* and so can act to set up a [conversational
+frame](https://syndicate-lang.org/tonyg-dissertation/html/#x_2_2_0_0_1) within which further
+interaction can take place.
+
+Here, subsequent interaction appears at first glance to be limited to transmission of a
+response message to *replyEntity*. But what if the Server were to crash before sending a
+response?
+
+Erlang [[Armstrong 2003][]] pioneered the use of "links" and "monitors" to detect failure of a
+remote peer during an interaction; "broken promises" and a suite of special system messages
+such as `__whenBroken` and `__reactToLostClient` [[Miller 2006][], chapter 17] do the same for
+E. The SAM instead uses *retraction of previous assertions* to signal failure.
+
+To see how this works, we must step away from the pseudocode above and examine the context
+where *serverRef* is discovered for eventual use with Client. In the case that an assertion,
+rather than a message, conveys *serverRef* to the client actor, then when Server *crashes*, the
+assertion conveying *serverRef* is automatically retracted. The client actor, interpreting this
+as failure, can choose to respond appropriately.
+
+The ubiquity of these patterns of service discovery and failure signalling also contributed,
+along with the patterns of generic publisher/subscriber state management mentioned above, to
+the factoring-out of dataspaces.
+
+## Dataspaces
+
+A special kind of syndicated actor entity, a *dataspace*, routes and replicates published data
+according to actors' interests.
+
+ ` 1:`**define entity** Dataspace():
+ ` 2:` *allAssertions* ← ∅
+ ` 3:` *allSubscribers* ← ∅
+ ` 4:` **on** assertion of semi-structured datum *a*,
+ ` 5:` add *a* to *allAssertions*
+ ` 6:` if *a* matches Observe(*pattern*, *subscriberRef*),
+ ` 7:` add (*pattern*, *subscriberRef*) to *allSubscribers*
+ ` 8:` for *x* in *allAssertions*, if *x* matches *pattern*,
+ ` 9:` **assert** *x* at *subscriberRef*
+ `10:` otherwise,
+ `11:` for (*p*, *s*) in *allSubscribers*, if *a* matches *p*,
+ `12:` **assert** *a* at *s*
+ `13:` **on** retraction of previously-asserted *a*,
+ `14:` retract *a* from all subscribers to whom it was forwarded
+ `15:` remove *a* from *allAssertions*
+ `16:` if *a* matches Observe(*pattern*, *subscriberRef*),
+ `17:` remove (*pattern*, *subscriberRef*) from *allSubscribers*
+ `18:` retract all assertions previously sent to *subscriberRef*
+
+Assertions sent to a dataspace are routed by pattern-matching. Subscriptions—tuples associating
+a pattern with a subscriber entity—are placed in the dataspace as assertions like any other.
+
+A dataspace entity behaves very similarly to a tuplespace [[Gelernter and Carriero 1992][]].
+One key difference is that tuples in a tuplespace are "generative" [[Gelernter 1985][]], taking
+on independent existence once created and potentially remaining in a tuplespace indefinitely;
+SAM assertions, by contrast, never outlive their asserting actors.
+
+Assertions placed at a dataspace only exist as long as they are actively maintained: if an
+actor terminates or crashes, *all* its assertions are withdrawn, including those targeted at a
+dataspace entity. The dataspace, following its definition, forwards all withdrawals on to
+interested subscribers.
+
+### Applications of dataspaces
+
+Dataspaces have many uses. They are ubiquitous in SAM programs. The form of state replication
+embodied in dataspaces subsumes Erlang-style links and monitors, publish/subscribe,
+tuplespaces, presence notifications, directory/naming services, and so on.
+
+#### Subscription management
+
+The very essence of a dataspace entity is subscription management. Entities wishing to manage
+collections of subscribers can cooperate with dataspaces: they may either manage a private
+dataspace entity, or share a dataspace with other entities. For example, in the spreadsheet
+cell example above, each cell could use its own private dataspace, or all cells could share a
+dataspace by embedding their values in a record alongside some name for the cell.
+
+#### Service directory and service discovery
+
+Assertions placed at a dataspace may include entity references. This makes a dataspace an ideal
+implementation of a service directory. Services advertise their existence by asserting *service
+presence* [[Konieczny et al 2009][]] records including their names alongside relevant entity
+references:
+
+ Service(`"name"`, *serviceRef*)
+
+Clients discover services by asserting *interest* in such records using patterns:
+
+ Observe(⌜Service(`"name"`, _)⌝, *clientRef*)
+
+Whenever some matching Service record has been asserted by a server, the dataspace asserts the
+corresponding record to *clientRef*. (The real dataspace pattern language includes *binding*,
+not discussed here; see [TODO].)
+
+#### Failure signalling
+
+Since assertions of service presence are withdrawn on failure, and withdrawals are propagated
+to interested subscribers, service clients like *clientRef* above will be automatically
+notified whenever *serviceRef* goes out of service. The same principle can also be applied in
+other similar settings.
+
+#### Independence from service identity
+
+There's no need to separate service discovery from service interaction. A client may assert its
+request directly at the dataspace; a service may subscribe to requests in the same direct way:
+
+ `(client:)` ServiceRequest(`"name'`, *arg1*, *arg2*, ..., *replyRef*)
+ `(server:)` Observe(⌜ServiceRequest(`"name'`, *?a*, *?b*, ..., *?k*)⌝, *serviceRef*)
+
+In fact, there are benefits to doing things this way. If the service should crash
+mid-transaction, then when it restarts, the incomplete ServiceRequest record will remain, and
+it can pick up where it left off. The client has become decoupled from the specific identity of
+the service provider, allowing flexibility that wasn't available before.
+
+#### Asserting interest in assertions of interest
+
+Subscriptions at a dataspace are assertions like any other. This opens up the possibility of
+subscribing to *subscriptions*:
+
+ Observe(⌜Observe(⌜...⌝, _)⌝, *r*)
+
+This allows dataspace subscribers to express interest in *which other subscribers are present*.
+
+In many cases, explicit assertion of presence (via, e.g., the Service records above) is the
+right thing to do, but from time to time it can make sense for clients to treat the presence of
+some subscriber interested in their requests as sufficient indication of service presence to go
+ahead.[^background-on-interests]
+
+## Illustrative Examples revisited
+
+Now that we have Dataspaces in our toolbelt, let's revisit the spreadsheet cell and cellular
+modem examples from above.
+
+### Spreadsheet cell with a dataspace
+
+ ` 1:`**define entity** Cell(*dataspaceRef*, *name*, *formula*):
+ ` 2:` **continuously**, whenever *value* changes,
+ ` 3:` **assert** CellValue(*name*, *value*) to *dataspaceRef*
+ ` 4:` **continuously**, whenever *formula* changes,
+ ` 5:` for each name *n* in *formula*,
+ ` 6:` define entity *k*:
+ ` 7:` **on** assertion of *nValue*,
+ ` 8:` *value* ← (re)evaluation based on *formula*, *nValue*, and other *nValue*s
+ ` 9:` **assert** Observe(⌜CellValue(*n*, *?nValue*)⌝, *k*) to *dataspaceRef*
+ `10:` **on** message conveying a new formula,
+ `11:` *formula* ← *newFormula*
+
+The cell is able to outsource all subscription management to the *dataspaceRef* it is given.
+Its behaviour function is looking much closer to an abstract prose specification of a
+spreadsheet cell.
+
+### Cellular modem server with a dataspace
+
+There are many ways to implement RPC using dataspaces,[^rpc-sam-discussion] each with different
+characteristics. This implementation uses anonymous service instances, implicit service names,
+asserted requests, and message-based responses:
+
+ ` 1:`**define entity** Server(*dataspaceRef*):
+ ` 2:` **define entity** *serviceRef*:
+ ` 3:` **on** assertion of *commandString* and *replyEntity*
+ ` 4:` output *commandString* via modem serial port
+ ` 5:` collect response(s) from modem serial port
+ ` 6:` **send** response(s) as a message to *replyEntity*
+ ` 7:` **assert** Observe(⌜Request(*?commandString*, *?replyEntity*)⌝, *serviceRef*) to *dataspaceRef*
+
+ ` 8:`**define entity** Client(*dataspaceRef*):
+ ` 9:` **define entity** *k*:
+ `10:` **on** message containing responses,
+ `11:` **retract** the Request assertion
+ `12:` (and continue with other tasks)
+ `13:` **assert** Request(`"AT+CMGS=..."`, *k*) to *dataspaceRef*
+
+If the service crashes before replying, the client's request remains outstanding, and a service
+supervisor [[Armstrong 2003][], section 4.3.2] can reset the modem and start a fresh service
+instance. The client remains blissfully unaware that anything untoward happened.
+
+## Object-capabilities for access control
+
+[Object capabilities](https://en.wikipedia.org/wiki/Object-capability_model) are the only
+properly compositional way to secure a distributed system. They are a natural fit for
+Actor-style systems, as demonstrated by E and its various descendants [[Miller 2006][], [Van
+Cutsem et al 2007][], [Stiegler and Tie 2010][], [Yoo et al 2012][] and others], so it makes sense
+that they would work well for the Syndicated Actor Model.
+
+The main difference between SAM capabilities and those in E-style Actor models is that
+syndicated capabilities express pattern-matching-based restrictions on the *assertions* that
+may be directed toward a given entity, as well as the *messages* that may be sent its way.
+
+Combined with the fact that subscription is expressed with assertions like any other, this
+yields a mechanism offering control over state replication and observation of replicated state
+as well as ordinary message-passing and RPC.
+
+In the SAM, a capability is a triple of
+
+ - target actor reference,
+ - target entity reference within that actor, and
+ - an *attenuation* describing accepted assertions and messages.
+
+An "attenuation" is a piece of syntax including patterns over semi-structured data. When an
+assertion or message is directed to the underlying entity by way of an attenuated capability,
+the asserted value or message body is checked against the patterns in the attenuation. Values
+not matching are discarded silently.
+
+**Restricting method calls.** For example, a reference to the dataspace where our cellular
+modem server example is running could be attenuated to only allow assertions of the form
+Request(`"ATA"`, _). This would have the effect of limiting holders of the capability to only
+being able to cause the modem to answer an incoming call ("ATA").
+
+**Restricting subscriptions.** As another example, a reference to the dataspace where our
+spreadsheet cells are running could be attenuated to only allow assertions of the form
+Observe(⌜CellValue(`"B13"`, _)⌝, _). This would have the effect of limiting holders of the
+capability to only being able to read the contents (or presence) of cell B13.
+
+## Conclusion
+
+We have looked at the concepts involved in the Syndicated Actor Model (SAM), an Actor-like
+approach to concurrency that offers a form of concurrent object-oriented programming with
+intrinsic publish/subscribe support. The notion of a *dataspace* factors out common interaction
+patterns and decouples SAM components from one another in useful ways. Object capabilities are
+used in the SAM not only to restrict access to the behaviour offered by objects, but to
+restrict the kinds of subscriptions that can be established to the state published by SAM
+objects.
+
+While we have examined some of the high level forms of interaction among entities residing in
+SAM actors, we have not explored techniques for effectively structuring the *internals* of such
+actors. For this, the SAM offers the concept of "facets", which relate directly to
+conversational contexts; for a discussion of these, see Garnock-Jones' [2017
+dissertation][Garnock-Jones 2017], especially [chapter
+2](https://syndicate-lang.org/tonyg-dissertation/html/#x_2_5_0_0_25), [chapter
+5](https://syndicate-lang.org/tonyg-dissertation/html/#CHAP:COMPUTATIONAL-MODEL-II:SYNDICATE),
+[chapter 8](https://syndicate-lang.org/tonyg-dissertation/html/#CHAP:IDIOMATIC-SYNDICATE) and
+[section 11.1](https://syndicate-lang.org/tonyg-dissertation/html/#sec:Placing-PL-on-the-map).
+A less formal [discussion of
+facets](https://syndicate-lang.org/about/#facets-represent-sub-conversations) can also be found
+on the Syndicate project website.
+
+## Bibliography
+
+[Armstrong 2003]: #ref:armstrong-2003
+[**Armstrong 2003**] Armstrong, Joe. “Making Reliable Distributed
+Systems in the Presence of Software Errors.” PhD, Royal Institute of Technology,
+Stockholm, 2003. [[PDF]](https://erlang.org/download/armstrong_thesis_2003.pdf)
+
+[De Koster et al 2016]: #ref:de-koster-2016
+[**De Koster et al 2016**] De Koster, Joeri, Tom Van Cutsem, and
+Wolfgang De Meuter. “43 Years of Actors: A Taxonomy of Actor Models and Their Key Properties.”
+In Proc. AGERE. Amsterdam, The Netherlands, 2016. [[DOI (PDF
+available)]](https://doi.org/10.1145/3001886.3001890)
+
+[Garnock-Jones 2017]: #ref:garnock-jones-2017
+[**Garnock-Jones 2017**] Garnock-Jones, Tony. “Conversational
+Concurrency.” PhD, Northeastern University, 2017.
+[[PDF]](https://syndicate-lang.org/papers/conversational-concurrency-201712310922.pdf)
+[[HTML]](https://syndicate-lang.org/tonyg-dissertation/html)
+
+[Gelernter 1985]: #ref:gelernter-1985
+[**Gelernter 1985**] Gelernter, David. “Generative Communication
+in Linda.” ACM TOPLAS 7, no. 1 (January 2, 1985): 80–112.
+[[DOI]](https://doi.org/10.1145/2363.2433)
+
+[Gelernter and Carriero 1992]: #ref:gelernter-1992
+[**Gelernter and Carriero 1992**] Gelernter, David, and Nicholas
+Carriero. “Coordination Languages and Their Significance.” Communications of the ACM 35, no. 2
+(February 1, 1992): 97–107. [[DOI]](https://doi.org/10.1145/129630.129635)
+
+[Konieczny et al 2009]: #ref:konieczny-2009
+[**Konieczny et al 2009**] Konieczny, Eric, Ryan Ashcraft, David
+Cunningham, and Sandeep Maripuri. “Establishing Presence within the Service-Oriented
+Environment.” In IEEE Aerospace Conference. Big Sky, Montana, 2009.
+[[DOI]](https://doi.org/10.1109/AERO.2009.4839647)
+
+[Miller 2006]: #ref:miller-2006
+[**Miller 2006**] Miller, Mark S. “Robust Composition: Towards a
+Unified Approach to Access Control and Concurrency Control.” PhD, Johns Hopkins
+University, 2006. [[PDF]](http://www.erights.org/talks/thesis/markm-thesis.pdf)
+
+[Stiegler and Tie 2010]: #ref:stiegler-2010
+[**Stiegler and Tie 2010**] Stiegler, Marc, and Jing Tie.
+“Introduction to Waterken Programming.” Technical Report. Hewlett-Packard Labs, August 6, 2010.
+[[Available online]](https://www.hpl.hp.com/techreports/2010/HPL-2010-89.html)
+
+[Van Cutsem et al 2007]: #ref:van-cutsem-2007
+[**Van Cutsem et al 2007**] Van Cutsem, Tom, Stijn Mostinckx,
+Elisa González Boix, Jessie Dedecker, and Wolfgang De Meuter. “AmbientTalk: Object-Oriented
+Event-Driven Programming in Mobile Ad Hoc Networks.” In Proc. XXVI Int. Conf. of the Chilean
+Soc. of Comp. Sci. (SCCC’07). Iquique, Chile, 2007.
+[[DOI]](https://doi.org/10.1109/SCCC.2007.12)
+
+[Yoo et al 2012]: #ref:yoo-2012
+[**Yoo et al 2012**] Yoo, Sunghwan, Charles Killian, Terence Kelly,
+Hyoun Kyu Cho, and Steven Plite. “Composable Reliability for Asynchronous Systems.” In Proc.
+USENIX Annual Technical Conference. Boston, Massachusetts, 2012.
+[[Talk]](https://www.usenix.org/conference/atc12/technical-sessions/presentation/yoo)
+[[PDF]](https://www.usenix.org/system/files/conference/atc12/atc12-final206-7-20-12.pdf)
+[[Project page]](https://web.eecs.umich.edu/~tpkelly/Ken/)
+
+
+----
+
+#### Notes
+
+[^terminology-vs-e]: The terminology used in the SAM connects to the names used in E [[Miller
+ 2006][]] as follows: our *actors* are E's *vats*; our *entities* are E's *objects*.
+
+[^analogy-with-function-call]: Consider the analogy to a similarly-fundamental design pattern:
+ function call. It can be usefully expressed in simpler terms, which expose interesting
+ aspects of and variations upon the pattern, but its utility makes it ubiquitous enough to
+ deserve special support not only from most programming languages, but from most *hardware*.
+
+[^rpc-sam-discussion]: Many variations on RPC are discussed in section 8.7 of Garnock-Jones'
+ [2017 dissertation][Garnock-Jones 2017] ([direct link to relevant section of online
+ text](https://syndicate-lang.org/tonyg-dissertation/html/#sec:RPC)).
+
+[^background-on-interests]: For more on assertions of interest, see
+ [here](https://syndicate-lang.org/about/#conversational-frames-conversational-knowledge) and
+ [here](https://syndicate-lang.org/tonyg-dissertation/html/#x_2_2_0_0_8).
diff --git a/src/theory/index.md b/src/theory/index.md
index 1774617..9b02ae0 100644
--- a/src/theory/index.md
+++ b/src/theory/index.md
@@ -1,5 +1,6 @@
# Specifications and Theory
-TODO: links
+TODO: intro
-[Protocol](../protocol.md)
+ - [Syndicated Actor Model](../syndicated-actor-model.md)
+ - [Protocol](../protocol.md)