proteomics-knowledge

proteomics-knowledge is the compatibility alias for the canonical knowledge owner bijux-proteomics-knowledge. It is the install and import alias for bijux-proteomics-knowledge.

Use this package when you want a shorter distribution and import name for the curated scientific memory surface without creating a second owner.

Alias at a glance

• Use proteomics-knowledge when you want a shorter package name for curated scientific memory without changing who owns the behavior.
• Start with the canonical knowledge package docs because this package only forwards into that owner surface.
• Route curation and grounding behavior to bijux-proteomics-knowledge; keep this package focused on compatibility naming and import forwarding.

0.3.8 Release Highlights

• The alias now points readers at the current knowledge handbook instead of reading like a second memory owner.
• Boundaries, release guidance, and compatibility wording now state the forwarding-only contract more clearly.

Installation

pip install proteomics-knowledge

Public APIs

The alias forwards the canonical knowledge surface through proteomics_knowledge:

from proteomics_foundation import DocumentSchema
from proteomics_knowledge import evaluate_schema_compatibility

report = evaluate_schema_compatibility(
    DocumentSchema(
        created_by="proteomics-knowledge",
        document_kind="annotation_pack",
        package_name="proteomics-knowledge",
    )
)

assert report.compatible is True
assert report.profile_id == "knowledge-default-profile"

Package identity

• Distribution name: proteomics-knowledge
• Import root: proteomics_knowledge
• Canonical owner package: bijux-proteomics-knowledge
• Canonical owner import root: bijux_proteomics_knowledge

Package boundaries

• this package owns compatibility naming for the knowledge surface
• reference curation, pathway memory, and evidence grounding remain owned by bijux-proteomics-knowledge
• new knowledge behavior must land in the canonical owner before alias exports change

What this package must not do

• define a second knowledge graph or grounding owner
• drift away from canonical curation behavior
• become an independent release surface for knowledge semantics

Contract checkpoints

• alias exports must keep forwarding to canonical knowledge behavior
• docs must keep the canonical knowledge owner explicit
• compatibility changes must stay covered by alias-package tests

Choose this package when

• you need a shorter import and distribution name for knowledge entrypoints
• migration constraints prefer proteomics_knowledge
• packaging or compatibility work needs a named alias for the knowledge owner

Route elsewhere when

• the change alters curation, grounding, or pathway semantics
• the work adds behavior not already owned by the canonical package
• the alias would stop being forwarding-only

Verification route

• run alias compatibility tests before changing knowledge imports or metadata
• review docs/ARCHITECTURE.md, docs/BOUNDARIES.md, and docs/CONTRACTS.md when alias claims or routing language change
• validate the canonical knowledge README and tests when behavior changes are proposed

Review questions

• does the change preserve this package as an alias only
• is the canonical knowledge owner still explicit in docs and behavior
• would the same outcome remain correct if consumers imported the canonical package directly

Escalation route

• route knowledge behavior changes to bijux-proteomics-knowledge
• stop and review boundaries when package-local curation semantics start appearing
• escalate before release when routing or metadata drift could confuse the knowledge owner

Consumer impact signals

• import-path or package-name changes are high-impact because downstream grounding code may depend on them directly
• alias documentation changes should still be reviewed against the canonical knowledge owner
• wording-only clarifications carry lower release risk than routing or behavior changes

Explicit non-goals

• this package does not own intelligence scoring, runtime delivery, or lab policy
• this package does not create a second knowledge graph
• this package does not replace the canonical knowledge release surface

Documentation

• Release guidance lives in this README.md, this package CHANGELOG.md, and package docs/*.md under the canonical knowledge owner surface.
• Product architecture
• Cross-package ownership
• Canonical knowledge package docs
• Changelog