Platform Overview¶
bijux-proteomics is split because proteomics work becomes easier to trust
when shared payload meaning, durable program contracts, evidence state,
decision policy, lab planning, and execution are owned in different places.
The split is not presentation polish. It is how the repository keeps authority
visible.
The platform also carries more real scientific and operational depth now than this page used to admit. The package chain no longer exists only to keep governance neat. It exists because broad proteomics work now crosses sequence and chemistry rules, benchmark-backed scientific interpretation, runtime proof, grounded evidence, recommendation posture, and downstream assay consequence.
The platform therefore should be read as an authority chain for one bounded scientific product, not as a packaging convenience. Each hop exists because a different kind of truth is being asserted: shared identifier truth, workflow contract truth, execution truth, evidence truth, recommendation truth, and downstream consequence truth.
Platform Model¶
flowchart LR
foundation["foundation"]
core["core"]
knowledge["knowledge"]
intelligence["intelligence"]
lab["lab"]
runtime["runtime"]
bridge["agentic-proteins"]
foundation --> core
foundation --> knowledge
core --> intelligence
knowledge --> intelligence
intelligence --> lab
runtime --> lab
bridge -. forwards to .-> runtime
This page should give the shortest honest explanation of the package chain. Readers should leave understanding why the split exists and how authority moves through it, not just memorizing package names.
Responsibility Chain¶
bijux-proteomics-foundationstabilizes schema meaning, identifiers, and deterministic serializationbijux-proteomics-coredefines benchmark assets, program models, scientific lifecycle rules, workflow contracts, and benchmark-backed review seamsbijux-proteomics-knowledgetracks claims, confidence, and contradiction state together with grounded biological context and literature supportbijux-proteomics-intelligenceturns those inputs into scores, recommendations, explanations, and downgrade-aware review posturebijux-proteomics-labmaps decisions into assay planning and outcome handlingbijux-proteomics-runtimeexecutes, replays, verifies reruns, and exposes operator-facing runtime proof surfacesagentic-proteinspreserves legacy runtime entrypoints while callers migrate
bijux-proteomics-runtime governs execution, replay, and operator-facing runtime behavior while agentic-proteins remains the compatibility bridge.
Concrete Product Through-Line¶
| stage | owner | current repository substance |
|---|---|---|
| shared meaning | foundation |
identifiers, canonical payloads, compatibility profiles, deterministic hashing, outcome-safe shared records |
| scientific law | core |
sequences, chemistry, spectra, mzML, identification, quantification, PTM, DIA, workflow contracts, benchmark assets |
| evidence truth | knowledge |
grounding, contradiction, literature pressure, pathways, complexes, kinases, disease, drug-target, and ortholog context |
| recommendation posture | intelligence |
ranking, challenge routes, confidence, regret, downgrade, and interpretation summaries |
| downstream consequence | lab |
planning, readiness, handoffs, refusal, requested-versus-observed outcome loops |
| execution proof | runtime |
raw-executable and import-backed reruns, replay, artifacts, comparability, operator entrypoints |
What Each Hop Must Refuse¶
- foundation must not improvise workflow truth, recommendation posture, or lab consequence
- core must not absorb evidence truth or operator-facing execution authority
- knowledge must not turn grounded hesitation into recommendation policy
- intelligence must not rewrite contradiction or runtime realism into cleaner prose
- lab must not promote assay worth without carrying requested-versus-observed burden
- runtime must not claim scientific meaning just because it can emit a stable run bundle
What This Split Lets Reviewers Ask¶
- did a change alter chemistry, sequence, benchmark, PTM, or quantification meaning in core, or only how runtime executes it
- did a public sentence widen because evidence and grounding improved, or because recommendation posture drifted
- did assay-worth-it language change because observed outcomes improved, or because the repository blurred consequence with analytical confidence
Why The Platform Now Looks More Real¶
- the package graph now corresponds to real scientific and operational owner surfaces instead of mostly future-facing structure
- benchmark-backed biology and chemistry depth now sits in core while grounded contradiction and literature pressure sit in knowledge, so review questions no longer collapse into one vague trust sentence
- runtime and lab now make rerun burden and downstream burden visible enough that the platform chain can be audited rather than narrated
Why The Split Pays Off¶
A package boundary is justified only when it reduces one concrete review risk. Here that means reviewers can ask whether a change altered shared meaning, durable contracts, evidence truth, scoring policy, lab decisions, or execution without guessing which layer silently owns the decision.
What Changed Since v0.3.7¶
- the split now maps onto real owned substance, not primarily future-facing architecture
- the core scientific layer became visibly deeper, so later packages can be read as real truth, judgment, and consequence owners instead of abstraction layers
- runtime and lab now make execution burden and downstream burden inspectable enough that the platform can be challenged from both ends
- knowledge and intelligence now expose grounded hesitation and analytical overreach as public owner surfaces rather than as maintainers' private review context
What This Platform Can Now Explain Honestly¶
- why one workflow family may have stronger benchmark evidence than rerun evidence
- why stronger runtime proof does not erase grounding or consequence limits
- why public trust pages can stay narrow even while the package graph gains scientific depth
- why compatibility surfaces like
agentic-proteinsstill exist without regaining canonical ownership
Fast Reader Questions¶
- where a public sentence becomes workflow law instead of evidence
- where a reproducible run becomes grounded belief instead of only an artifact
- where a recommendation stops because contradiction or assay burden still wins
- where a legacy compatibility surface ends and canonical ownership resumes
Strongest Platform Proof Route¶
- start with Product Architecture when the question is how benchmark intake becomes consequence-bearing review
- continue to Workflow Families when the question becomes family-specific rather than repository-wide
- then open runtime, knowledge, intelligence, and lab routes only after the reader understands which owner is allowed to strengthen or narrow the public sentence
First Proof Check¶
- product handbooks under
docs/02-...throughdocs/09-... packages/for the matching package directories- package tests and schema artifacts once one layer clearly owns the claim
Design Pressure¶
The easy mistake is to explain the package family as a catalog of parts instead of an authority chain that keeps trust decisions legible.