Skip to content

Foundation

The foundation section exists to keep shared primitives narrow and durable: identifiers, schema compatibility, canonical serialization, and cross-package invariants. If a page here needs recommendation posture, runtime delivery, or lab consequence to justify itself, the page is already pointing at the wrong owner.

That narrowness matters more now because the repository carries much deeper scientific, runtime, and review surfaces than it did before. The more real workflow and evidence depth downstream packages own, the more expensive it becomes to let shared identifiers, canonical serialization, deterministic hashing, or document meaning drift.

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 shared identifier and document grammar across all product packages
  • deterministic serialization and hashing that survive package boundaries
  • migration-safe invariants that downstream owners can consume without rewriting primitive meaning

Why This Section Is Small On Purpose

  • foundation exists to settle shared primitive meaning before downstream policy begins
  • deeper scientific packages make cross-package invariants more valuable, not less
  • keeping this section narrow prevents recommendation posture, execution behavior, and lab consequence from leaking into the shared substrate

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 This Package Does Not Own when the question is whether a proposal is trying to smuggle product or review behavior into shared primitives.
  • 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

  • whether a rule is truly a shared primitive instead of lifecycle, evidence, recommendation, or execution logic
  • which invariants every package must share before local owner policy begins
  • when a migration helper is justified versus when a higher package should own the change directly

Strongest Foundation Proof

  • start with Package Overview for the shortest owner statement
  • continue to Ownership Boundary when the real question is whether a proposal crosses into downstream policy
  • open This Package Does Not Own when someone is trying to move recommendation posture, runtime behavior, or lab consequence into 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