Write up the ap_pipe package and its design decisions.

data-access.tex

@@ -72,6 +72,7 @@ \subsection{Butler}
 A deep coadd on a patch of sky would not have \texttt{exposure} dimensions at all and would instead be something like \texttt{instrument="LSSTCam", tract=105, patch=2, skymap="something"}, which would tell you exactly where it is located in the sky since you can calculate it from the tract and patch and skymap.
 
 \subsection{Instrument Abstractions: Obs Packages}
+\label{sec:obs_packages}
 
 The Butler and pipeline construction code know nothing about the specifics of a particular instrument.
 In the default dimension universe there is an \texttt{instrument} dimension that includes a field containing the full name of a Python \texttt{Instrument} class.

pipe.tex

@@ -18,4 +18,11 @@ \subsection{Task library}
 \subsection{Pipeline Collections}
 
 \texttt{drp\_pipe}
-\texttt{ap\_pipe}
+
+The \texttt{ap\_pipe} package defines the pipeline(s) to be used for real-time Alert Production processing (\ref{}).
+These pipelines include instrument signature removal (\S\ref{sec:isr}), calibration (\S\ref{}), measurement plugins (\S\ref{sec:meas}), image differencing (\S\ref{sec:diffim}), source association (\S\ref{sec:association}), and alert generation (\S\ref{sec:alerts}).
+Some of these tasks are shared with the pipelines in \texttt{drp\_pipe}, but configured to prioritize speed over strict quality; for example, they use a minimal set of measurement plugins.
+
+\texttt{ap\_pipe} currently has pipeline variants for LATISS, the Rubin Observatory simulators, Hyper-SuprimeCam, and the Dark Energy Camera.
+Because these pipelines serve as testbeds for AP-specific algorithms and configuration settings, they differ almost purely in loading instrument defaults from \texttt{obs} packages (\S\ref{sec:obs_packages}).
+The only other customization is an extra task for handling DECam's inter-chip crosstalk, which does not have an equivalent for Rubin instruments.