diff --git a/docs/design/selector-generation.md b/docs/design/selector-generation.md
index 27107c31291..032129b6dbb 100644
--- a/docs/design/selector-generation.md
+++ b/docs/design/selector-generation.md
@@ -48,11 +48,17 @@ Make it really hard to accidentally create a job which has an overlapping select
 
 # Proposed changes
 
-## APIserver
+## API
 
 `extensions/v1beta1 Job` remains the same. `batch/v1 Job` changes change as follows.
 
-There are two allowed usage modes:
+Field `job.spec.noAutoSelector` is added.  It controls whether selectors are automatically
+generated.  In automatic mode, user cannot make the mistake of creating non-unique selectors.
+In manual mode, certain rare use cases are supported.
+
+Validation is not changed.  A selector must be provided, and it must select the pod template.
+
+Defaulting changes.  Defaulting happens in one of two modes:
 
 ### Automatic Mode
 
@@ -72,10 +78,6 @@ There are two allowed usage modes:
 - User puts a unique label or label(s) on pod template (required).  user does think carefully about uniqueness.
 - No defaulting of pod labels or the selector happen.
 
-### Common to both modes
-
-- Validation code ensures that the selector on the job selects the labels on the pod template, and rejects if not.
-
 ### Rationale
 
 UID is better than Name in that:
@@ -89,6 +91,10 @@ Commands like  `kubectl get pods -l job-name=myjob` should do exactly what is wa
 
 Using both gets the benefits of both, at the cost of some label verbosity.
 
+The field is a `*bool`.  Since false is expected to be much more common,
+and since the feature is complex, it is better to leave it unspecified so that
+users looking at a stored pod spec do not need to be aware of this field.
+
 ### Overriding Unique Labels
 
 If user does specify `job.spec.selector` then the user must also specify `job.spec.noAutoSelector`.
@@ -128,6 +134,8 @@ We probably want as much as possible the same behavior for Job and ReplicationCo
 
 
 
+
+
 <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
-[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/selector-generation.md?pixel)]()
+[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/selector-generation.md?pixel)]()
 <!-- END MUNGE: GENERATED_ANALYTICS -->
diff --git a/docs/proposals/job.md b/docs/proposals/job.md
index 36e7a760605..d2d728a5b36 100644
--- a/docs/proposals/job.md
+++ b/docs/proposals/job.md
@@ -185,7 +185,7 @@ Below are the possible future extensions to the Job controller:
   [this comment](https://github.com/kubernetes/kubernetes/issues/1624#issuecomment-97622142))
 * Be able to inspect Pods running a Job, especially after a Job has finished, e.g.
   by providing pointers to Pods in the JobStatus ([see comment](https://github.com/kubernetes/kubernetes/pull/11746/files#r37142628)).
-* help users avoid non-unique label selectors ([see this proposal](selector-generation.md))
+* help users avoid non-unique label selectors ([see this proposal](../../docs/design/selector-generation.md))
 
 
 <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->