John Parejko added a comment - 25/Jan/23 10:28 PM - edited Summary of my conversation with Yusra and Jim: We should treat VisitSummary as a code interface, not a data product, because it is a temporary internal product. We do have an explicit guarantee that you can read data produced with older code with new code; we do not have a guarantee that you can process old data with new code (for example, running difference imaging with old coadds, or postprocess/analysis_tools on old calexps/tables). In the context of this ticket, this means that developers can add fields to VisitSummary and assume in downstream code-released concurrently with or after the addition-that those fields will exist, while the removal of fields from VisitSummary or significant changes to meanings requires an RFC and potentially a deprecation period. This also means that VisitSummary is explicitly not versioned: its effective version is tied directly to the version of Science Pipelines that was used to produce it and use it. I don't know if the above is fully captured in RFC-699 : that RFC mostly discusses reading of old data, but I had interpreted some of it to refer to further processing of older intermediate data products.