Skip to content

Bijux Proteomics

bijux-proteomics is a bounded proteomics product for benchmark-backed scientific workflows, reviewable execution, grounded interpretation, recommendation posture, and explicit downstream lab consequence.

The important correction since v0.3.7 is that this repository is no longer best described as governance around isolated packages. It now has a deeper scientific core, public benchmark packets, runtime rerun proof, explicit knowledge and intelligence pressure, and a lab-consequence owner that keeps the cost of being wrong visible.

Python 3.11+ License: Apache-2.0 Verify Release PyPI Release GHCR Release GitHub Docs Release GHCR packages Published packages

agentic-proteins bijux-proteomics-foundation bijux-proteomics-core bijux-proteomics-runtime bijux-proteomics-intelligence bijux-proteomics-knowledge bijux-proteomics-lab

agentic-proteins bijux-proteomics-foundation bijux-proteomics-core bijux-proteomics-runtime bijux-proteomics-intelligence bijux-proteomics-knowledge bijux-proteomics-lab

agentic-proteins docs bijux-proteomics-foundation docs bijux-proteomics-core docs bijux-proteomics-runtime docs bijux-proteomics-intelligence docs bijux-proteomics-knowledge docs bijux-proteomics-lab docs

Product Scope

This site should let a serious reader answer four questions quickly:

  • what scientific workflow families the repository can defend today
  • which package owns each part of that defense
  • where benchmark, runtime, grounding, recommendation, and assay-burden limits still cap the wording
  • which page should be opened next without maintainer narration

What The Repository Actually Contains Now

The repository is no longer best summarized as a set of governance rules around smaller utilities. The current public product contains:

  • benchmark-backed workflow-family evidence packets
  • deep core biology and chemistry surfaces across sequence, spectra, mzML, identification, quantification, DIA, PTM, and targeted review
  • public runtime rerun, replay, verification, and refusal routes
  • grounded claim and contradiction surfaces with real biological context
  • explicit recommendation-confidence, challenge, regret, and downgrade routes
  • assay-planning, readiness, refusal, and outcome-learning consequence routes

Current Credible Workflow Families

The strongest current public sentence is family-specific rather than repository-wide:

  • outsider-auditable today: dda, dia, ptm, targeted
  • review-grade but still bounded: lfq
  • internal support only: multiplex

That sentence is carried by paired benchmark packages, runtime rerun evidence, grounded claim review, recommendation challenge, and lab-consequence boundaries. It is not carried by polished prose alone.

Forbidden Claims

This home page should never imply the following:

  • that one strong workflow family upgrades the whole repository to decision-grade authority
  • that public benchmark depth erases runtime, grounding, recommendation, or assay-burden limits
  • that raw-executable runtime lanes automatically create broader scientific truth
  • that recommendation confidence can outrun the weakest downstream lab consequence

When wording sounds stronger than the weakest owner surface, the right next page is Current Capability Limits.

Reader Paths

  • Scientist: start with Scientist Journey when the question is what one careful scientific reader should trust and why.
  • Operator: start with the Operator Rerun Journey when the question is how to reopen a flagship family without guessing what runtime proof surface counts.
  • Maintainer: start with Maintainer Safe Change when the question is how to evolve the repository without widening dishonest language.

Reader-First Sections

Open these sections in order if you need the shortest honest route through the product:

  1. Product Overview
  2. Product Architecture
  3. Cross-Package Ownership
  4. Workflow Families
  5. Decision Support

Fast Verification Routes

If the question is already owner-specific, jump directly to:

Package Owners

The site is organized around durable package ownership:

handbook owner question
01-bijux-proteomics what the repository claims, where it stops, and how package boundaries fit together
02-agentic-proteins which historical runtime entrypoints still exist and how compatibility is bounded
03-bijux-proteomics-foundation which shared contracts and serialization rules keep scientific state stable
04-bijux-proteomics-core where public benchmark assets and flagship scientific workflow contracts live
05-bijux-proteomics-intelligence how recommendations are challenged, narrowed, or refused
06-bijux-proteomics-knowledge what the repository can ground scientifically and where contradiction remains
07-bijux-proteomics-lab what downstream assay burden, refusal, and learning loops still apply
08-bijux-proteomics-maintain how maintainers verify, release, and keep the repository honest
09-bijux-proteomics-runtime how public benchmark packages become rerunnable runtime evidence

What Changed Since v0.3.7

The docs now need to represent a deeper product:

  • broader core biology and chemistry surfaces across sequence handling, digestion, spectra, mzML, quantification, DIA, PTM, and review artifacts
  • stronger runtime proof through replay, rerun kits, refusal routes, and artifact-integrity surfaces
  • explicit knowledge and intelligence routes for grounding, contradiction, downgrade, overconfidence, and regret
  • a real lab-consequence owner that keeps follow-up burden, refusal, and requested-versus-observed learning public

Reader Rule

If a page makes the repository sound like it has only governance polish, that page is incomplete. If a page makes the repository sound broader than its current benchmark, runtime, grounding, recommendation, or consequence owner can defend, that page is dishonest.

Boundary

This home page should make the product legible and point to the real owner next. It should not duplicate package-handbook detail once the right owner is known.