diff --git a/specification.md b/specification.md
index fabd73f..8a790a5 100644
--- a/specification.md
+++ b/specification.md
@@ -75,7 +75,6 @@
 ## STATUS: EARLY DRAFT
 
 
-
 ## Introduction
 
 The purpose of this document is to provide an analysis of the design and
@@ -87,11 +86,36 @@ corresponding implementation of a job management API is a job management
 library. A job management library, through its  API,  is invoked by a
 client application.
 
-Traditionally, job management is implemented on supercomputers by Local
-Resource Managers (LRMs), such as PBS/Torque, SLURM, etc. To a first
-approximation, a job management API is understood as an abstraction layer
-on top of various LRMs.
-
+Traditionally, job management is implemented on supercomputers by Local Resource
+Managers (LRMs), such as PBS/Torque, SLURM, etc. To a first approximation, a job
+management API is understood as an abstraction layer on top of various LRMs.
+Consequently, the scope of the present API is informed by functionality commonly
+found across LRMs.
+
+The main motivation behind the present job management API is the ubiquity with
+which projects meant to simplify the process of doing science on compute
+clusters are forced to implement their own solution. The reason is simple. If
+any tool needs to be portable across multiple clusters (and it rarely makes
+sense to not want such portability), it must access the underlying cluster LRM
+in an abstract way; that is, it must use a job management API. The only stable
+job management API currently available is
+[SAGA](http://radical-cybertools.github.io/) [so, wait a minute, how do we
+justify not pushing SAGA forward?].
+
+We aim to provide a minimal API. That is, the API focuses on managing
+independent jobs and not much more. Functionality such as expressing and
+enforcing job dependencies, providing a uniform view of software environments
+deployed on target clusters/resources, or providing an information service
+describing characteristics of the target cluster/resource are beyond the scope
+of this API. This is motivated, in part, by the fact that such functionality
+would push the complexity of the API into unmanageable territory, while,
+simultaneously being better suited for separate components.
+
+We take inspiration from a number of projects, some defunct, with overlapping
+scope, such as [Globus
+GRAM](https://en.wikipedia.org/wiki/Grid_resource_allocation_manager),
+[SAGA](http://radical-cybertools.github.io/), and
+[DRMAA](http://www.drmaa.org/).
 
 ### A Note About Code Samples