Foundation¶

The foundation section explains the durable role of bijux-proteomics-foundation before it explains implementation detail. Use it to resolve why shared meaning belongs here before downstream packages add policy or execution.

flowchart LR
    ids["identifiers"]
    payloads["shared payloads"]
    schema["schema compatibility"]
    migrations["migrations"]
    foundation["foundation section"]
    downstream["core, knowledge,<br/>intelligence, lab, runtime"]

    ids --> foundation
    payloads --> foundation
    schema --> foundation
    migrations --> foundation
    foundation --> downstream

What This Section Protects¶

one family-level meaning for shared objects and records
visible migration discipline instead of silent schema drift
a clean handoff from common semantics to downstream policy and execution

Start With¶

Open Package Overview for the shortest statement of the package role.
Open Ownership Boundary when the question is whether a change belongs here or in a neighbor.
Open Scope and Non-Goals when a proposed change risks broadening the package.
Open Capability Map when you need the concrete work the package is allowed to do.

Section Pages¶

What This Section Settles¶

why a concern belongs in shared meaning instead of in a downstream package
when compatibility pressure justifies a foundation-layer change
how much downstream code should be allowed to depend on shared primitives

First Proof Check¶

packages/bijux-proteomics-foundation/src/bijux_proteomics_foundation
packages/bijux-proteomics-foundation/tests
neighboring handbooks once the change crosses the local boundary

Neighbors¶

Open bijux-proteomics-core when the question leaves shared payload meaning, identifiers, and deterministic serialization.
Open bijux-proteomics-runtime when the issue is clearly outside this package's local role.