Bijux Proteomics¶

bijux-proteomics is a modular proteomics system. It does not hide its ideas inside one large package. It separates shared meaning, durable program rules, evidence state, decision policy, lab execution, and runtime control so each kind of responsibility can stay legible.

The point of this split is not packaging for its own sake. The point is to make serious scientific and operational work reviewable: what the system means, what it knows, how it decides, how it runs, and how it touches the lab are not the same question and should not collapse into the same code story.

That does not mean the full scientific workflow already exists. Today the repository is strongest where contracts, package boundaries, and reviewable domain surfaces are concerned. The end-to-end proteomics workflow story still needs more explicit stage blueprints and clearer current-scope boundaries.

flowchart LR
    foundation["foundation<br/>shared meaning<br/>schemas, ids, migrations"]
    core["core<br/>durable program rules<br/>gates, lifecycle, workflows"]
    knowledge["knowledge<br/>evidence state<br/>claims, confidence, contradictions"]
    intelligence["intelligence<br/>decision policy<br/>ranking, scenarios, explanations"]
    lab["lab<br/>assay-facing loop<br/>plans, outcomes, promotion"]
    runtime["runtime<br/>execution control<br/>operators, providers, replay"]
    legacy["agentic-proteins<br/>legacy bridge"]
    maintain["maintain<br/>repo health<br/>docs, checks, release, policy"]

    foundation --> core
    foundation --> knowledge
    foundation --> intelligence
    core --> intelligence
    core --> runtime
    knowledge --> intelligence
    intelligence --> lab
    lab --> knowledge
    runtime --> lab
    legacy -. migrate .-> runtime
    maintain -. verifies .-> foundation
    maintain -. verifies .-> core
    maintain -. verifies .-> knowledge
    maintain -. verifies .-> intelligence
    maintain -. verifies .-> lab
    maintain -. verifies .-> runtime

What Makes This Repository Worth Reading¶

it treats proteomics work as a system with distinct layers of truth, policy, execution, and experiment
it keeps evidence and recommendation separate, so a ranking is never allowed to masquerade as raw fact
it keeps runtime and lab behavior separate, so orchestration and assay action can evolve without erasing their seam
it keeps the migration from agentic-proteins visible instead of pretending the transition never happened

Current Limit¶

The current repository can explain and validate package-level responsibilities, but it is still building the scientific workflow spine that should carry one proteomics program from sequence intake through assay planning, evidence review, and advancement decisions.

Start Here¶

Open the Repository Handbook when the question is about the system as a whole and not yet about one package.
Open the Scientific Workflow Roadmap when the question is what the current package stack still needs before it becomes a full proteomics workflow engine.
Open one product handbook when you already know where the real idea lives: evidence, decisions, lab work, execution, or shared contracts.
Open the Maintainer Handbook when the question is how the repository keeps itself honest.

Package Family At A Glance¶

Package	Owns
`bijux-proteomics-foundation`	shared schema compatibility, identifiers, and deterministic serialization
`bijux-proteomics-core`	program definitions, lifecycle contracts, and gate semantics
`bijux-proteomics-knowledge`	evidence records, claims, confidence, and contradiction state
`bijux-proteomics-intelligence`	scoring, ranking, scenario evaluation, and explanations
`bijux-proteomics-lab`	assay planning, outcome capture, and lab-facing loop control
`bijux-proteomics-runtime`	execution, replay, provider integration, and operator entrypoints
`agentic-proteins`	temporary compatibility forwarding for legacy runtime imports and CLI paths

bijux-proteomics-runtime governs execution and replay. agentic-proteins preserves compatibility entrypoints.

Reading Paths¶

If you want the architecture story first: Repository Handbook then Foundation then Core
If you want the scientific reasoning story first: Knowledge then Intelligence then Lab
If you want the operational story first: Runtime Handbook then agentic-proteins then Maintainer Handbook

First Proof Check¶

packages/ for the package split this page is explaining
mkdocs.yml for the published navigation spine
package tests, schema artifacts, and workflows once one package clearly owns the claim

Boundary¶

This page should make the system feel coherent before the reader sees code. It should not try to replace the owning handbooks for package-level detail.