Package Map¶

The package map is the shortest route from a cross-package question to the owning handbook. It should help a reviewer classify work before reading deep code.

Routing Model¶

flowchart TB
    question["cross-package question"]
    foundation["shared meaning and serialization"]
    core["durable rules and lifecycle"]
    knowledge["evidence truth and contradictions"]
    intelligence["recommendation policy and explanations"]
    lab["assay planning and outcomes"]
    runtime["execution and replay"]
    bridge["legacy runtime forwarding"]

    question --> foundation
    question --> core
    question --> knowledge
    question --> intelligence
    question --> lab
    question --> runtime
    question --> bridge

This page should let a reader classify work before diffing the whole repository. The table is useful, but it becomes much easier to use once the package choices are visible as a routing model instead of a long lookup list.

Ownership Map¶

Package	Owns	Use It When
`bijux-proteomics-foundation`	shared payload meaning, identifiers, and serialization	the change affects what packages exchange
`bijux-proteomics-core`	program contracts, lifecycle state, and gates	the change affects durable workflow rules
`bijux-proteomics-knowledge`	evidence state, claims, confidence, and contradictions	the dispute is about trust or evidence truth
`bijux-proteomics-intelligence`	scoring, ranking, scenarios, and explanations	the change affects recommendation policy
`bijux-proteomics-lab`	assay planning, lab execution, and outcome handling	the work concerns experiments or outcome promotion
`bijux-proteomics-runtime`	execution, replay, providers, and operator entrypoints	the work concerns running the system
`agentic-proteins`	temporary legacy forwarding to runtime	the question starts from an old import or CLI path

Shared Non-Product Surfaces¶

the Repository Handbook for cross-package rules and root-owned assets
the Maintainer Handbook for repository-health automation

First Proof Check¶

the matching package under packages/
the matching handbook branch under docs/
package tests that prove the package really owns the claimed behavior

Design Pressure¶

The easy failure is to make the package map accurate but too flat, so readers still hesitate between neighboring packages that sound plausible.