How do I build a reproducible evidence-register provenance workflow?

Build a reproducible evidence-register provenance workflow by fixing a field schema, capturing identifiers and versions at entry time, and running a completeness audit before any entry is marked complete. The workflow below turns that into a repeatable sequence with a field schema and an audit table.

Define the provenance field schema

Each register entry should carry these fields so a later reader can retrace the source:

• Entry ID: your internal, stable identifier for the register row.
• Source title: the title as deposited or published.
• Identifier and identifier type: the DOI or other persistent identifier, recorded with its type so it is not mistaken for another scheme.
• Identifier source: which service the identifier and metadata were retrieved from, such as Crossref for scholarly works or DataCite for DOI metadata.
• Version or deposit date: the version, edition, or deposit date recorded with the metadata.
• Retrieval date: the date you captured the record.
• Verification status: whether the reference was checked against the original source, per ICMJE guidance to verify references against original sources.
• Retraction or correction flag: whether a retraction or correction is known, since ICMJE advises authors to identify retractions.
• Completeness result: pass or hold from the audit step.

Capture identifiers and versions

1. Record the identifier and its type at the moment of entry, and note which service returned the metadata. A DOI lookup in the Crossref REST API returns the metadata deposited for that DOI; the DataCite REST API exposes DOI metadata and supports queries and filters. Write the service name and, if needed, the endpoint path such as /works in the register.
2. Capture the version or deposit date alongside the identifier so a later change to the record is visible against the version you used.
3. Verify the reference against the original source where possible, following ICMJE guidance, and set the verification status field to reflect what you checked.

Run the completeness audit before marking complete

Use a short audit table with one row per entry and one column per required field. Mark each cell present or missing, then apply the decision rule: an entry moves to complete only when every required field is populated and the verification status is recorded. Entries with a missing identifier, version, or verification status stay on hold with the missing field named as the next action.

| Check | Pass condition | Action if failed |
|---|---|---|
| Identifier and type present | Both recorded | Return to source service, re-query |
| Version or deposit date present | Recorded | Re-capture from metadata |
| Verification status set | Checked against original | Verify, then update status |
| Retraction flag reviewed | Flag recorded | Note status, hold entry |
| Completeness result | All above pass | Keep on hold, list gap |

Record the audit result in the entry itself so the register shows why an entry was closed.