Interfaces¶

bijux-proteomics-lab interfaces are where scientific intent turns into operational work. This section should show how the package receives assay requirements, publishes planning and schedule payloads, and emits outcome and rerun signals that other packages can still reason about.

flowchart LR
    intent["requirements and assay intent"]
    planning["planning surfaces"]
    schedules["schedule and repository contracts"]
    outcomes["outcome payloads"]
    feedback["rerun and feedback outputs"]

    intent --> planning --> schedules --> outcomes --> feedback

What These Interfaces Need To Carry¶

enough structure to make lab work executable, not merely discussable
enough explicitness to connect outcomes back to plans and assay intent
enough boundary clarity that lab payloads do not quietly absorb program authority or evidence semantics

Start With¶

open Data Contracts when the question is what a plan, schedule, outcome, or rerun recommendation must contain
open Operator Workflows when the reader wants the real lab-facing flow instead of a code view
open Artifact Contracts when the issue is persisted plans, execution records, or promoted outcomes
open Compatibility Commitments before changing any published planning or outcome shape

Read By Workflow Hand-Off¶

Public Imports for code-level planning and outcome entrypoints
Data Contracts and Artifact Contracts for the durable forms of lab work
API Surface, CLI Surface, and Configuration Surface for operator and automation entrypoints
Entrypoints and Examples for concrete end-to-end planning examples

What This Section Should Settle¶

how assay intent becomes an executable artifact rather than a vague recommendation
where outcome payloads belong in the wider proteomics story
which lab-facing interfaces are stable enough for operators and repository tooling to depend on

First Proof Check¶

src/bijux_proteomics_lab/planning.py and outcomes.py
src/bijux_proteomics_lab/schema.py and serialization.py
packages/bijux-proteomics-lab/tests