[v4] Integrate Crossref retraction API for structured retraction checking

[cpitzi]

Summary

Replace web-search-based retraction checking with direct Crossref REST API queries for structured retraction metadata (update-to, update-type fields).

See roadmap/v4-features.md (Priority 4) for full specification.

Current State

The v3 prompt checks for retractions via web search against Retraction Watch. This works but is indirect — it depends on search result quality and Retraction Watch coverage.

Target State

For every DOI-bearing reference, query the Crossref API for:

• update-to relationships (retraction notices, corrections, expressions of concern)
• update-type field values
• Retraction notice DOI and date

Implementation Approach

This is most naturally implemented as part of the pipeline decomposition (Stage 2: Sonnet + programmatic verification). In the current monolithic prompt, it can be approximated by instructing Claude to query specific Crossref API URL patterns via web fetch.

Acceptance Criteria

• Every DOI-bearing reference checked for Crossref retraction/correction metadata
• Retraction notice DOI and date included in forensic notes
• Distinguishes retraction, correction, and expression of concern
• Handles partial retractions and editor's notes
• Works in both monolithic prompt and pipeline architecture

Dependencies

• Crossref REST API (free, polite pool — no authentication required for basic queries)
• Pipeline architecture (ideal but not required)

[cpitzi]

Deferred indefinitely (2026-06-19, per maintainer direction) — this is the P4 / architecture tier of the issue-harvest backlog.

These items require structural work beyond prompt engineering — multi-model orchestration (#11), programmatic API integration that pays off mainly inside that pipeline (#8), and persistent cross-audit state (#10) — so they are postponed without a target date. Not rejected: kept open and labeled deferred for the record; reopen into active rotation when editorial-scale throughput or productization makes the build worthwhile.

[cpitzi]

Grooming update — still valid and still unimplemented. The version baselines in it are three releases stale.

Checked against roadmap/v4-features.md: Crossref Retraction API Integration is Priority 5 in the implementation order and carries no "Shipped" marker, unlike its neighbours (Heuristic 8 shipped in v4, Heuristic 9 and COPE alignment in v5, Heuristic 10 and the scoring fix in v6). So the ask is intact.

Correction to the "Current State" section. It reads:

The v3 prompt checks for retractions via web search against Retraction Watch.

The current auditor is v6 (prompts/v6-auditor.md). The web-search-based retraction check is still the mechanism — that part is right — but it is v6 behaviour being described, not v3. Anyone reading this as a v3-era ticket will underestimate how much prompt has been built around the thing they are replacing.

One dependency note. The issue calls the pipeline architecture "ideal but not required", and the roadmap agrees that Crossref is "an optimization of existing capability" — so this does not have to wait on #11. Worth stating plainly, because #11 (API-based orchestration) sits at Priority 4, immediately ahead of this at Priority 5, and the ordering reads as a dependency chain when it is not one.

The [v4] title prefix and v4 label are provenance — these items come from the v4-features.md backlog, which is still the living roadmap document and has carried work into v5 and v6. They do not mean "targeted at the v4 release."

Fleet-wide issue grooming pass, 2026-07-25.