For the storage of information related to the genealogy and processing history of a data frame, the Birmingham/Asterix design and subroutine-interface library has been adopted. Therefore the structure is named [HISTORY] and has TYPE HISTORY. (See Asterix Programmer Note 86_008.) A [HISTORY] structure describes the object in which it appears at the top level; it never describes anything at higher levels. This usually means that one history applies to one main data array.
History is optional and is under the control of applications—only they know whether they have done anything important to a file, and which parameters are important, though the user will always have the opportunity to add commentary via various patching and notepad utilities. There should be a logical parameter in applications to enable/disable history recording, which is normally defaulted in the interface file to disabled. Applications which do not modify or create structures containing [HISTORY] (e.g. NDF) do not need to update it — a display application, for example, would not have to write a history record.
History records must not be regarded by applications as machine readable—they must not be used to specify parameters or to control processing, even to re-enact automatically a processing sequence. They are present to assist the user: “What did I do to these data?”, “Did I flat-field this image?”.
History records should be brief.
Details are given in Section 10.6.