diff --git a/media/README.txt b/media/README.txt
deleted file mode 100644
index 75ed9b6..0000000
--- a/media/README.txt
+++ /dev/null
@@ -1 +0,0 @@
-Placeholder.
diff --git a/media/simulation-poster.png b/media/simulation-poster.png
new file mode 100644
index 0000000..5598ff0
Binary files /dev/null and b/media/simulation-poster.png differ
diff --git a/media/simulation.mp4 b/media/simulation.mp4
new file mode 100644
index 0000000..121f629
Binary files /dev/null and b/media/simulation.mp4 differ
diff --git a/media/simulation.vtt b/media/simulation.vtt
new file mode 100644
index 0000000..0daee66
--- /dev/null
+++ b/media/simulation.vtt
@@ -0,0 +1,181 @@
+WEBVTT
+
+00:00:00.000 --> 00:00:05.843
+Zuul can be used to ensure that every commit
+merged into a project has passed tests
+
+00:00:05.844 --> 00:00:09.442
+and the project continues to work
+with its dependencies.
+
+00:00:09.443 --> 00:00:14.402
+When a change or pull request is approved
+Zuul adds it to the gate pipeline.
+
+00:00:14.403 --> 00:00:18.242
+This pipeline holds changes to be merged
+into their respective projects
+
+00:00:18.243 --> 00:00:20.882
+in the order in which they are going to merge.
+
+00:00:20.883 --> 00:00:23.282
+This ordering can be determined explicitly
+
+00:00:23.283 --> 00:00:25.843
+if a user adds a "Depends-On" line
+to the commit message.
+
+00:00:25.844 --> 00:00:30.003
+In that case, Zuul will make sure that the
+dependency is enqueued first
+
+00:00:30.004 --> 00:00:32.551
+followed by the change that depends on it.
+
+00:00:32.552 --> 00:00:36.657
+Or as in this case the order might simply be
+determined by the order
+
+00:00:36.658 --> 00:00:39.616
+in which changes are approved
+by the project's developers.
+
+00:00:39.617 --> 00:00:41.290
+In the example shown here
+
+00:00:41.291 --> 00:00:44.174
+developers have approved
+two changes to Nova,
+
+00:00:44.177 --> 00:00:45.700
+one change to Keystone,
+
+00:00:45.701 --> 00:00:48.094
+followed by one more change to Nova.
+
+00:00:48.097 --> 00:00:50.896
+As soon as a change is enqueued
+into the gate pipeline
+
+00:00:50.897 --> 00:00:53.376
+Zuul starts running jobs for that change.
+
+00:00:53.377 --> 00:00:57.216
+Each item in the pipeline represents
+a future state of its project
+
+00:00:57.217 --> 00:01:01.616
+but also includes the future state
+of all the projects ahead of it in the queue.
+
+00:01:01.617 --> 00:01:05.136
+So in this case, the tests which are running
+on the second Nova change
+
+00:01:05.137 --> 00:01:08.816
+include the commit for that change
+as well as the first.
+
+00:01:08.817 --> 00:01:12.977
+Nova and Keystone are tested together
+in the integration test job
+
+00:01:12.978 --> 00:01:15.596
+so when that job runs on change #3
+
+00:01:15.597 --> 00:01:17.836
+it is testing not only the Keystone change
+
+00:01:17.837 --> 00:01:20.156
+but both Nova changes as well.
+
+00:01:20.157 --> 00:01:24.071
+Inside that test job,
+it is as if all the changes ahead of it
+
+00:01:24.072 --> 00:01:25.991
+in the queue have already merged.
+
+00:01:25.992 --> 00:01:30.631
+In this way, Zuul tests the changes as they
+would be merged into the git repository
+
+00:01:30.632 --> 00:01:32.711
+not simply as they were written.
+
+00:01:32.712 --> 00:01:35.351
+Zuul runs all of these tests in parallel
+
+00:01:35.352 --> 00:01:36.951
+but as soon as a job fails,
+
+00:01:36.952 --> 00:01:39.491
+the future that Zuul predicted
+is no longer valid --
+
+00:01:39.492 --> 00:01:42.051
+we know that change is not going to merge.
+
+00:01:42.052 --> 00:01:45.651
+All of the tests for changes behind it
+in the queue are outdated
+
+00:01:45.652 --> 00:01:48.611
+so Zuul cancels any running jobs
+for those changes.
+
+00:01:48.612 --> 00:01:52.051
+Here we can see that not only has
+change #4 failed
+
+00:01:52.052 --> 00:01:54.451
+but change #3 has as well.
+
+00:01:54.452 --> 00:01:57.651
+Because #3 failed and is no longer
+eligible to merge
+
+00:01:57.652 --> 00:02:01.171
+Zuul has invalidated the earlier
+test results for #4
+
+00:02:01.172 --> 00:02:06.371
+and has re-started jobs for #4 with only
+changes #1 and #2 included this time.
+
+00:02:06.372 --> 00:02:11.151
+Change #3 stays in the queue in case
+one of the changes ahead of it fails
+
+00:02:11.152 --> 00:02:14.512
+but unless that happens it will not be merged.
+
+00:02:14.513 --> 00:02:17.472
+As changes #1 and #2 complete their tests
+
+00:02:17.473 --> 00:02:20.592
+each of them is merged into
+the Nova repository.
+
+00:02:20.593 --> 00:02:21.794
+Once that is complete
+
+00:02:21.795 --> 00:02:26.914
+it is safe to report the Keystone change #3
+as having failed its tests
+
+00:02:26.915 --> 00:02:30.274
+Finally, the tests for Nova
+change #4 are passing now
+
+00:02:30.275 --> 00:02:33.714
+confirming that the earlier problem
+was due to the Keystone change
+
+00:02:33.715 --> 00:02:37.053
+Zuul merges the final Nova
+change into the repository
+
+00:02:37.054 --> 00:02:39.766
+once all tests are complete.
diff --git a/media/simulation.webm b/media/simulation.webm
new file mode 100644
index 0000000..2b505c3
Binary files /dev/null and b/media/simulation.webm differ