Architecture¶

bijux-proteomics-intelligence architecture should make judgment legible. This section is where a reader should understand how candidates become scored, explained, and turned into recommendation outcomes without pretending that policy is the same thing as evidence truth.

flowchart LR
    candidates["candidate intake"]
    metrics["metrics and fingerprints"]
    policies["policies and evaluators"]
    briefs["briefs and reports"]
    outcomes["decision outcomes"]
    loop["design loop feedback"]

    candidates --> policies
    metrics --> policies
    policies --> briefs
    policies --> outcomes
    outcomes --> loop
    loop --> candidates

What Makes This Architecture Distinct¶

it is allowed to judge, rank, and explain
it is not allowed to redefine evidence truth or execute lab work
the feedback loop matters because recommendation quality is learned over time, not frozen in one score pass

Start With¶

open Execution Model when the question is how inputs move through policy into recommendation output
open Integration Seams when a proposed change starts to smell like evidence semantics or execution control
open Module Map when you need the owning family for candidates, policies, reports, or loops

Reader Routes¶

for scoring mechanics: Execution Model and Dependency Direction
for explainability surfaces: State and Persistence and Code Navigation
for future scoring or report extensions: Extensibility Model and Architecture Risks

First Proof Check¶

src/bijux_proteomics_intelligence/candidates.py and domain/candidates/ for decision inputs
src/bijux_proteomics_intelligence/policies.py, evaluators.py, and domain/metrics/ for scoring structure
src/bijux_proteomics_intelligence/report/, briefs.py, outcomes.py, and design_loop/ for explainability and control

Boundary Test¶

If a recommendation cannot be explained as a policy result with named inputs, the architecture is too opaque for the role this package claims.