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¶
- when evidence volume grows: State and Persistence and Dependency Direction
- when contradictions grow: Error Model and Architecture Risks
- when new source or resolution logic is proposed: Extensibility Model and Code Navigation
First Proof Check¶
src/bijux_proteomics_knowledge/claims.py,evidence.py, andgraph.pyfor canonical knowledge structuressrc/bijux_proteomics_knowledge/confidence/segments.py,resolution.py, andreview.pyfor trust and contradiction handlingsrc/bijux_proteomics_knowledge/repositories.py,schema.py, andserialization.pyfor 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.