Skip to content

Execution Model

Core executes scientific transformations as explicit, inspectable stages. Each stage accepts declared inputs, validates its assumptions, emits stable outputs, and preserves enough lineage to explain exclusions and derived values.

flowchart TD
    A[Files and study metadata] --> B[Parse, normalize, and retain rejections]
    B --> C[Typed scientific records]
    C --> D[Identification and inference]
    C --> T[Targeted or assay-specific review]
    D --> Q[Quantification and statistics]
    D --> P[PTM, proteoform, and DIA evidence]
    Q --> M[Multiplex, LFQ, and contrast evidence]
    Q --> I[Interpretation]
    P --> I
    M --> I
    T --> R[Reviewable result contract]
    I --> R
    B --> X[Rejected inputs and diagnostics]
    D --> X
    Q --> X
    P --> X

No arrow converts an upstream pass into downstream acceptance. Each branch revalidates the assumptions it owns, and a valid branch may stop with a reviewable partial result when another branch is unsupported.

Stage contracts

Ingestion does more than load files: it establishes format validity, sample and run identity, source-row lineage, and experimental-design consistency. Identification converts search output into explicit PSM, peptide, and protein evidence and records target-decoy and grouping decisions. Quantification carries normalization, missingness, roll-up, statistics, and QC choices forward instead of presenting a matrix without its derivation.

Specialized stages add acquisition or biological semantics—DIA transition evidence, multiplex interference, isotope labels, PTM localization, proteoforms, targeted assays—without discarding their upstream evidence. Interpretation then maps results to annotation, pathways, complexes, regulators, or biological context. Review modules package claims, evidence graphs, explanations, and structural diagnostics for inspection.

Stage boundary Required retained evidence Refuse or degrade when
source to normalized records file identity, parser policy, accepted and rejected counts, source-row lineage format, identity, or required metadata cannot be interpreted
normalized records to identifications score direction, target-decoy state, tie and threshold policy, inference ambiguity error control or protein attribution is not defensible
identifications to quantities roll-up, normalization, missingness, uncertainty, exclusions the requested contrast is underdetermined or QC fails
quantities to specialized evidence family-specific policy, interference or localization evidence, caveats family assumptions are violated or support is incomplete
evidence to interpretation claim, contrast, support, contradiction, and limiting uncertainty the evidence ceiling is weaker than the requested sentence

Invocation paths

sequenceDiagram
    participant User
    participant Interface as CLI or Python API
    participant Workflow
    participant Domain as Scientific modules
    participant Output as Stable output writer
    User->>Interface: inputs and explicit options
    Interface->>Workflow: validated request
    Workflow->>Domain: compose scientific stages
    Domain-->>Workflow: results, exclusions, provenance
    Workflow->>Output: tables, cards, reports
    Output-->>User: reviewable artifact set

The CLI and Python entrypoints are adapters over the same owned functions. Workflow modules compose calculations; they do not replace family-level contracts. Runtime may schedule these calls and manage run state, but the result of a scientific function must not depend on whether it was invoked from a terminal, notebook, worker, or HTTP service.

Determinism and refusals

Stable ordering, explicit policies, atomic writes, and retained provenance make repeat execution comparable. Malformed inputs, invalid designs, unsupported formats, and scientifically insufficient evidence are reported as such. They must not be converted into empty success, silently imputed, or omitted from the audit trail.

A comparable rerun therefore requires more than matching final tables. The request, normalized inputs, policy objects, exclusion sets, software identity, and output fingerprints must agree or be explained. Runtime records that execution comparison; core determines whether the scientific result remains acceptable under the declared contract.