Skip to content

Interfaces

bijux-proteomics-core interfaces are where the domain speaks in public. This section should make it obvious which surfaces define protein programs, lifecycle gates, assay requirements, and execution readiness so a reader can tell where governance ends and orchestration begins.

flowchart LR
    imports["public imports"]
    programs["program and target contracts"]
    reviews["review and liability surfaces"]
    assays["assay and criteria payloads"]
    execution["execution-facing contracts"]
    operators["cli, repositories,<br/>operator workflows"]

    imports --> programs --> reviews --> assays --> execution --> operators

What Makes These Interfaces Important

  • they publish the constitutional rules of the proteomics program model
  • they are meant to be consumed by both code and review processes, not just by Python call sites
  • they define readiness and progression without owning runtime execution itself

Start With

  • open Data Contracts when the question is what a program, review, assay, or gate payload is allowed to mean
  • open Operator Workflows when the reader is less interested in Python and more interested in how the package is actually used in governed work
  • open Public Imports and CLI Surface when the question starts from code or command entrypoints
  • open Compatibility Commitments before widening or narrowing any public domain promise

Read By Domain Question

What This Section Should Settle

  • which public surfaces define program authority
  • where a downstream package may depend on core contracts without taking over core governance
  • how to distinguish execution readiness from actual execution ownership

First Proof Check

  • src/bijux_proteomics/program_spec.py, programs.py, and targets.py
  • src/bijux_proteomics/cli.py and interfaces/cli.py
  • packages/bijux-proteomics-core/tests