Ok. I disagreed with the new wording in the ticket... I don't think the finite set of coordinate transformations adds anything useful. Either we are standardized or we aren't.

The problem with verification is that the requirement simply states:

The DMS shall generate and persist a WCS for each visit image. The absolute accuracy of the WCS shall be at least astrometricAccuracy in all areas of the image, provided that there are at least astrometricMinStandards astrometric standards available in each CCD.

and there is no statement as to how portable that WCS representation should be. You'd pass the requirement by being able to read the WCS back in LSST software and look at the calibration error. The discussion has a critical implementation statement saying that we are writing it in standard form which I assume implies that we are doing that so that the WCS can be read by non-LSST stack users. Since it's discussion it's not part of verification.

At this point I'd argue that we really want an extra requirement saying that the WCS in our FITS images can be read by non-LSST software.

I see your point now. It seems like we don't necessarily need a non-LSST requirement, but that it would be a nice thing to provide (i.e., I wouldn't object to requiring it). 

Is this really a question of documentation? (i.e., If we provide coefficients and document the functional form that the coefficients correspond to, we don't need to provide actual code, because users can apply the transformation themselves? Plus, our open-source project tools that apply the transform will be available and documented.)

The point here is that we intend to store these transforms in a usable manner. Documenting our WCS representation doesn't really help people since standard FITS WCS can't represent those transformations accurately (SIP is an approximation that won't work across the LSST field of view) and we can't expect people to take our FITS binary table containing our non-standard WCS and try to reconstruct how we represent complex transformations from the documentation. The problem we are having is that the discussion has (to me) a clear intent to state that the way we write WCS follows a standard and is therefore usable by people outside the project. Without that discussion the way we write WCS can be anything we want so long as we meet the accuracy requirements.

Regardless of the words in the requirement, by the end of the year we should be able to serialize our WCS in a form that can be understood by Astropy without requiring LSST software to be installed.

The requirement DMS-REQ-0030 only applies to PVIs. Similarly, the requirement DMS-REQ-0328,

The persisted format for Processed Visit Images shall be fully documented, and shall include a description of all image characterization data products.

also only applies to PVIs.

I think some refactoring is in order. We should introduce a requirement to report a WCS for difference images (presumably the same one from the PVI), and another to determine a WCS for all coadded images (I don't believe we have such a requirement now), and we should exclude from both these new requirements and from DMS-REQ-0030 any discussion of persistence. We should then add a requirement subtree something like this, rooted in section 1.1, "General Considerations" for "Data Products" in the DMSR:

1.1.8 "Image Data Persistence"
DMS-REQ-xxx1
The DMS shall make all image data products available to end users, upon request, in the FITS 4.0 file format.

1.1.8.1 "Persisted Image Format Documentation"
DMS-REQ-xxx2
The persisted format for all image data products released to end users shall be fully documented, including a description of all image characterization data products.

1.1.8.2 "FITS-compatible WCS persistence"
DMS-REQ-xxx3
The DMS shall include a browse-quality approximate WCS in every FITS image file provided to end users, using WCS representation methods from the FITS 4.0 standard.

Discussion: This ensures that all commonly-available FITS-viewing tools can at least approximately indicate the coordinate system in a display.

1.1.8.3 "Precise WCS persistence"
DMS-REQ-xxx4
The DMS shall include the full computed WCS for all calibrated images released to end users in (... language Tim Jenness can help us craft about using a community-readable format ...)

This will trigger flowdown to the image services requirements in the LSP, LDM-554, as well.