Journey
Assay development
From a biological question to a versioned method someone else can run. Each stage declares its own inputs, tools, artifacts and review point, and is marked with whether the software exists today.
What this is, and what it is not
Hordago Labs builds software that orchestrates computational workflows. No wet laboratory is operated here. Benchwork, sample handling and instrument runs stay with the laboratory that owns them; this software plans the analysis around that work, runs the computation, and records what was decided and on what evidence.
The stages
This journey is better supported than the therapeutic one, because most of it is analysis rather than chemistry. The two weak points are named below: endpoint and control design is only partly tooled, and the orthogonal validation plan has no repository at all.
5 built · 2 partly built · 1 planned · 8 stages in all. Counted from the registry this page renders.
-
01 / 08Built Repositories exist for this stage and carry the code described.
The biological question
Turn a vague research interest into a question an assay could answer, and a result that would refute it.
Goes in
- Research interest as the group states it
- Constraints: model system, budget, timeline
- Prior work the group trusts
Does the work
- co-scientist — scout, generate, critique, scan, plan and review phases with debate-ranked hypotheses
Comes out
- Ranked, falsifiable hypotheses
- Checkpoint cards flagging low-confidence branches
- The question, written so it can be tested
Person reviews Checkpoint cards are the review surface. A principal investigator resolves each before the pipeline continues.
How this status was set co-scientist is present under the organisation as a substantial Python package with an agent and command surface, and its README documents the phase pipeline and the human checkpoints named here.
-
02 / 08Built Repositories exist for this stage and carry the code described.
Literature
Find out whether the assay has already been run, and what went wrong when it was.
Goes in
- The written question
- Assay type and model system
- Known failure modes the group has hit before
Does the work
- paper-intelligence — claim extraction and contradiction lookup over the literature
- fact-check-os — primary-source refetch and a consensus pass across sources
- biocontext7 — retrieval skill bundles
Comes out
- Claim graph for the assay area
- Contradiction report
- Prior-art note with locators
Person reviews A scientist reads the contradiction report before the protocol is written, so disagreement in the literature is a design input rather than a surprise.
How this status was set Same three repositories as the therapeutic journey's first stage, all present with source and tests. This stage and that one are deliberately the same tooling applied to a different question.
-
03 / 08Partly built Part of this stage has a repository behind it; a named part does not.
Endpoints and controls
Choose what is measured, what it is measured against, and how much signal would be enough.
Goes in
- The written question
- Available readouts
- Expected effect size
Does the work
- statskit — power analysis, effect-size standardisation and assumption checking
- screen-os — essential-gene reference sets used as positive controls in screens
Comes out
- Endpoint definition
- Control plan naming positive and negative controls
- Power analysis for the planned design
Person reviews The power analysis is reviewed before the protocol is fixed, so an underpowered design is caught while it is still cheap to change.
How this status was set statskit exists and contains power and effect-size modules with tests; screen-os contains the essential-gene reference skill. There is no repository that designs controls for an assay in general, so outside pooled screens this stage is an analyst using statskit rather than a tool that produces a control plan.
-
04 / 08Partly built Part of this stage has a repository behind it; a named part does not.
Protocol specification
Write the method down in a form a machine can check and a person can follow.
Goes in
- Endpoint and control plan
- Sample layout and batch structure
- The computation the readout will go through
Does the work
- specforge — compiles a typed run specification into an execution work packet without running it
- science-runtime — phase machine, planning packet and approval-before-execute
- sci-lock-os — a person locks the agreed ground truth into a sealed manifest that downstream steps are held to
Comes out
- Run specification
- Execution work packet
- Sealed manifest naming the files the analysis may touch
Person reviews The lock is the review: a person seals the manifest, and downstream steps are constrained to what was sealed rather than to paths they invent.
How this status was set science-runtime and sci-lock-os are both large Python repositories with the phase machine and sealing behaviour described in their READMEs. specforge exists but is early — a small package with a short history — so the compiler step is real in outline and thin in practice.
-
05 / 08Built Repositories exist for this stage and carry the code described.
Ingestion, quality control and normalisation
Take the raw readout, check it against the specification, and put it on a common scale.
Goes in
- Raw readout files
- Sample sheet and plate or batch layout
- The sealed manifest from the previous stage
Does the work
- screen-os — counting, library QC, normalisation, batch correction and copy-number correction
- cell-os — single-cell ingestion and processing
- BIOos — alignment and sequencing QC
- statskit — missing-data handling and assumption checks
Comes out
- QC report
- Normalised matrix
- Exclusion list with a reason per excluded sample
Person reviews A person reads the QC report and approves the exclusion list before statistics are run. This is the gate most worth holding.
How this status was set screen-os carries counting, QC, normalisation and correction skills; cell-os and bioinformatics-os carry the single-cell and sequencing paths; statskit carries the missing-data modules. All four are present with source and history.
-
06 / 08Built Repositories exist for this stage and carry the code described.
Statistics, dose response and hit calling
Fit the model the specification named, and call hits against it rather than against whatever the data suggests afterwards.
Goes in
- Normalised matrix
- Control plan
- The pre-registered analysis from the run specification
Does the work
- statskit — dose-response fitting, hypothesis tests, multiple-comparison correction, effect sizes and a provenance record on results
- screen-os — gene-level scoring, model-based testing and hit calling
Comes out
- Fitted curves with parameters and confidence intervals
- Corrected significance table
- Hit list tied to the analysis that produced it
Person reviews The hit list is reviewed alongside the assumption report, so a result that violated the model's assumptions is visible at the same moment it is read.
How this status was set statskit contains a dose-response module with its own tests, alongside multiple-comparison, effect-size and assumption-checking modules. screen-os contains the hit-calling and model-based scoring skills. Both were opened and read.
-
07 / 08Planned No repository does this work today.
The orthogonal validation plan
Plan the second, mechanistically different assay that would catch a result the first one got wrong.
Goes in
- Hit list from the primary assay
- The mechanism each hit implies
- Readouts that share as little as possible with the primary assay
Does the work
Nothing does this work today.
Comes out
Nothing, until the stage is built.
Person reviews Not defined as a tool step. The nearest thing that exists is the falsification statement in the science-runtime planning packet, which records what would refute a claim without planning the assay that would test it.
How this status was set Checked for a validation or orthogonal-assay repository under the organisation and found none, so nothing plans this stage. science-runtime carries falsification as a field in its planning packet, which is why it is named here, but it does not design the second assay. Marked planned rather than partial, because no tool performs the stage.
-
08 / 08Built Repositories exist for this stage and carry the code described.
The versioned method and evidence package
Leave behind a method someone else can run and a trail connecting every claim to the artifact that supports it.
Goes in
- Every artifact from the earlier stages
- The review decisions attached to each
- The sealed manifest
Does the work
- evidence-audit — source to script to artifact to panel to claim tracing, with fail-closed admissibility review
- sci-lock-os — sealed manifests and phase state
- science-runtime — validation and release gates that do not call a model
- hordago-contracts — the shared schemas the artifacts are written against
Comes out
- Versioned method with its inputs pinned
- Claim-to-artifact trace
- Admissibility report listing what was rejected
- Release gate result
Person reviews Release is a human decision taken on the admissibility report. Artifacts that fail admissibility are held back rather than footnoted.
How this status was set evidence-audit exists under the organisation, though its README calls the project scientific-audit — a case where the published name and the repository slug differ. sci-lock-os, science-runtime and hordago-contracts are all present with source and history.
What a stage leaves behind
method/ assay: placeholder-viability spec.json endpoints, controls, planned analysis manifest.sealed.json the files the analysis was held to qc/report.html per-plate QC and the exclusion list stats/dose-response.tsv fitted parameters and intervals claims/trace.json each claim, and the artifact under it review/admissibility.json what was accepted, what was held back
The products behind the stages
Each stage names the software that does its work. The full catalogue, with the status of every entry, is on the products page.