Importing samples and assays
All methods · August 14, 2026 · Jan Hellemans
Before a plate is laid out or data is imported, an experiment needs to know which samples and which assays it contains. Both can be typed in, generated as a series, taken from your library, or pasted from a spreadsheet. Pasting is the fastest route for a real experiment, and it does more than carry names: a header row lets you set types, quantities and their units, positions and quality-control limits in the same paste, and any column Clarida does not recognise becomes a custom property on every row. That is how a property is set on many samples at once.
An experiment in Clarida is defined by the samples it measures and the assays it measures them with. Both are declared in the Design phase, in Sample prep and Assay prep, before a plate layout is generated or instrument data is imported.
This page describes how sample and assay lists get into an experiment, what a pasted table may contain, and how columns are interpreted. It is the design-side counterpart to Importing instrument data, which covers the Cq export produced after a run. The vocabulary used here (sample types, assay types, reporter dyes) follows the MIQE guidelines (Bustin et al., 2009) and the RDML data standard (Lefever et al., 2009).
Four ways to add samples or assays
Both sections offer the same input methods, chosen to match how the list already exists in your hands:
- Manual · Add rows one at a time and edit any cell inline. Suited to a handful of entries, or to correcting a list that is already there.
- Generate · Create a numbered series (
Sample 1,Sample 2, …) of a chosen length. Useful when names carry no information and positions do the work. Samples additionally offer a series variant for structured naming. - From library · Pick entries already stored in your workspace library. A library sample or assay carries its stored properties with it, so nothing is retyped.
- Paste · Paste a table from Excel, Google Sheets, or any tabular source.
Pasting is the route this page concentrates on, because it is the only one that transfers a whole experiment's worth of annotation in one action.
What a pasted table may contain
Pasted text is split into columns on tab, comma, or semicolon, whichever appears most often on the first line, defaulting to tab for Excel compatibility. A space is deliberately not a separator: sample names routinely contain spaces (Liver RNA), and treating them as column breaks would corrupt the names.
What Clarida does with the columns depends on whether the first row is a header row.
With headers, columns are matched by name, in any order, and the full set of recognised columns becomes available:
| Column | Description | Recognised by (aliases) |
|---|---|---|
| Sample name ★ | The sample identifier | Sample, Sample Name, Name |
| Sample type | Control role, see the sample types below | Type, Sample Type |
| Quantity | Input quantity / concentration, used for standards | Quantity, Concentration, Input Quantity, Qty |
| Unit | Unit for the quantity, defaults to copies/µL | Unit, Units, Concentration Unit, Quantity Unit |
| Position | Plate position (A1–P24) or a plate-fill index | Position, Pos, # |
| Expected Cq min / max | Acceptable Cq window for a positive control | Expected Cq Min / Max, POS Cq Min / Max, Min Cq, Max Cq |
| NEG Cq floor | Lowest Cq a negative control may show before it fails | NEG Cq Floor, Neg Cq Floor, Cq Floor |
| NEG dCq margin | Minimum dCq a negative control must clear | NEG dCq Margin, Neg dCq Margin, Min dCq |
★ Required. All other columns are optional.
Header names are trimmed and matched case-insensitively against the alias lists, exactly per alias rather than by substring, so an unlisted header is not auto-detected.
Without headers, the columns are read by position: first column sample name, second sample type, third quantity, fourth the unit that quantity is in. This is what makes a bare list of names work, since pasting one column of names turns each into a sample. Two further conveniences apply to headerless input. A single column of plain integers is read as positions, with names generated to match, and a list of names with no types is read as names alone.
The trade-off is worth stating plainly: only a header row unlocks positions, quality-control limits, and custom properties. A headerless paste can carry four things; a paste with headers can carry everything.
Custom properties: any other column
A column whose header matches none of the recognised names is not an error and is not discarded. It becomes a custom property on every row of the paste, named after the header.
This is the supported way to set a property on many samples at once. To record the tissue each sample came from, add a Tissue column to the table you are already pasting, and every sample receives its value in the same operation.
Before anything is written, a review dialog shows each column and what will happen to it:
- Matched column · Routed to the existing property it matches, and can be re-routed to a different one.
- Unmatched or type-mismatched column · Becomes a new experiment-local text property.
- Any column · Can be skipped.
The dialog is also what catches a mistyped canonical header. Smaple Name matches no recognised column, so it would otherwise quietly become a property called "Smaple Name" instead of filling the sample-name column. The review makes that visible before it lands rather than afterwards.
When a pasted name matches a sample already in the experiment, you choose whether to update the matching sample, the default since adding a property column to existing samples is the common case, or to create new samples, suffixing the collision.
Custom properties on paste are a Sample prep capability. Assay prep recognises its own columns, described below, and ignores any others. The library paste surfaces under Storage likewise take canonical columns only.
Assay columns and multiplex
Assay prep reads the same way, with headers matched by alias, or a positional fallback of name, dye, type, part name:
| Column | Description | Recognised by (aliases) |
|---|---|---|
| Assay name ★ | The assay identifier | Assay, Assay Name, Name |
| Target | Target gene / amplicon | Part, Part Name, Target, Target Name, Target Gene, Gene |
| Dye | Reporter dye (defaults to SYBR when blank) | Reporter, Reporter Dye, Dye |
| Assay type | Gene of interest, reference gene, or a control | Type, Assay Type |
| Quencher | Probe quencher (defaults to BHQ1 when blank) | Quencher |
| Position | Plate position (A1–P24) or a plate-fill index | Position, Pos, # |
★ Required. All other columns are optional.
A multiplex assay is written as several rows sharing one assay name. Each row becomes one part of that assay, distinguished by its dye:
| Assay | Target | Dye |
|---|---|---|
| FLU.RSV | Influenza | FAM |
| FLU.RSV | RSV | CY5 |
| FLU.RSV | RNase P | HEX |
Three rows, one triplex assay with three parts. Parts of one assay would normally each use a different dye. Sharing one is allowed, since pathogen panels legitimately do it, but is flagged as a warning because it is more often a mistake.
Assay type accepts gene_of_interest (the default), reference_gene, positive_control, negative_control, and internal_control, each with the aliases listed in the in-app help. Note that ntc is a sample type only: an assay has no template to omit, so a negative-control assay is negative control or neg_ctrl.
Sample types
The sample type classifies each entry as a test sample or a control. It is normalized case-insensitively after trimming, 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, pairing 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 |
A value matching none of these, or a row with no type at all, is treated as Unknown, and the unmatched value is recorded as a warning.
Aliases are matched per entity, not globally: ntc is a sample type, while a target control is negative_control. And an ambiguous token is deliberately not an alias, so cal is absent because it could mean a standard-curve point (std), an optical calibrator (opt), or an inter-run calibrator, which is not a type at all. Leaving such a cell unrecognised lets you choose rather than having Clarida guess.
These are the same types the instrument-data importer recognises. Importing instrument data describes why a specific negative control is preferable to a generic one.
Concentration units
A quantity is only meaningful with a unit, so the Quantity column pairs with an optional Unit column. Seven units are stored:
| Unit | Meaning | Recognised values |
|---|---|---|
| copies/µL | Copy concentration per microlitre (the default) | copies/µL, copies/uL, copy/uL, cp/uL, copies per uL, copies/microliter |
| ng/µL | Mass concentration per microlitre | ng/µL, ng/uL, ng per uL, ng/microliter |
| nmol/µL | Amount concentration per microlitre | nmol/µL, nmol/uL, nmol per uL, nanomol/uL |
| nM | Nanomolar | nM, nanomolar, nmol/L, nanomol/L |
| copies | A copy count with no volume | copies |
| fold | A fold change | fold, fold change, fold-change, x |
| dilution | A dilution factor | dilution, dilution factor, dil |
Matching ignores case and treats µ and u as the same character, so copies/µL and copies/ul are one unit. A quantity with no unit is stored as copies/µL, the most common case, without comment. A unit that is present but unrecognised falls back to the same default and is flagged as a warning, so a typo is visible rather than silent.
As with sample types, an ambiguous token is deliberately not an alias: a bare cp or copy could mean either copies/µL or the unit-less copies, so it warns instead of guessing.
Fold and dilution are opposites
These were one combined unit until recently, and separating them matters because they count in opposite directions. A standard at 10 000 fold is the most concentrated point on the curve; the same sample at 10 000 dilution is the least. A single label could not say which, so the number alone did not tell you which way the curve ran.
Clarida stores the concentration itself, which always rises with the amount of template: a 1:10 dilution is stored as 0.1. Entering and reading a dilution as 1:10 is a presentation of that same number, not a different one. Because the stored value never changes direction, calculations such as amplification efficiency never need to know which unit you chose.
The combined spellings — fold dilution, fold dil, fd — are no longer recognised for exactly this reason: they cannot be told apart from either sense, so accepting one would silently reverse half the standard curves that used it. They are flagged as unrecognised so you can state which you meant. Samples already saved under the old unit keep their stored value and label until you edit them.
nmol/µL is also new, and it is not the same as nM: nanomolar is per litre, so the two differ by a factor of a million. Both are offered because both are legitimate — the same relationship copies and copies/µL already have.
Where the definitions go next
Samples and assays declared here feed the rest of the Design phase. The plate layout is generated from them, and the resulting run defines which wells hold which sample-assay combination. When instrument data is imported afterwards, that annotation is what the imported file is reconciled against: a sample name in the export matches a sample defined here, and any difference is resolved explicitly rather than silently.
Definitions are not frozen once entered. Names can be edited inline, types and quality-control limits set in bulk from the sample list, and properties added at any later point, including by pasting another column onto samples that already exist.
