Functionality to get audit trails for files belonging to a specific bit preservation collection.
The audit trails must cover relevant data object/file information about condition, ingest and access of the file. The information can originate from the pillars or from e.g. the integrity checks.
The audit trails must be secured to some specified level for files in a specific bit preservation collection. That means which bit preservation level the audit trails must be kept at. One level could be that audit trails must just have via local back-up or that they must secured by two copies 100 km apart with yearly integrity checks. In the reference implementation this is secured via an Audit Trails Service (see also Reference services and Different Audit Trails solutions).
The audit trails can include more or less details. The detailed specification of the information must be specified for each bit preservation collection. For example, it must be specified whether audit trails must include all access information from clients, pillars and coordination layer, or only some of them.
A typical example of requirements to contents of an audit trail is that an audit trail must include information on the integrity checks, e.g. when integrity check was performed and integrity restored. Another example that an audit trail must include media migration in including change of errornous disk and who have had different forms of access to the data object, including mass-processing jobs.
The final audit trail should be given on recommended standardised form by the DK Bit Repository.