Operations

bijux-proteomics-core operations is about changing domain law carefully. When this package moves, progression rules, validation behavior, and operator expectations can all move with it. The job here is to keep the central program model coherent while still letting the repository evolve.

flowchart LR
    proposal["domain rule change"]
    invariants["check invariants and lifecycle rules"]
    interfaces["check public contracts and cli behavior"]
    neighbors["check cross-package expectations"]
    review["review governance impact"]
    release["publish updated domain law"]

    proposal --> invariants --> interfaces --> neighbors --> review --> release

What Operations Means Here

• the most dangerous failures are invalid program progression and silent contract drift
• local tests matter, but cross-package invariants matter just as much because neighbors depend on this layer's authority
• release notes should explain rule movement, not just code movement

Start With

• open Common Workflows when you need the normal route from change to domain proof
• open Local Development when you are actively editing lifecycle, review, assay, or target behavior
• open Failure Recovery when a workflow already violated a contract or stage expectation
• open Release and Versioning before publishing changes that alter the meaning of readiness or progression

Route From Risk

• Installation and Setup and Observability and Diagnostics for reproducing domain behavior and finding which rule failed
• Deployment Boundaries and Security and Safety for the boundaries that keep core from becoming runtime-by-accident
• Performance and Scaling when large program sets or validation cost become a real operational factor

First Proof Check

• src/bijux_proteomics/program_spec.py and targets.py
• src/bijux_proteomics/lifecycle.py and validation.py
• packages/bijux-proteomics-core/tests