When initiating the execution of a program on an instrument, it is common to supply a list of samples intended for processing during the run as part of the StartProgram() method’s input arguments. Samples within this context are typically identified and tracked using their unique sample identifiers. These sample identifiers can take various application-specific or domain-specific formats, serving as representations of the materials (such as fluids, solids, cells, etc.) to be processed.

However, in most cases, the sample identifier itself cannot be directly associated with the sample, but rather it may be linked to a sample container. This container, whether it's a vial or a multi-well plate, encapsulates one or more samples and can be identified using human- and/or machine-readable codes like barcodes, QR codes, RFID, and similar technologies.

In real-world scenarios, there isn't always a straightforward one-to-one correspondence between a container's code and the sample identifier of the contained sample. Several variations exist, such as:

A single identifiable container containing multiple samples, including additional fluids like calibration standards or reagents. An example is a multi-well plate.

Certain processing steps within a workflow using a specialized instrument might require one sample to be divided among several containers due to volume constraints, with the possibility of pooling these samples back together at a later stage.

To address these diverse scenarios, the SampleInfoType offers multiple properties that can be better understood through illustrative examples provided in the subsequent sections.