Skip to content

Architecture

bijux-proteomics-knowledge architecture is about keeping evidence usable even when sources disagree. This section should help a reader see how claims, graphs, confidence, contradiction handling, and review outputs fit together without collapsing into recommendation policy or generic storage plumbing.

flowchart LR
    evidence["evidence records"]
    claims["claims"]
    knowledge_graph["knowledge graph"]
    confidence["confidence segments"]
    resolution["contradiction resolution"]
    review["review and repository outputs"]

    evidence --> claims --> knowledge_graph
    knowledge_graph --> confidence
    knowledge_graph --> resolution
    confidence --> review
    resolution --> review

Architectural Promise

  • contradictory evidence should become inspectable structure, not silent data loss
  • trust scoring and contradiction handling should remain close to the claims they justify
  • repository boundaries should preserve the reasoning trail, not just the final answer

Start With

  • open Execution Model when the question is how raw evidence becomes reviewable knowledge
  • open Integration Seams when a change starts to blur knowledge work with recommendation policy or generic persistence concerns
  • open Module Map when you need the owner for claims, graphs, confidence, or resolution code

Read By Tension

First Proof Check

  • src/bijux_proteomics_knowledge/claims.py, evidence.py, and graph.py for canonical knowledge structures
  • src/bijux_proteomics_knowledge/confidence/segments.py, resolution.py, and review.py for trust and contradiction handling
  • src/bijux_proteomics_knowledge/repositories.py, schema.py, and serialization.py for durable boundaries

Boundary Test

If the architecture can show a final conclusion but not the path through conflict and confidence, it is hiding the most important part of the package.