Platform foundations

Bijux Proteomics separates scientific computation, execution, evidence, decision support, and laboratory consequence because each requires a different kind of review. The boundaries make it possible to identify who owns a claim, which artifact supports it, and where uncertainty must remain visible.

flowchart LR
    Q["question"] --> A{"kind of truth"}
    A -->|meaning and identity| F["Foundation"]
    A -->|scientific result| C["Core"]
    A -->|what executed| R["Runtime"]
    A -->|why a claim is grounded| K["Knowledge"]
    A -->|why an action ranks| I["Intelligence"]
    A -->|what happened in the lab| L["Lab"]

No package owns the whole conclusion. A defensible conclusion is a chain of typed handoffs, each retaining the assumptions, rejected alternatives, and provenance required to review that part independently.

Architecture routes

Question	Primary guide	Evidence boundary
How does information move end to end?	Product architecture	data, control, evidence, and feedback flows
Why are there multiple packages?	Repository shape rationale	responsibility and dependency boundaries
Which package owns a model or contract?	Cross-package ownership	canonical owner, consumer, and forbidden duplicate
Which install name provides a capability?	Package map	distributions, imports, commands, and compatibility status
What is inside the public product boundary?	Repository scope	supported surfaces and explicit exclusions
Which terms carry contractual meaning?	Domain language	stable vocabulary across packages and artifacts

Use the package handbook once a question reaches a single owner. Repository architecture defines the seam; the package contract defines behavior at that seam.

Scientific routes

Coverage is organized by evidence posture, not by a single blanket claim of “proteomics support.”

• Workflow families compares DDA, DIA, LFQ, PTM, targeted, and multiplex analysis boundaries.
• Workflow claim limits states how far the available implementation and evidence permit each claim to travel.
• Workflow consequence maps connects analytical outputs to downstream decisions and laboratory consequences.
• Decision support distinguishes evidence synthesis from action ranking and experimental authority.
• Current capability limits collects the important constraints that remain active across the package family.

The workflow-specific trust guides expose evidence at the appropriate depth: DDA, DIA, LFQ, PTM, and targeted proteomics. Multiplex limits explain why that workflow stops short of a stronger public posture.

Independent review route

Trust begins with a claim and ends with an artifact another person can inspect.

flowchart LR
    C["bounded claim"] --> M["readiness matrix"]
    M --> A["public artifact"]
    A --> D["independent rerun dossier"]
    D --> H["hostile review"]
    H -->|supported| P["publishable posture"]
    H -->|gap found| N["narrow or refuse claim"]

1. Read the release readiness matrix to identify the proof category required by the claim.
2. Open the Public Artifact Index and use the Public Artifact Role Matrix to distinguish benchmark, rerun, review, and consequence evidence.
3. Follow an independent rerun dossier or an external review kit without relying on maintainer narration.
4. Apply the Hostile Review Kit, including negative paths and missing-evidence checks.
5. If the evidence does not meet the burden, use the Release Narrowing Protocol rather than strengthening the prose.

The flagship release candidate and one-workflow support record show how those layers compose for a concrete public claim. The readiness blockers and What Would Make This Repository Ready keep remaining gaps explicit.

Ownership rules

• A model has one canonical package owner. Other packages import it or define a purpose-specific projection with an explicit conversion boundary.
• Stable identifiers, canonical serialization, hashes, envelopes, and typed outcomes belong to Foundation.
• Scientific algorithms and workflow-family interpretation belong to Core.
• Provider execution, state transitions, checkpoints, replay, and run evidence belong to Runtime.
• Sources, claims, contradictions, and evidence memory belong to Knowledge.
• Ranking, sensitivity, stance, and refusal policy belong to Intelligence.
• Readiness, handoff, observations, QC, and feedback belong to Lab.

The detailed ownership model and decision rules govern ambiguous cases. Known duplicate surfaces remain visible in the duplicate model ownership record; proximity or convenience is not evidence of ownership.

Repository-wide contracts

Some responsibilities necessarily span packages:

• Public language binds capability wording to a proof burden.
• Change principles preserve compatibility and evidence when a boundary moves.
• Workspace layout connects package ownership to source, test, API, and documentation locations.
• Documentation integrity defines how published guidance remains linked to implemented and checked behavior.

These contracts do not replace package APIs. They define the conditions under which package-local results can be combined into a repository-level claim.