BioNexus
A lean open-source framework for agentic drug discovery — pluggable models, bio tools, labs, and sandboxes behind five core interfaces.
Core dependencies: pydantic only. Everything else (models, labs, sandboxes,
stores) is an adapter you opt into.
Quickstart (simulator-first, no network needed)
python -m venv .venv && .venv/bin/pip install -e . dev-dependencies... # see pyproject
.venv/bin/pip install -e ".[dev]"
.venv/bin/python examples/iteration_loop.py # full design round on the virtual lab
.venv/bin/python -m pytest # 11 tests, <1s, offline
The example runs: candidate generation → hypothesis tournament → human-approvable
protocol → safety engine → virtual wet lab → fork branch → safety rejection demo →
hash-chained provenance. See docs/PLAN.md for the full build plan.
Simulated lab devices with image readouts
The virtual lab goes one level deeper: a simulated imaging plate reader. A protocol run captures raw fluorescence micrographs per well (96-well plate), an analysis pipeline fits dose–response IC50s from the images, and assay QC is a Z' factor computed from controls. Measured IC50s recover the seeded ground truth within realistic noise, and the raw well images are kept as evidence that agents (or vision-capable LLMs) can inspect:
.venv/bin/pip install numpy # [lab-imaging] extra
.venv/bin/python examples/demo_imaging.py
# run img-c2f0183b: Z'=0.938 (controls PASS)
# compound measured IC50 ground truth
# C2 11.98 uM 10.85 uM
# raw evidence: 14 well images in .data/images/
Failure modes are simulated too: well artifacts (pipetting spikes, bubbles, edge
effects) are flagged, weak compounds are right-censored (no IC50 — test higher
concentrations), and runs failing Z' QC are marked unusable. See
docs/virtual-lab.md.
CLI:
bn run examples/workflow.yml # tournament + assay on the configured lab
bn sim # reference round on the virtual lab
bn prove <branch> --html out.html # tamper-evident provenance + shareable report
bn mcp # MCP server: drive BioNexus from Claude/Cursor
Works with Claude / Cursor / any MCP client — add to your MCP config:
{"bionexus": {"command": "bn", "args": ["mcp"]}}
Exposes generate_candidates, run_assay (dose-response + IC50),
propose_hypothesis, and list_lab_capabilities as agent tools.
Tutorials: notebooks/ — run a campaign · write an adapter · bring your own model.
Extend it:
bn new-adapter lab my_robot # scaffold a tested LabAdapter in seconds
bn new-adapter tool my_docking --cap e.sim.docking
See docs/ADAPTERS.md and the
stability policy — the five core interfaces are stable
surfaces with additive-evolution guarantees.
| Doc | Contents |
|---|---|
docs/QUICKSTART.md |
install, run, workflows |
docs/ADAPTERS.md |
authoring adapters (labs, models, tools, stores) |
docs/SAFETY.md |
safety rules, LabGateway, audit trail |
docs/domain-review.md |
flow fidelity review vs. the real drug-discovery cycle |
docs/benchmarks.md |
public datasets (MoleculeNet, TDC, DOCKSTRING, ProteinGym) + first benchmark results |
docs/virtual-lab.md |
simulated devices, image-based readouts, QC and failure modes |
docs/security.md |
threat model, trust boundaries, agent capability matrix |
docs/stability.md |
versioning, stability tiers, deprecation policy |
docs/PLAN.md |
build plan, principles, guardrails |
Five core interfaces (everything is one of these)
| Interface | Adapters (now → roadmap) |
|---|---|
ModelProvider |
openai_compat (OpenAI/ollama/vLLM/stub) → anthropic, gemini |
LabAdapter (+ SafetyEngine, LabGateway) |
simulator, imaging-simulator (synthetic plate images + analysis + Z' QC) → opentrons, cloud labs |
Sandbox |
local (copy-on-fork) → AgentENV (real fork/snapshot) |
ProvenanceStore |
sqlite → postgres, s3-worm |
BioTool |
rdkit descriptors → docking, ADMET, ESMFold |
Architecture Diagrams
Hand-drawn blueprint-style diagrams (SVG — rendered directly on GitHub):
1 · Layered View — L0 governance → L3 infrastructure, with the five architectural blocks between.
2 · Design Iteration Loop — one active-learning round, from dossier to next-round proposals.
3 · Hypothesis Tournament — Generate → Reflect → Rank → Evolve, plus the fine-tuning flywheel.
4 · Wet-Lab Round Trip — protocol through the safety boundary, instruments, and back as provenance.
5 · Fork / Snapshot Branching — sandbox lifecycle as experiment tree.
6 · Campaign Pipeline — target ID through trial design with human gates and failure loops.
Styled HTML versions (dark blueprint pages with legends/captions) live in
diagrams/artifacts/ — open locally in a browser.
Repository Layout
| Path | Contents |
|---|---|
docs/architecture.md |
Architectural blocks A–F, components, responsibilities, interfaces |
docs/flows.md |
End-to-end flows: design iteration loop, fork/branch, review gates, wet-lab round trip |
docs/blocks/ |
One deep-dive doc per block (A–F) |
docs/research-landscape.md |
Review vs. Google AI co-scientist, Anthropic, Isomorphic, Cradle, Lila, FutureHouse, Coscientist, OpenAI Rosalind |
contracts/ |
The five shared integration contracts (StageTask, ToolInvocation, ProtocolSubmission, AssayResult, ProvenanceRecord) |
diagrams/ |
SVG diagrams + styled HTML artifact pages |
Architectural Blocks at a Glance
| Block | Name | Layer | Can start with |
|---|---|---|---|
| A | Workflow & Orchestration | L1 | stub tool endpoints |
| B | Agent Workforce | L2 | virtual lab + mocked models |
| C | Model & Knowledge Services | L2 | open-source FMs on a GPU box |
| D | Lab Execution | L2/L3 | full virtual lab simulator |
| E | Simulation & Data Services | L2 | existing MD/docking tools |
| F | Infrastructure (AgentENV) | L3 | exists — integrate |
Design Principles
- Contract-first integration — blocks communicate only through five versioned schemas; nothing else couples them.
- Hardware behind an abstraction — agents see the Instrument Abstraction Layer (IAL) only; a Virtual Lab Simulator is a drop-in stand-in for real robots.
- State is snapshot-able — every experiment branch runs in a sandbox that can be forked, paused at review gates, and replayed for audits.
- Provenance is immutable — every artifact carries full lineage (inputs, model versions, prompts, instrument run IDs) in WORM storage.
- Safety is non-bypassable — a policy engine sits in the physical-action path, outside any agent's trust boundary.
References & Sources
The architecture draws on published work from teams operating in this space. The
full review — what each system does, how it compares, and which learnings were
folded into this design — is in docs/research-landscape.md.
Key sources:
- Google — AI co-scientist (paper) · AlphaFold 3 · Isomorphic Labs Drug Design Engine · Bioresilience approach
- Anthropic — Claude for Life Sciences · Model Hardware Standard
- Cradle Bio — Platform · Series B / wet-lab expansion
- FutureHouse — Robin multi-agent system
- Lila Sciences — Agent-driven science on NVIDIA BioNeMo
- Helical — Virtual AI lab / Helix-mRNA FM
- Coscientist (CMU) — Autonomous chemical research with LLMs + robotics, Nature 2023
- OpenAI + Retro Biosciences — GPT-4b micro protein engineering, MIT Tech Review
- Chai Discovery — chai-1/chai-2 structure & antibody models
Metadata
Release files for bionexuslab 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| bionexuslab-0.1.0.tar.gz | 120.2 kB | With provenance | Details for bionexuslab-0.1.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| bionexuslab-0.1.0-py3-none-any.whl | Python 3 | none | any | Details for bionexuslab-0.1.0-py3-none-any.whl |
Total release size: 186.5 kB
Release files / bionexuslab-0.1.0.tar.gz
| Download URL | bionexuslab-0.1.0.tar.gz |
|---|---|
| Size | 120.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
fa3ffea91b28c99fd96c7bb1e2c2a3b6ea275f6ec61b97b2da2ec5cf5b72d1d7
|
|
BLAKE2b-256 checksum How to use checksums |
91f739ad6a482fbafcaf67a461f4c13db2155363e2f5e18e10dfe99dfe168954
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 30, 2026.
Transparency logRelease files / bionexuslab-0.1.0-py3-none-any.whl
| Download URL | bionexuslab-0.1.0-py3-none-any.whl |
|---|---|
| Size | 66.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
a17d47e25dafd44750f2f72d45264fd0b62167bc7f0b8ed487b518a164270b8f
|
|
BLAKE2b-256 checksum How to use checksums |
e3fa31fc5493fc9e8b649c0f4e6b0d3be07f3fd01ecad6365e05800cba27c4a4
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 30, 2026.
Transparency logSecurity for bionexuslab 0.1.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
Both files in this release have been uploaded with provenance metadata.
Attestation for bionexuslab-0.1.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 30, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.