Skip to main content
Tamarind Pipelines is a workflow builder to allow the outputs of one tool to automatically be used as the inputs of another tool. It passes molecular data through a graph of nodes as they execute jobs on Tamarind and tracks dependencies between tools. Pipelines are composed of nodes, and each node is one tool and jobs for that tool on Tamarind. The pipeline builder: a Structures input feeds a BoltzGen de novo nanobody design node, whose designs are scored in parallel for thermostability (TEMPRO) and developability (TNP). Base URL: https://app.tamarind.bio/api/pipelines

Node Types

  • User input: molecule groups or files that supply the starting molecules for the pipeline. This could be a protein to score, a protein target for a design tool, or a sequence to predict a structure.
  • Tool: a tool on Tamarind which runs using input molecules and associates any output scores/files.
  • Filter: allow you to restrict molecules from passing along further in the pipeline based on scores from tools. You can also keep only the top-ranked molecules by a score, or combine multiple upstream sources (union, or intersection by molecule).

Templates and Runs

  • Pipelines are created as templates, which may be versioned, published, and re-run.
  • Templates can be used to create runs, which execute a series of jobs on Tamarind using a given set of inputs.
  • Only the creator of a pipeline may edit it by default, though anyone in the organization may run/duplicate it.
  • A pipeline creator may grant admin access to other users, to allow them to edit the pipeline also.
  • Template versions may not be edited after creation, and only 1 version of a pipeline may be published to your organization.
  • Each node may contain multiple underlying jobs, which each run in parallel. A molecule may move forward in the pipeline if its corresponding job is complete before other jobs in its node have completed.
  • You may test your template using test runs from the pipeline editor page before publishing it to your organization, available alongside other Tamarind tools and your organization’s custom tools.
  • You may designate certain settings as editable by users in your organization.

Reference molecules

  • A pipeline must be created with a reference molecule, which is used to test your pipeline, provide users with example input, and select any required chains throughout the pipeline (e.g. which chain to design, which chain to use as target).
  • When a member of your organization uses the pipeline, they can input their own molecule.
  • Input-specific settings: some tools may require you to choose a chain from your input molecule. The pipeline creator will select chains using their reference molecule, and the pipeline submitter will map their chains to the reference molecule at submission time. The submitter selects any residues on their own chain, such as hotspots or designed regions.

Running pipelines

  • You may stop your pipeline to stop all running jobs and nodes, or stop a node to stop all downstream nodes.
  • Results of your pipeline may be found at /jobs/job-id. You may download the full tool raw results for a given node or the whole pipeline. You may also view all molecular groups associated with the pipeline, along with scores generated during the pipeline run.
  • Before you run a pipeline, a compute estimate will be shown for the weighted hours the pipeline will use. This is an estimate — we recommend running your pipeline with a small number of inputs, then scaling up to a production run.

Pipeline schema

A pipeline is a graph of nodes, allowing the outputs of one tool on Tamarind to be used as the inputs of another. It is defined as a JSON object, and this section explains the schema for that object. A pipeline is a map of node ids to nodes. The map keys are your node ids, which must be unique and are how nodes refer to each other.

Pipeline examples

The pipelines below are the starter templates covering a variety of use cases. Use these with the POST /api/pipelines/templates endpoint to create a pipeline template. Replace <groupId> with a molecule group id (from your organization’s molecule database, GET /api/molecules/groups) before creating. Create a run from the template using the POST /api/pipelines/templates/{id}/runs endpoint.
BoltzGen → TNP + Tempro. BoltzGen (de-novo-nanobody mode) mints VHHs against the target; each design is scored in parallel for immunogenicity (TNP) and thermostability (Tempro).
BoltzGen → DeepViscosity + BioPhi + TAP2. BoltzGen (de-novo-antibody mode) mints paired H+L; each design is scored in parallel for viscosity risk (DeepViscosity), humanness (BioPhi), and TAP2 developability metrics.
ANARCI × 2 + DeepSP + BioPhi + TAP2 + DeepSTABp × 2 + ImmuneBuilder → protein properties. Two ANARCI nodes number H and L independently; DeepSP, BioPhi, and TAP2 each take the H+L pair; DeepSTABp runs twice (per chain) for thermostability; ImmuneBuilder folds the antibody, then protein properties scores the folded structure.
RFPeptides → Boltz + PeptiVerse + PepFuNN. RFPeptides generates de novo peptide binders; each design folds with Boltz and is scored with PeptiVerse and PepFuNN in parallel.
AlphaFold → OpenMM MD. AlphaFold folds the input sequence; OpenMM runs energy minimization, equilibration, and production MD on the folded structure.
BoltzMol → ADMET + QupKake + LogP + FastSolv. BoltzMol mints de novo small molecules against the target; each design is scored in parallel for ADMET profile, microscopic pKa (QupKake), logP, and aqueous solubility (FastSolv). Solvent is a second input slot — bind it to a solvent MolDB group at run (water for aqueous).
ADMET + aqueous-solubility + LogP + FastSolv. Every input molecule flows into each scorer in parallel; FastSolv pairs each solute with the solvent input (water by default) so N solutes yield N solvent-specific solubility scores.
RFdiffusion3 → ProteinMPNN → AlphaFold. RFdiffusion3 (protein-binder-design task) generates backbones against the target; ProteinMPNN designs sequences on each backbone; AlphaFold refolds them so the designs can be validated against the intended binder geometry.
RFdiffusion3 → Boltz + CatPred. RFdiffusion3 runs in enzyme-design mode with residue-level scaffolding around the input active-site residues (carbonic anhydrase II, PDB 2VVB by default); each designed sequence folds with Boltz-2 and is scored for predicted Km against the substrate SMILES (bicarbonate) with CatPred in parallel.
BindCraft → NetSolP + TemstaPro. BindCraft integrates backbone and sequence generation against the target; each binder sequence is scored for solubility (NetSolP) and thermostability (TemstaPro) in parallel.
Tautomer → conformer generation → electronic properties + charge/dipole + electrostatic potential + H-bond strength. Tautomers are enumerated and 3D conformers embedded; each conformer is then scored in parallel for charge/dipole, electrostatic potential (V_min/V_max/V_mean), electronic properties (HOMO/LUMO/gap), and per-site H-bond donor/acceptor strength.
TemstaPro + NetSolP + AlphaFold → Aggrescan3D + protein properties. TemstaPro (thermostability) and NetSolP (solubility) run directly on the sequences in parallel; AlphaFold folds each sequence, then Aggrescan3D (aggregation propensity) and protein properties run on the folded structure.
AlphaFold + Boltz + Chai + ESMFold2 + OpenFold + OpenDDE + Protenix → rmsd-calculator. Every predictor folds the input sequence in parallel; all seven predicted structures feed a single rmsd-calculator node against the reference PDB (fan-in on pdbFile1), producing one RMSD row per predictor.
Gnina → GBSA + RBFE. Gnina docks each candidate against the target with a whole-protein search; the docked poses fan out to MM-GB/PB(SA) endpoint rescoring and RBFE free-energy perturbation in parallel. Swap the default SMILES ligand for an SDF-bearing group before submit.
AlphaFold → DockQ + RMSD. AlphaFold-Multimer folds the multichain sequence as a complex; the prediction is scored against a reference native with DockQ (interface quality) and rmsd-calculator (backbone RMSD). Needs a multichain input AND a paired multichain reference — swap the 1UBQ placeholder for the real crystal before submit.
LigandMPNN → Boltz. LigandMPNN samples new sequences on the fixed scaffold conditioned on the bound ligand; each design is co-folded with the same ligand by Boltz to validate that the redesigned pocket still docks the small molecule.
AlphaFold → FoldSeek. AlphaFold folds the query sequence; the predicted structure is used as a FoldSeek query against the PDB. Useful for finding structural homologs when sequence-search returns nothing. To search AlphaFold DB, Swiss-Prot, ESMAtlas, or a custom database, duplicate the template in the full editor and change the FoldSeek node’s database setting.

Node kinds

There are four kinds, set by each node’s kind field:
  • user_input — Use a molecule group from the Tamarind molecules database or a file as inputs into the pipeline. In a pipeline template, a molecule input is used as the default or reference group it’s authored against in metadata.defaultGroup (required at create/publish). Each run of a pipeline template is submitted with its own group, which is mapped to the reference group at submission time.
  • tool — runs a computational biology tool on Tamarind, named by tool, and can have either user_input or other tool/filter nodes as inputs.
  • filter — narrows or combines results: gather sources on its in port. Can either filter for top K of a given metric, or for specific thresholds on tool scores. Can either combine through intersection (a molecule must be present in all input sources) or union (a molecule must be present in any input source).
  • container — groups several nodes behind one shared input and output handle, so you can wire a source into a set of tools (and gather their outputs) with a single edge. See Containers below.

Reference molecule group

Every molecule user_input names a reference molecule group in its metadata.defaultGroup, and one is required to create or publish a template. The reference group is the example molecules the pipeline is created against: it tests the pipeline, shows users what a valid input looks like, and is how you select any required chains throughout the pipeline, such as which chain to design, score, or use as the target. When a member of your organization runs the pipeline, each run is submitted with its own group at submission time. The reference group defines the shape of the input, not the data every run must use.

Connecting nodes

A node names its upstream sources inside each input setting. A setting’s value is a list of references to upstream node ids. Listing several sources on one port combines (unions) them.

Filters

A filter node combines its sources if there are multiple (union by default, or intersect by molecule identity), and narrows them with an ordered list of rules. A rule is either a defined threshold over molecule attributes (e.g. confidence > 0.9), or a ranked top-K filter that keeps the top results by a score. The confidence example below keeps only molecules whose overall confidence is above a threshold. For advanced use cases, you can define custom rules using jsonlogic to define arbitrary and/or relationships between predicates.

Filter rules & score columns

A predicate rule reads a molecule’s score by column name{ "var": "overall_confidence" } — and a Top K rank_by names a column the same way. Column names are the metrics a tool produces (its output columns). When two tools feeding one filter produce a column with the same name, prefix it with the producing tool to target one specifically: { "var": "<tool>.<column>" }, where <tool> is the same string used in that node’s tool field — e.g. boltz.plddt vs chai.plddt. You can also use a score’s name directly, which still resolves to whichever connected tool carries that score.

Containers

A container groups several nodes behind one shared input handle and one shared output handle. Connecting another node or container to a container’s input is the same as connecting it to every member node inside the container. This allows you to simplify your pipeline structure by grouping multiple related tools together.

Tool settings

A tool node’s settings are validated against that tool’s own field schema. To see every setting a tool accepts — names, types, defaults, and which task each applies to — call GET /api/tools/{name}/schema (and GET /api/tools to list the available tools). The examples below show a few real settings; the schema endpoint is the full, authoritative list.

Worked examples

Diversify and predict structures. Diversify an input structure’s sequence with ProteinMPNN, keep only the high-confidence designs with a filter, then predict a structure for each with AlphaFold.
De novo binder design (VHH). Design de novo VHH nanobody binders against a target antigen with BoltzGen, then score each design in parallel for immunogenicity (TNP) and thermostability (Tempro).
Small-molecule scoring. Score a set of small molecules in parallel for ADMET properties, aqueous solubility, and logP. Every input molecule flows into each scorer independently.

End to end example

Redesign an input structure’s sequence with ProteinMPNN, then fold each design with AlphaFold — create the template, bind your molecule at submit, and poll until it finishes.
Each input slot is bound at submit with a molecule group, plus the residues to act on (residuesByChain) and — only if your molecule’s chain labels differ from the template’s reference chains — a chainMapping. Call POST /templates/{id}/validate first to pre-flight a run without submitting.