Foundation¶

The core foundation section is where the repository names its durable scientific law: workflow contracts, lifecycle transitions, review gates, runtime-agnostic request shapes, and benchmark acceptance logic. If a page here needs recommendation posture or operator transport to justify itself, the boundary is already drifting.

This section now carries far more real scientific weight than an abstract workflow charter. Public benchmark evidence, workflow-family trust, and release scrutiny all depend on core continuing to state runtime-agnostic workflow contracts, benchmark-acceptance bars, and lifecycle transitions in terms that remain inspectable outside execution code.

Why Readers Should Start Here More Often¶

core is where the repository proves it has scientific law instead of only opinionated runtime wrappers
benchmark trust, family transfer, and package lineage all depend on the contracts named here staying explicit and reviewable
the deeper chemistry, sequence, identification, quantification, PTM, DIA, and targeted surfaces only become trustworthy when their workflow contracts and acceptance bars stay visible before downstream interpretation begins

flowchart LR
    lifecycle["lifecycle states"]
    gates["gate semantics"]
    workflows["workflow contracts"]
    core["core foundation"]
    intelligence["intelligence"]
    runtime["runtime"]
    lab["lab"]

    lifecycle --> core
    gates --> core
    workflows --> core
    core --> intelligence
    core --> runtime
    core --> lab

What This Section Protects¶

one canonical workflow grammar before downstream packages add policy or transport
review-gate and lifecycle truth that stays inspectable outside runtime code
scientific contracts that remain distinct from evidence memory and lab burden

What Makes This Section Scientifically Heavy¶

it names the repository's scientific law before downstream judgment begins
benchmark-backed workflow families must clear benchmark-acceptance scrutiny here before they earn broader trust language
runtime, knowledge, intelligence, and lab all inherit these lifecycle transitions and workflow contracts before they add local owner logic

Start With¶

Ownership and scope: open Package Overview, Ownership Boundary, This Package Does Not Own, and Scope and Non-Goals when the question is whether a scientific workflow concern really belongs in core.
Benchmark evidence: open Benchmark Assets, Flagship Public Benchmark Catalog, Flagship Benchmark Assets, and Benchmark Asset Audit when the question is what public benchmark roots exist and how they were governed into the repository.
Workflow trust: open Benchmark Freshness Review, Benchmark Incompleteness Ledger, Benchmark Flagship Status, and Flagship Acceptance Bars when the question is whether benchmark evidence still earns a public workflow sentence.
Family transfer: open the family lineage pages plus the Flagship Challenge Corpus Catalog when the dispute is whether one workflow family survives blinded holdouts, perturbations, and companion-package generalization.

Section Pages¶

What This Section Settles¶

whether a rule changes canonical scientific workflow truth or only downstream interpretation
which benchmark-acceptance and lifecycle surfaces are still owned here
when a proposed change is really evidence policy, runtime delivery, or lab consequence and should leave this package

Reader Questions This Section Can Answer Well¶

where does the repository define workflow truth before benchmark prose or recommendation prose starts narrowing it
which public benchmark roots actually anchor the current flagship families
why a workflow family can look benchmark-rich and still stay bounded by transfer, acceptance, or lifecycle limits
which neighboring package is allowed to add judgment, grounding, or consequence only after core has named the scientific contract clearly

Strongest Core Proof¶

start with Benchmark Assets when the question is whether the repository has real public scientific roots
continue to Flagship Acceptance Bars when the dispute is whether a family still earns benchmark-backed trust
open This Package Does Not Own when a proposal is trying to turn scientific law into evidence policy, recommendation posture, or operator transport

First Proof Check¶

packages/bijux-proteomics-core/src/bijux_proteomics
packages/bijux-proteomics-core/tests
neighboring handbooks once the change crosses the local boundary

Neighbors¶

Open bijux-proteomics-foundation when the question leaves program contracts, lifecycle rules, and gate semantics.
Open bijux-proteomics-intelligence when the issue is clearly outside this package's local role.