Index: trunk/doc/release.2015/ps1.datasystem/response.v1.txt
===================================================================
--- trunk/doc/release.2015/ps1.datasystem/response.v1.txt	(revision 41205)
+++ trunk/doc/release.2015/ps1.datasystem/response.v1.txt	(revision 41206)
@@ -12,2 +12,79 @@
    the bottom and added a line to show where the distribution and
    publication mechanisms interface to these customers.
+
+## Section 3.1
+
+This is by no means necessary, but I'm curious to see a table or
+discussion of what fraction of jobs of various types failed with bad
+"quality". In other words, how much data could you not get through the
+pipelines at all, and what was the most sensitive step?
+
+** We liked this suggestion and added a subsection 3.12 and a new
+   table (2) to discuss the failure rates.
+
+## Section 3.3
+
+Running "Registration" only once for each exposure would seem to
+prohibit re-running "burntool" after updating the algorithm for that -
+and I'm guessing you didn't get that fully stabilized until after you
+had already processed some images and learned from thr experience. How
+did that work?
+
+** We added a couple of sentences to explain that we used a
+   semi-manual task to re-run just the burntool analysis during
+   development and if the code ever needs to be changed.
+
+## Section 3.5
+
+Why a 3rd-order polynomial from chip to focal plane? Wouldn't an
+affine transform have been sufficient (and more than that degenerate
+with the focal plane to sky transform)?
+
+** We use the higher-order transformation for each chip to capture the
+   small-scale astrometric signal present in the data.  One could use
+   an afine transformation for chip-to-focal plane and capture the
+   same signal in a much higher-order model for focal-plane to sky,
+   but that was not our development path.  These would be equivalent
+   solutions.  (Note that degeneracies exist in both cases).   We
+   avoid the degeneracy of the chip positions in the focal plane
+   solution by fitting the local gradient to get the initial
+   distortion solution (and there are certain terms which are held
+   fixed for the focal plane.)  We then limit the impact of the
+   degeneracy by fitting the two levels independently and fixing the
+   focal-plane solution after a few iterations.
+
+   We have added some words to explain some of this, but leave the
+   details to Paper IV.
+
+What makes the masks generated in this step "dynamic"? Are they
+generated wholly from the reference catalog (i.e.  predicting where a
+ghost will appear based on the position of a bright star)? It seems
+like the CAMERA step does not utilize any of the pixel data (just the
+pixel-level masks from CHIP). Is that correct?
+
+  ** correct: the dynamic masks are generated from the reference
+     catalog and do not go back to the original pixels.  We added a
+     paragraph to clarify.
+
+
+## Section 3.8
+
+Is the selection of which warped images go into a stack driven by
+human operators, or are there automated systems to launch these jobs,
+too?
+
+  ** section 5.2 discusses how both the nightly stacks and
+     large-scale reprocessing campaign stacks are automatically
+     defined.  We added some words to refer to this section in 3.8.
+
+## Section 3.10
+
+How much of the PSF-convolved galaxy models do you re-fit in forced
+photometry? If you're fitting more than just the amplitude at that
+stage, and considering each exposure as independent, you're
+potentially throwing away a lot of S/N (at least in the many-exposure
+limit), even if you average later. If you're just fitting the
+amplitude, the structural parameters are still going to be the ones
+affected by poor PSFs in the stack.
+
+  **