Structured metadata, not spreadsheets

Free-text CSV columns are ambiguous — an AI has to guess what "organism" or "sample" means. ISA-Tab gives BioLedger structured, ontology-backed metadata instead: sources, samples, characteristics, and assays with formal relationships between them. That structure is what lets an LLM reason reliably about your data — which files belong to which sample, which organism they came from, what assay produced them — instead of pattern-matching on column names.

Run anywhere — Docker, Conda, Nextflow, Snakemake, or Galaxy

BioLedger tool specs are execution-agnostic: a declarative command template, input/output contract, and parameters. Today BioLedger runs tools via Docker, Conda (native conda environments via conda run), Nextflow, Snakemake, and Galaxy (via planemo or remote instances). You're not tied to a single platform — every run is fully observable, with exact commands, containers, and file hashes recorded for reproducibility and traceability.

Think in experiments, not workflows

Researchers don't design a pipeline up front — they load some data, try a tool, look at the output, and decide what's next. BioLedger is built around that reality: every action you take (tool runs, imports, LLM calls, notes) is recorded in an append-only ledger as you work. The workflow and RO-Crate aren't something you author — they're crystallized after the fact from the ledger, as an artifact that makes what you did reproducible for someone else (including future you).

Let workflow engines do what they do best

BioLedger doesn't reinvent workflow orchestration. When you run a tool via Nextflow, Snakemake, or Galaxy, the engine manages its own tool calls, environment, and execution — BioLedger integrates seamlessly as a provenance layer on top. Discovered tools from the Galaxy Tool Shed, nf-core, or snakemake-wrappers run via their native engines without translation — pin a specific upstream revision with @<revision> for reproducibility. The ledger records what happened; the engine handles how it happened.

LLM where it earns its keep

The LLM is used only where judgment genuinely helps — suggesting a next step, resolving how one tool's output should feed the next tool's input, fixing malformed imports. Everything else is deterministic and programmatic: execution, file hashing, provenance linking, and artifact generation. Because the ledger records every action and every LLM message as a first-class, file-based artifact, the whole history is independently verifiable — you don't have to trust a model's summary of what happened.

Roadmap

Near-term: Inline output previews (HTML reports, tabular data, BAM/VCF summaries) so you can inspect results without leaving the session, Singularity support for sites without Docker, and LLM-assisted tool spec authoring (describe a tool in plain English and have the agent draft a spec).

Longer-term: Turning an NCBI BioProject accession into an ISA-Tab study by querying NCBI directly, and expanding the public tool and study libraries with community contributions.

Documentation

Schema references for the two formats BioLedger builds on, each auto-generated from the live Pydantic models so they can't drift from the code:

Explore the libraries

BioLedger hosts two small, growing public libraries of ready-to-use assets. They're searchable here, and discoverable directly from the CLI (bioledger library list, bioledger study list) — tools are auto-imported on first use.

Examples

Complete end-to-end walkthroughs, kept in sync with the examples/ directory in the repo — from a first "hello world" session to a full variant-calling pipeline built entirely from the public libraries.

Browse the examples →