Carlos A. Rojas

Confirmed

The reproducibility problem

Sequencing workflows differ from lab to lab and even from technician to technician. Small and seemingly insignificant alterations to a procedure may yield completely different results. This is especially true in the realm of NGS. Each piece of equipment, every software component, and even the very technician involved in a procedure all represent a segment in a complex puzzle that may change someone's life for the better...or the worse.

What a BCO actually is

The Biocompute standard aims to fix these types of problems with the potential to enhance reliability, reproducibility, interpretability, and interoperability in all labs. In its most basic form, the Biocompute Object, or BCO, is functionally and syntactically identical to an everyday JSON object. It's easily parsable, but most importantly, it is infinitely scalable. The best way to think of this is as a ledger that is continuously written to.

A minimal example

{
    "biocompute_object_id": "BCO_001",
    "spec_version": "1.3.0",
    "object_id": "Cancer_Genes_Panel_Workflow",
    "description": "Short Biocompute Object",
    "execution_environment": {
        "software_prerequisites": [
            { "name": "samtools", "version": "1.9" },
            { "name": "bwa", "version": "0.7.17" },
            { "name": "python", "version": "3.9.15" },
            { "name": "R", "version": "4.1.2", "version_alias": "Bird Hippie" }
        ],
        "operating_system": "GNU/Linux",
        "os_release": "Debian",
        "os_version": "22.04.1",
        "environmental_conditions": { "cores": 16, "memory": "128GB" }
    },
    "inputs": [
        { "input_id": "Iontorrent_Aligned_Sequence_04",
          "value": "IonXpress_Barcode_04_Patient_A.bam", "format": "BAM" },
        { "input_id": "Iontorrent_BAM_Index_04",
          "value": "IonXpress_Barcode_04_Patient_A.bai", "format": "BAI" }
    ],
    "outputs": [
        { "output_id": "Variant_Calls_For_Sequence_Barcode_04",
          "value": "Variant_Calls_For_Sequence_Barcode_04.vcf", "format": "VCF" }
    ],
    "parameters": [
        { "parameter_id": "param_1", "name": "alignment_algorithm", "value": "bwa-mem" },
        { "parameter_id": "param_2", "name": "mapping_quality", "value": 30 }
    ],
    "provenance_domain": {
        "name": "Cancer_Genes_Panel_Workflow",
        "version": "1.3.0",
        "created": "2023-12-01T12:00:00Z",
        "contributors": ["Carlos Rojas"],
        "license": "MIT License"
    }
}

Why this is an engineering problem

The BCO above is an example; in reality a single well-formatted, properly-described BCO will be several thousand or tens of thousand lines in length. This example references already-existing BAM, BAI, and VCF files, but a BCO could embed all three with ease, eliminating the need to track multiple files — a technician or developer need only track a single file, the BCO. This is the same instinct behind configuration-as-code and infrastructure-as-code in IT: capture the entire environment declaratively so it can be versioned, diffed, audited, and reproduced. The goal is to reliably reproduce a sequencing environment by reading a single file — exactly what a good deployment manifest does for a production system.