# Journal Workflow Integrations
Sourceright can support journal submission screening when the editorial workflow can provide manuscript text, extracted references, or canonical CSL JSON and accept back report artifacts.
The integration target is a citation-integrity screening service, not an automatic rejection tool. Reports should identify reference risks, missing evidence, conflicts, and AI-related citation-error signals without claiming that a reference or manuscript was generated by AI.
## Current Integration Surface
The current core can support a platform adapter through:
- `sourceright validate-csl --json`.
- `sourceright report --json`.
- `sourceright report --mcp-resource`.
- `sourceright citations <manuscript.txt>`.
- `sourceright review queue`.
- `sourceright journal-screen`.
- `sourceright export`.
- JSON-ready report and sidecar models in the Rust library.
The remaining platform work is adapter glue: retrieving submission files, running extraction, storing reports, and returning editor-facing or author-facing summaries. The Rust contract already models OJS, generic webhooks, ScholarOne, Editorial Manager, eJournalPress, and Manuscript Manager as screening platform targets.
## OJS First
Open Journal Systems is the preferred first public integration target because it is open source and has a plugin ecosystem. An OJS track should map submission files or extracted text into Sourceright intake, run the citation-integrity report, and store outputs in a way that fits editorial workflows.
Useful OJS outputs include:
- Editorial triage summary.
- Full Markdown or HTML report for editors.
- Author-facing checklist where enabled.
- Machine-readable JSON report for later workflow automation.
Recency and integrity evidence from providers should remain conservative: a
retraction or expression of concern should surface as a review signal, not as an
assertion about claim truth or AI authorship.
## Enterprise Adapters
ScholarOne, Editorial Manager, eJournalPress, Manuscript Manager, and similar editorial systems should initially be handled through adapter contracts or generic batch/webhook workflows. Live integrations should wait for platform API access, vendor documentation, or publisher test environments.
The generic adapter contract should define:
- Submission id.
- Manuscript file or extracted text location.
- Optional reference-list text or CSL JSON.
- Report destination.
- Severity thresholds.
- Visibility rules for editors, reviewers, and authors.
## Privacy
Journal integrations should default to local processing in the journal-controlled environment. Reports should support excerpt minimization or redaction, and live platform tests must be credential-gated and skipped in normal CI.