diff --git a/website/source/docs/internals/architecture.html.md b/website/source/docs/internals/architecture.html.md
index 982394550..0dd5ef76d 100644
--- a/website/source/docs/internals/architecture.html.md
+++ b/website/source/docs/internals/architecture.html.md
@@ -77,8 +77,8 @@ Looking at only a single region, at a high level Nomad looks like:
 ![Regional Architecture](/assets/images/region-arch.png)
 
 Within each region, we have both clients and servers. Servers are responsible for
-accepting jobs from users, managing clients, and computing task placements. Each
-region may have clients from multiple datacenters, allowing a small number of servers
+accepting jobs from users, managing clients, and [computing task placements](/docs/internals/scheduling.html).
+Each region may have clients from multiple datacenters, allowing a small number of servers
 to handle very large clusters.
 
 In some cases, for either availability or scalability, you may need to run multiple
@@ -126,7 +126,8 @@ ensuring PCI compliant workloads run on appropriate servers.
 # Getting in Depth
 
 This has been a brief high-level overview of the architecture of Nomad. There
-are more details available for each of the sub-systems. The [consensus protocol](/docs/internals/consensus.html) is
-documented in detail as is the [gossip protocol](/docs/internals/gossip.html).
+are more details available for each of the sub-systems. The [scheduler design](/docs/internals/scheduling.html),
+[consensus protocol](/docs/internals/consensus.html), and [gossip protocol](/docs/internals/gossip.html)
+are all documented in more detail.
 
 For other details, either consult the code, ask in IRC or reach out to the mailing list.
diff --git a/website/source/docs/internals/scheduling.html.md b/website/source/docs/internals/scheduling.html.md
index e3a19ea27..ca930d85e 100644
--- a/website/source/docs/internals/scheduling.html.md
+++ b/website/source/docs/internals/scheduling.html.md
@@ -10,10 +10,11 @@ description: |-
 
 Scheduling is a core function of Nomad. It is the process of assigning tasks
 from jobs to client machines. This process must respect the constraints as declared
-in the job, and optimize for resource utilization by bin packing. This page documents
-the details of how scheduling works in Nomad to help both users and developers
-build a mental model of how it works. The design is heavily inspired by Google's
-work on [Omega: flexible, scalable schedulers for large compute clusters](http://research.google.com/pubs/pub41684.html)
+in the job, and optimize for resource utilization. This page documents the details
+of how scheduling works in Nomad to help both users and developers
+build a mental model. The design is heavily inspired by Google's
+work on both [Omega: flexible, scalable schedulers for large compute clusters](http://research.google.com/pubs/pub41684.html)
+and [Large-scale cluster management at Google with Borg](http://research.google.com/pubs/pub43438.html).
 
 ~> **Advanced Topic!** This page covers technical details
 of Nomad. You don't need to understand these details to