Skip to content

Scientific Workflow Roadmap

bijux-proteomics no longer needs a roadmap because the repository has no scientific substance. It needs one because the product now has several real workflow-family proof routes, but that proof is still uneven across the wider proteomics surface. The roadmap exists to separate genuine current depth from the next scientific surfaces that still need their own public evidence, runtime realism, grounding pressure, and consequence discipline.

Current State

Today the repository is strongest in these areas:

  • outsider-auditable bounded families: dda, dia, ptm, targeted
  • review-grade-bounded family: lfq
  • internal-support-only family: multiplex
  • broader core scientific ownership across sequence, chemistry, spectra, mzML, quantification, PTM review, and benchmark packaging
  • explicit runtime, grounding, recommendation, and consequence routes that now let reviewers challenge one workflow sentence end to end

What Is Still Missing

  • broader cross-family transfer proof that survives the same scrutiny level across more study shapes and instrument contexts
  • stronger live-engine or broader runtime realism where some lanes still stop at import-backed or library-conditioned pressure
  • wider biological and assay consequence closure that can survive stronger downstream burden without collapsing back to exploratory-only wording
  • public proof for advanced surfaces such as glycopeptide-heavy, broader library-search, and more external-engine-intensive workflows

Next State

The next durable step is not to add more words. It is to add more family-specific proof packets:

  • preserve the current family packet pattern: benchmark package, runtime lane, grounding route, recommendation packet, and consequence surface
  • widen that pattern to the scientifically important families that still stop at boundary-only or internal-support language
  • keep glycopeptide, library-search, and external-engine behavior at explicit boundary scope until they earn the same public scrutiny route
  • widen the proven workflow surface without losing package ownership clarity

Each new workflow family should remain reviewable from repository contracts rather than being hidden inside one runtime path or one notebook.

Why This Matters

Without an explicit roadmap, the repository can look deeper than it is. The goal is not to decorate package boundaries with ambition. The goal is to grow a real scientific workflow on top of those boundaries without losing ownership clarity.

The roadmap is about what should exist next after the current bounded family-level proof set. The exact list of what does not yet exist lives in Current Capability Limits.

Strongest Companion Routes

Boundary

This roadmap should keep the repository honest. If a future claim sounds like a workflow capability, it should land either as one concrete workflow contract or stay here as future work until it exists.