Architecture¶

bijux-proteomics-foundation architecture is deliberately small, and that is the point. This section explains how the package preserves stable meaning across ids, schemas, serialization, and migrations without quietly absorbing package-specific policy.

flowchart LR
    ids["ids.py<br/>stable identifiers"]
    schema["schema.py<br/>shared payload shape"]
    serialization["serialization.py<br/>transport form"]
    migrations["migrations.py<br/>version continuity"]
    errors["errors.py<br/>shared failure vocabulary"]
    consumers["all higher packages"]

    ids --> schema --> serialization --> migrations --> consumers
    errors --> schema
    errors --> serialization
    errors --> migrations

Architectural Promise¶

the same object should keep the same meaning while it moves between packages, artifacts, and versions
version repair belongs here, but domain judgment does not
the small file count is a design statement, not a sign of incompleteness

Start With¶

open Execution Model when the question is how shared meaning survives transport and version change
open Integration Seams when a proposed helper starts to smell like package-specific policy
open Module Map when you need the exact owner quickly because the package is intentionally compact

Reading Map¶

State and Persistence for what is allowed to become durable
Dependency Direction and Extensibility Model for the rules that keep the package minimal
Error Model and Architecture Risks for the places hidden policy often tries to enter

First Proof Check¶

src/bijux_proteomics_foundation/ids.py and schema.py for stable shared meaning
src/bijux_proteomics_foundation/serialization.py and migrations.py for transport and compatibility structure
src/bijux_proteomics_foundation/errors.py for shared failure vocabulary

Boundary Test¶

If a new helper needs package-specific nouns to justify itself, it probably does not belong in this architecture.