Row 11: Assuming the user story on row 5 is completed, this is primarily a matter of capturing (or being able to query for) DDP transfer data and displaying it within the repository. Are preservation workflow actions captured by the repository as metadata on the work? If not, the Audit calls on the Gateway and Bridge would support asking about audit data for a specific object, which could support building an index or report.

Row 12: Similar comment as Row 11. Would require the repository to capture (or be able to query for) metadata about transfers to a DDP in order to display it. If this data were captured within the repository that would make answering this type of question easier.

Row 13: Beyond comments for Rows 11-12, this requires a knowledge of versioning that is not currently in place in the API specs. Not sure what level of capability the repository would have to capture and display different information for each object version.

Row 14: Notes mention a need to scope this to a single deposit. If that were done, then the repository should be able to display this information by using the Gateway GET Object Audit endpoint. If this is not scoped to one deposit, then this suggests the need to get audit events for all deposited content, perhaps as a log or notification stream, which starts to get down to implementation detail. Clarifying the scope here would be useful.

Row 15: There is no current method via the API specs to directly request fixity information about an object/work that has been ingested into a DDP. The current API specs would allow asking for audit history on an object/work, but what is captured there will depend somewhat on the DDP and fixity details would need to be parsed out. Audit history should include the checksum of each file at ingest, but it may or may not include details on further fixity activities.

Row 16: This is covered by the current API specs

Row 17: The Bridge API spec supports this use case. The current Gateway spec does not appear to support listing of all repository content to support a restore. The repository would likely also need to add support for making such a request and rebuilding the repository.

Row 18: This requires a knowledge of versioning that is not currently in place in the API specs.

Row 19: The Bridge/DDP could record a restore request as an audit event. It would be helpful to get agreement on what types of events must be captured via the audit mechanism. In any case, to be visible to the user this would need to be captured (or queried for) by the repository.