When to apply When an institution or journal needs to record allegations, investigations, retractions, corrections, expressions of concern, or paper-mill detections as structured records that travel with the affected outputs.
Before you start
Prerequisites
What needs to be in place before you operationalise Research integrity and misconduct terminology in your CRIS or repository.
- An institutional research-integrity policy aligned with COPE, ORI, UKRIO, or a comparable national framework
- A controlled vocabulary for integrity event types (allegation, inquiry, investigation, finding, correction, retraction, expression of concern, withdrawal)
- Familiarity with Crossref Mark and Retraction Watch as the canonical federation signals for post-publication updates
- A clear boundary between confidential investigation records (HR / legal) and public-record outcomes (retraction notices)
- Editorial alignment on how integrity events are surfaced on the affected output's public record
Deployment
Five steps to deploy
Each step is small enough to land in a single sprint or a single sitting with the relevant CRIS administrator. Follow in order.
Define an Integrity Event entity
A first-class record type with: event_type (closed list), affected_outputs (multi-link), affected_persons (link, confidential-by-default), date_opened, date_closed, finding (closed list: substantiated / not substantiated / inconclusive / partial), public_outcome_url, COPE_flowchart_reference, retraction_doi if applicable.
Wire output-side integrity markers
On every Output entity, support a current_integrity_status field with values: clear, expression_of_concern_issued, corrected, retracted, withdrawn. When the value changes, the public record must surface the change with a Crossref Mark and a structured retraction or correction record.
Integrate with Crossref Mark / Retraction Watch
Crossref Mark deposit on retraction, correction, or expression-of-concern; Retraction Watch ingests Crossref and produces the canonical public database. Your CRIS should ingest the Retraction Watch feed and flag any institutional outputs that appear there independently of an internal report.
Separate confidential and public records
The Integrity Event entity has a confidential investigation file (access restricted to integrity office and named investigators) and a public-record subset (the published retraction notice, the expression of concern). The two are linked but access-controlled separately.
Pilot with a historic retraction
Pick a published retraction from the past five years and reconstruct the Integrity Event record after the fact. Surface what is missing from the structured record relative to the public retraction notice, and adjust the schema before the next live case.
Worked example
Sample workflow
A realistic walk-through of a single record passing through the Research integrity and misconduct pipeline once the checklist is in production.
Integration points
CRIS and repository systems
Vendor-specific notes on where this vocabulary fits in real research-information systems. Names appear here only where there is public field evidence — they are not vendor partnerships.
Both support integrity-tracking workflows; configure the event-type and finding controlled lists to align with COPE-flowchart references.
Federation target for post-publication updates (Crossref Mark on retraction, correction, expression of concern). Crossref propagates to most downstream indexers.
Ingest the Retraction Watch feed and cross-check against institutional outputs; this is the canonical public federation of retractions independent of publisher self-reporting.
Add an Integrity Event entity via custom metadata; surface integrity status on the Output entity public-portal view.
Integrity Event as a configurable entity; link to Output via standard relationship types; access-control the confidential file via DSpace group permissions.
What goes wrong in the field
Common pitfalls
The patterns that show up repeatedly when this checklist is skipped or misapplied. Address these before they become entrenched.
- Storing retractions as a single field on the Output record without the structured event entity behind it
- Failing to deposit a Crossref Mark, so the retraction is invisible to downstream indexers
- Mixing the confidential investigation file with the public retraction notice, leaking what should not be public or hiding what should be
- Treating Retraction Watch only as a reference and not as an ingest source — public retractions of institutional outputs are sometimes detected externally first
- Letting expressions of concern remain open indefinitely without a defined timeline to either substantiate or close
Frequently asked
Implementation FAQ
- Who maintains this checklist?
- The Research integrity and misconduct working group maintains the checklist alongside the dictionary terms in the same domain. It is reviewed each release cycle (March and September) and updated when a working-group consultation, a vendor product change, or a federation-partner schema update materially changes the operational guidance.
- What if my CRIS or repository is not listed?
- The integration points listed name the systems CASRAI has direct field experience with — Pure, Symplectic Elements, Worktribe, Converis, DSpace and DSpace-CRIS, EPrints, VIVO, Dataverse, Invenio-RDM. The CERIF mapping in the checklist is vendor-neutral and applies equally to other CRIS or repository products. If your system supports the underlying entities (Person, Project, Output, Funding, plus the domain-specific extensions), the steps transfer.
- How do I validate my implementation?
- Three validation surfaces. First, the deposit form should refuse a record missing required fields rather than warn and accept. Second, the resulting metadata should round-trip through the federation layer your institution uses (OpenAIRE Guidelines 4.0 for European federation, DataCite Commons for DOI-anchored discovery, Crossref for article-anchored discovery) without upstream errors. Third, walk a real-world record through the sample-workflow path on this page and confirm the structured fields capture what the prose describes.
- Where do I report errors in the checklist?
- Open a comment via the dictionary-feedback flow at /dictionary/contribute. Editorial corrections — wrong vendor module names, deprecated standards, broken integration paths — are queued into the next release cycle. Substantive disagreements on the operational guidance are routed to the working group for review and may motivate a checklist revision.
- Is this checklist enough to certify my implementation?
- No. The checklist gives you the operational baseline; certification against federation profiles (CoreTrustSeal, OpenAIRE-compliant, COAR-aligned) is a separate process with its own audit. Treat the checklist as the engineering scaffolding and the certification as the institutional sign-off that the scaffolding is being used.
