[v4] Design batch-pattern detection across submissions

[cpitzi]

Summary

Statistical analysis across multiple manuscript submissions to identify coordinated fabrication campaigns.

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

Why This Is Last

This requires persistent state across audits, a database of prior results, and statistical analysis. It's an architectural change, not a prompt enhancement. High value at editorial scale, but high complexity.

Design Questions (Pre-Implementation)

• Storage: What stores cross-audit data? SQLite? Cloud DB? JSON files in repo?
• Signals: What cross-submission patterns indicate coordinated fabrication?
  • Same shadow papers appearing in unrelated manuscripts
  • Statistically unusual reference list overlap between submissions
  • Same ghost authors across manuscripts
  • Shared citation clusters to predatory journals
• Privacy: Cross-submission analysis means storing author names and reference metadata. What are the data retention and privacy implications?
• Threshold tuning: What level of overlap is suspicious vs. normal? (Foundational papers in a field will appear in many manuscripts legitimately)

Acceptance Criteria (Design Phase)

• Design document in docs/batch-pattern-design.md
• Data model for cross-audit storage defined
• Statistical detection methods identified and documented
• Privacy and data retention policy drafted
• Prototype feasibility assessed (can this work in prompt-only mode, or does it require a separate application layer?)

Dependencies

• Pipeline architecture (Stage 2 needs to persist results)
• At least 10 completed audits to have meaningful cross-submission data

[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, still last in the order, unchanged in substance.

Confirmed against roadmap/v4-features.md: Batch-Pattern Detection is Priority 7 — the final item in the prioritized implementation order — and is unshipped. The stated reason still holds exactly: it needs persistent cross-audit state, which nothing in the repo provides.

Two things worth recording since this was written:

1. Its real dependency is #11, and that has not moved. The roadmap lists API-based orchestration at Priority 4 with the note that it is a "prerequisite for … batch processing of multiple manuscripts" and "persistent state for batch-pattern detection." That is #11, still open. This issue's own "Dependencies" section says the same thing in different words ("Stage 2 needs to persist results"). No path to this one that doesn't go through that one.

2. The second dependency has quietly become more achievable. The issue requires "at least 10 completed audits to have meaningful cross-submission data" — reports/ has been accumulating since, and the repo now carries real-article test sets. Worth counting actual completed audits before assuming this is still blocked on volume; it may only be blocked on storage.

Baseline note: the auditor is now v6, not the v3/v4 era this was written against. That does not change the design questions here — storage, signals, privacy, and threshold tuning are all unaffected by prompt version — but the "10 completed audits" bar should be measured against current-version runs if the statistics are to mean anything.

The [v4] prefix and v4 label are provenance from the v4-features.md backlog, which is still the living roadmap, not a claim that this targets the v4 release.

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