Importing instrument data
All methods · August 12, 2026 · Jan Hellemans
Bringing instrument data into an experiment in Clarida means importing the Cq export your instrument software already produced. If that import is well annotated, that is all it takes to start downstream analyses. If the experiment was designed in Clarida, two extra steps link the Cq data to the pre-generated annotation and resolve any annotation conflicts. We describe what kind of data Clarida imports today and how the importer adapts to the workflow: a single step when going straight to analysis, two more when there is a design to reconcile against.
After a qPCR run finishes, the instrument software produces a table of quantification cycle (Cq) values, one per well or well-dye combination. The Import & annotate section brings that table into a Clarida experiment, where the data can be quality-controlled, normalized, and explored. The input is the export file the instrument software produces; the Cq values it contains are used as recorded.
This page describes what data the importer reads today, and why the import consists of one to three steps depending on the experiment. The terms used throughout, such as quantification cycle (Cq), dye, and the sample-type codes, follow the MIQE guidelines (Bustin et al., 2025) and the RDML data standard (Lefever et al., 2009), the reference vocabularies for reporting qPCR.
Imported data: the instrument's Cq export
Clarida currently imports Cq export files: per-well tables of quantification cycle values, as produced by a qPCR instrument or its analysis software. The Cq values determined by that software are used directly; the raw amplification curves are not re-read.
This reflects the current scope rather than a final design. Reading instrument run files directly, and deriving Cq values from amplification curves within Clarida, is planned. Until then, importing the Cq export reuses the baseline, threshold, and amplification calls already made in the instrument software, and leaves those values unchanged.
The importer reads tabular exports (.xlsx, .csv, .txt, or .tsv) with one row per measured well, or per well-dye combination on a multiplex run. Two columns are required: the well position and the Cq value. The remaining columns are optional; when present, they are used to annotate the run or to match the import against an experiment's design.
| Column | Description | Recognised by (aliases) |
|---|---|---|
| Well ★ | Plate position A1–P24 | Well, Well Position, Pos, Position, Well Name |
| Cq ★ | Quantification cycle (blank = undetermined) | Cq, Ct, Cp, Cq Value, Ct Value, Cp Value, C(q), C(t) |
| Sample | Sample name | Sample, Sample Name, Sample ID |
| Assay | Target / gene measured | Assay, Assay Name, Gene, Gene Name, Detector, Target, Target Name |
| Assay type | Gene of interest, reference gene, or a control | Assay Type, Type |
| Dye | Reporter dye; resolves to a detection channel and identifies the part in a multiplex run | Dye, Reporter, Reporter Dye, Channel, Fluor, Fluorophore |
| Replicate | Replicate number | Replicate, Rep, Replicate #, Replicate Number, Bio Rep |
| Sample type | Unknown, standard, control, etc. | Sample Type, Type, Content, Task, Category, Control Type |
| Quantity | Standard concentration | Quantity, Concentration, Conc, Std Conc, Standard Quantity, Input Quantity, Qty, Starting Quantity (SQ), Starting Quantity |
★ Required. All other columns are optional.
Instrument vendors use no common export format, so header names are matched case-insensitively against a list of known aliases; a column labelled "Ct Value", for example, is recognised as Cq. When the headers in a file cannot be recognised automatically, the source is flagged and its columns are mapped by hand instead of the import failing. Most instrument exports are read without modification.
Three of the optional columns (Dye, Sample type, and Assay type) are matched against fixed sets of recognised values rather than taken verbatim. All three tolerate missing or unrecognised entries instead of failing the import.
A file that annotates both samples and assays should label its two type columns explicitly, as Sample Type and Assay Type, since a bare Type header is read as whichever kind the table describes.
Dyes and detection channels
The export reports a dye: the reporter on the probe or reaction, the term used by MIQE and RDML. Each dye corresponds to a detection channel on the instrument, and on a multiplex well that reports several dyes, each dye becomes its own measurement (its own row in the export).
The Dye value on each row is matched, case-insensitively, against Clarida's recognised channels: FAM, VIC, HEX, CY5, CY5.5, SYBR, ROX, TAMRA, and Texas Red.
A value that does not match one of these is not rejected: the measurement is still imported, but assigned to the default channel (SYBR) and flagged with a warning. When no Dye column is present at all, the run is treated as singleplex and every measurement is assigned to that same default channel.
The dye also resolves which target a measurement belongs to. For a singleplex assay there is a single part, so this is unambiguous; for a multiplex assay, each measurement is matched to the part that uses its dye.
Sample types
The Sample type value classifies each well as a sample or a control. It is normalized case-insensitively, accepting common variant spellings:
| Type | Meaning | Recognised values |
|---|---|---|
| Unknown | An ordinary test sample (the default) | unknown, unkn, unk, sample, qsUnknown, wcSample |
| Standard | A standard-curve point; pairs with the Quantity column | std, standard, qsStandard, wcStandard |
| Positive | Positive control | pos, positive, positive control, positive template control, ptc, qsPositive, qsPosCalibrator, wcPosCtrl |
| NTC | No-template control | ntc, no template control, no-template control, no template, water, h2o, qsNegative, wcNTC |
| NAC | No-amplification control, omitting the polymerase (or, in RT-qPCR, the reverse transcriptase) | nac, no amplification control, no-amplification control, noamp |
| NRT | Minus-reverse-transcription (−RT) control | nrt, no rt, no-rt, -rt, rt-, minus rt, minus-rt, minusrt, wcNRT |
| NTP | No target present | ntp, no target present |
| Negative | A generic negative control, where the reason is not stated | neg, negative, negative control, neg ctrl, negctrl, neg_ctrl, wcNegCtrl |
| OPT | Optical calibrator | opt, optical calibrator |
The first eight are the sample types defined by the RDML data standard, several of which (NTC, NAC, NRT) are reproducibility-relevant controls under MIQE. A value that matches none of them, or a row with no Sample type at all, is treated as Unknown, and an unmatched value is recorded as a warning.
Prefer a specific negative control where you can. NTC, NAC, NRT and NTP each say why a well should stay clean (no template, no polymerase or reverse transcriptase, no RT step, no target), and that reason is what makes a signal interpretable: an amplifying NAC points at degrading probes, an amplifying NTC at contamination. Negative exists because instrument software often offers only an unqualified "Negative Control" alongside its NTC, and recording that verbatim is more honest than guessing which specific control was run. All five are treated identically in quality control: the well is expected to stay silent, and any signal is flagged.
Every type is viewable and settable in the Clarida interface. Sample type is not required for import, and wells left unclassified can be set later in the experiment.
Assay types
Sample type describes what was loaded into a well. Assay type describes what the assay measures, and the two are independent: a no-template control is a property of the sample, while a reference gene is a property of the assay. Both can appear in the same import, on their own columns.
Like sample type, the Assay type value is normalized case-insensitively, accepting common variant spellings:
| Type | Meaning | Recognised values |
|---|---|---|
| Gene of interest | The target being measured (the default) | gene of interest, gene_of_interest, goi, toi, target |
| Reference gene | A normalization target for relative quantification | reference gene, reference_gene, ref, reference, housekeeping, hkg |
| Positive control | An external positive control assay | positive control, positive_control, pc, ptc, pos_ctrl |
| Negative control | An external negative control assay | negative control, negative_control, nc, neg, neg_ctrl |
| Internal control | An in-sample control amplified alongside the target, validating that extraction and amplification worked for that sample | internal control, internal_control, iac, ic, ipc, endogenous control, extraction control |
The first two follow the RDML target types (toi and ref); RDML defines no control types, so the remaining three follow MIQE. The internal control, an internal amplification control (IAC) in MIQE terms, is distinct from both a reference gene and a positive control: it neither normalizes nor supplies template, but reports whether a sample was processed successfully. It is stored today; the per-sample quality control that acts on it is in development.
A value that matches none of these is not rejected: the target is imported as a Gene of interest and the unmatched value is recorded as a warning. When no Assay type column is present, every part is treated as a gene of interest.
Note that ntc is a sample type only. A target has no template to omit, so a negative-control assay is written as negative control or neg_ctrl.
Import, link, and reconcile
The importer has three steps, Import, Link, and Reconcile, that address three separate questions:
- Import: what data is in the file? A file is not always a single dataset. An Excel workbook may contain one sheet per run, several unrelated sheets, or sheets that hold no Cq data. The import step reads each file, and each sheet, as a candidate source, and parses the ones that are selected.
- Link: which run does the data belong to? An imported source carries measurements but no record of which run produced them. Linking assigns each source to a run defined in the design, or promotes it to a new standalone run when no designed run applies.
- Reconcile: which annotation applies where they differ? When a source is linked to a designed run, two annotations of the same wells exist: the one defined in the design and the one carried in the imported file. Matching wells are resolved automatically; conflicting wells are resolved by an explicit choice between the imported and the designed annotation.
One step without a design, three with one
Linking and reconciliation only have something to act on when the experiment carries a design, so the number of steps that need attention depends on the experiment.
In an analysis-only experiment, created to process data with no design, there is nothing to link or reconcile against. Sources are promoted to runs automatically and the file's annotation is used as recorded, so steps two and three complete without user action. The import is effectively a single step.
In an experiment designed in Clarida, with plates laid out and samples and assays named, the imported data is checked against that design, and that is where linking and reconciliation earn their place. Because both are explicit, the imported file does not have to match the design exactly: sample names that differ, a workbook holding several runs, or a re-run that replaces earlier data are handled by assigning and reconciling sources rather than by demanding a fixed file format or naming scheme. Each action is reversible, since a staged link can be cleared before it commits and a merged run can be reset, so corrections do not require restarting the import.
After reconciliation is committed, the imported Cq values are attached to their runs, and the experiment proceeds to quality control, normalization, and exploration.