diff --git a/README.org b/README.org
index 5b4f0fb..a8512d3 100644
--- a/README.org
+++ b/README.org
@@ -1395,6 +1395,82 @@ tonight.
 # add backup of file example; alice's composed capability should
 # live on her own server
 
+One thing we might notice about the previous example is that we said
+that Alyssa set up the endpoint pointed by the capability to "log"
+information about who was associated with it.
+But... where did the logger come from?
+The file did not contain this functionality, and capabilities
+themselves do not intrinsically have logging functionality.
+
+The answer is: Alyssa had a capability to a logging facility, and used
+that to do the logging!
+But what's interesting about that?
+Think about it for a moment: the capability is now doing something more
+interesting than mere "proxying".
+It isn't merely forwarding or not a message to a single capability...
+Alyssa has *composed together* the file capability with the logging
+capability.
+Pretty cool!
+
+And yet we are about to see an even cooler example of composition.
+
+Now that Alyssa has put enough work into this file, she would like to
+automatically back up the file's contents twice a day.
+Luckily, she has a capability to a job-scheduling service:
+
+: # lets Alyssa schedule work at periodic intervals
+: # aka <JOB-SCHEDULER>
+: https://webchronjobs.example/api/3Gw5Ivk_qaNPLWro0MTr_KP1JhuC6GWDvhgDARFG61g
+
+Alyssa also has a capability to a backup service:
+
+: # more or less another place to put files
+: # aka <BACKUP-SERVICE>
+: https://backups.example/api/BUWRNHd2kIkhl0MvtPUd8tqhW_c99c5KdBZYC7bC0NA
+
+And recall, of course, Alyssa's original capability to <PARTY-FILE>
+
+: # aka <PARTY-FILE>
+: https://filestore.example/obj/30SVLFRf1cTPNnjgaJfN8r85joIMVDSgWSKXKoYiFuY
+
+Alyssa would like to have =<JOB-SCHEDULER>= periodically copy
+=<PARTY-FILE>= over to =<BACKUP-SERVICE>=.
+However, she wouldn't like =<JOB-SCHEDULER>= to be able to read
+the contents of =<PARTY-FILE>= or write anything else other than
+the backup of =<PARTY-FILE>= to =<BACKUP-SERVICE>=.
+This might seem like an impossible task... but Alyssa knows how
+to do it.
+
+Alyssa creates a new object/endpoint on her own server with the
+following capability URL:
+
+: # aka <BACKUP-PARTY-FILE>
+: https://alyssas-home.example/obj/9SzcK9U40-EPYll1ixTU2-jgqvPWJy1xvQWfSp3aT-c
+
+Now here's the cool thing: internally, =<BACKUP-PARTY-FILE>= knows
+about and actually uses both =<PARTY-FILE>= and =<BACKUP-SERVICE>=...
+it's just some simple code that reads the current state of
+=<PARTY-FILE>= and copies it over to =<BACKUP-SERVICE>=; that's it.
+But =<BACKUP-PARTY-FILE>= never /discloses/ the locations of either
+=<PARTY-FILE>= or =<BACKUP-SERVICE>=.
+Why should it?
+
+And so, Alyssa can schedule =<JOB-SCHEDULER>= to run
+=<BACKUP-PARTY-FILE>= twice a day.
+But =<JOB-SCHEDULER>= never gets to read the actual contents of
+=<PARTY-FILE>= or write anything else to =<BACKUP-SERVICE>=
+(it doesn't even know where either live).
+This is the Principle of Least Authority in action!
+
+You may also notice that all four of the capabilities in this section
+were on different servers.
+And yet there was no trouble coordinating authority between them.
+The servers really did not need to "think" about which servers, or
+which users, had access to what.
+This all just fell out of the design of the system, the same way
+that data naturally flows through the code pathways of our programs
+through argument passing.
+
 **** Mapping this to ActivityPub