I wouldn't recommend appending every log warning message into the headers. This could result in the headers being hundreds of fields long, filled with log comments. I would recommend using a single bitfield to capture which reduction steps a file has successfully made it through, maybe re-purposing these

Alternatively, the DRP reduction log files are output in JSON format as well as text format. That makes the logs machine-readable and searchable. One could write a simple tool or script that could parse and extract information from the json logs.

In my opinion, the status and quality information should be captured with something like the following header keys, which would propagate into the drpall file. This has the advantage of keeping the headers light and readable, but still tracking the details.

• QUALITY - a bitfield tracking the output of Dmitry's QA
• DRPQUAL - a bitfield tracking errors and flags raised in the reductions
• STAGE - a bitfield tracking which reduction stage of the pipeline was last successful
• STATUS - a single, final, string of reduction status, indicating "SUCCESS" or "FAIL" (possibly redundant)
• SCIENCEQUAL - a single, final, string quality of the overall quality, "GOOD" or "BAD" (possibly redundant)