Skip to content

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["identity/identifiers.py<br/>stable identifiers"]
    schema["serialization/document_schema.py<br/>shared payload shape"]
    serialization["serialization/<br/>transport form"]
    migrations["compatibility/schema_migrations.py<br/>version continuity"]
    errors["outcomes/exceptions.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 owner paths should stay explicit enough that a reviewer can find them without relying on wrapper history

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

First Proof Check

  • src/bijux_proteomics_foundation/identity/identifiers.py and serialization/document_schema.py for stable shared meaning
  • src/bijux_proteomics_foundation/serialization/ and compatibility/schema_migrations.py for transport and compatibility structure
  • src/bijux_proteomics_foundation/outcomes/exceptions.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.