proteomics-lab 0.3.8

Install and import alias package for bijux-proteomics-lab.

proteomics-lab

proteomics-lab is the compatibility alias for the canonical lab owner bijux-proteomics-lab. It is the install and import alias for bijux-proteomics-lab.

Use this package when you want a shorter distribution and import name for assay planning and handoff behavior without creating a second owner.

Alias at a glance

• Use proteomics-lab when you want a shorter package name for assay planning, readiness, and handoff entrypoints.
• Start with the canonical lab package docs because this package only forwards into that owner surface.
• Route lab behavior to bijux-proteomics-lab; keep this package focused on compatibility naming and import forwarding.

0.3.8 Release Highlights

• The alias now sends readers to the current lab handbook instead of sounding like a second operational owner.
• Release guidance and compatibility wording now make the forwarding contract explicit before a reader reaches the deeper sections.

Installation

pip install proteomics-lab

Public APIs

The alias forwards the canonical lab planning surface through proteomics_lab:

from bijux_proteomics.domain.assays import AssayRequirement
from bijux_proteomics.domain.program_spec import create_program_spec
from bijux_proteomics.domain.reviews import ReviewGate
from proteomics_lab import build_advisory_assay_plan

program = create_program_spec(
    program_id="prog-readme",
    name="binder rescue",
    objective="recover binding while preserving folding",
    target_id="protein:p11111",
    target_name="PTM1",
    sequence="MPEPTIDEK",
    organism="human",
    mechanism="stabilize productive packing",
).model_copy(
    update={
        "assay_panel": [
            AssayRequirement(
                assay_id="primary-binding",
                purpose="confirm target engagement",
                readout="binding_score",
                sample_kind="biophysical",
                blocking=True,
            )
        ],
        "review_gates": [
            ReviewGate(
                gate_id="pre-synthesis",
                name="Pre-synthesis review",
                required_roles=["scientist"],
                decision_inputs=["evidence_bundle"],
            )
        ],
    }
)
plan = build_advisory_assay_plan(program)

assert plan.program_id == "prog-readme"
assert plan.recommendations[0].assay_id == "primary-binding"

Package identity

• Distribution name: proteomics-lab
• Import root: proteomics_lab
• Canonical owner package: bijux-proteomics-lab
• Canonical owner import root: bijux_proteomics_lab

Package boundaries

• this package owns compatibility naming for the lab surface
• assay planning, handoffs, and execution-adjacent lab policy remain owned by bijux-proteomics-lab
• new lab behavior must land in the canonical owner before alias exports change

What this package must not do

• define a second assay-planning or handoff owner
• drift away from canonical lab behavior
• become an independent release surface for lab semantics

Contract checkpoints

• alias exports must keep forwarding to canonical lab behavior
• docs must keep the canonical lab owner explicit
• compatibility changes must stay covered by alias-package tests

Choose this package when

• you need a shorter import and distribution name for lab entrypoints
• migration constraints prefer proteomics_lab
• packaging or compatibility work needs a named alias for the lab owner

Route elsewhere when

• the change alters assay-planning, handoff, or lab-policy semantics
• the work adds behavior not already owned by the canonical package
• the alias would stop being forwarding-only

Verification route

• run alias compatibility tests before changing lab imports or metadata
• review docs/ARCHITECTURE.md, docs/BOUNDARIES.md, and docs/CONTRACTS.md when alias claims or routing language change
• validate the canonical lab README and tests when behavior changes are proposed

Review questions

• does the change preserve this package as an alias only
• is the canonical lab owner still explicit in docs and behavior
• would the same outcome remain correct if consumers imported the canonical package directly

Escalation route

• route lab behavior changes to bijux-proteomics-lab
• stop and review boundaries when package-local assay semantics start appearing
• escalate before release when routing or metadata drift could confuse the lab owner

Consumer impact signals

• import-path or package-name changes are high-impact because downstream operational tooling may depend on them directly
• alias documentation changes should still be reviewed against the canonical lab owner
• wording-only clarifications carry lower release risk than routing or behavior changes

Explicit non-goals

• this package does not own core scientific semantics
• this package does not create a second assay-planning or handoff owner
• this package does not replace the canonical lab release surface

Documentation

• Release guidance lives in this README.md, this package CHANGELOG.md, and package docs/*.md under the canonical lab owner surface.
• Product architecture
• Cross-package ownership
• Canonical lab package docs
• Changelog