Glossary#

Workflow#

An Orchestration Python script which carries out a lab process using a set of manual and automated steps.

Job#

A single execution of a Workflow. A Job is created when a Workflow is run and contains the complete record of what happened during that run. For example, you might have a Workflow that defines how to run a fitness assay in your lab, and 3 jobs that represent actually running the assay this morning, yesterday, and last week.

Request#

A Request is a Job very early in its life cycle. Conceptually a Request represents a desire for a workflow to be executed, And contains all the relevant scientific parameters and variables needed to execute that workflow. Requests are created in LabOps or through an integration with a LIMS or ELN. To optimize equipment utilization, requests can be batched together into a single job before execution.

Adapter#

An Adapter is a bundle of code that allows a workflow to interact with the systems and hardware in your lab. In production, the Adapter runs on the IPC that we install in your lab as part of customer on-boarding so that it can access devices on your internal network. During development, the adapter runs directly in your development environment, whether that’s code space or your local machine.

IPC#

The Artificial IPC is a small industrial-grade computer that we install in your lab as part of customer on-boarding so that the Adapter can access devices and systems on your internal network. We have a lot of experience and guidance working with IT departments to set this up in both large enterprise contexts and small startups. Please reach out to support@artificial.com for more details or a white paper on what to expect.

Plugin#

A Plugin is a python class that inherits from ActionModulePlugin and handles administrative tasks for an Adapter, including registering Action Modules, Resouces, and Health Checks, as well as managing the Adapter Configuration values.

Action Module#

An Action Module is a python class that inherits from ActionModule and defines one or more Actions that can be run by a Workflow. Action Modules are intended to encapsulate all the logic, state, and configuration needed to run a set of Actions in your lab, including managing Resources or other connections to external systems.

We recommend that you create one Action Module for each type of device or system that you need to interact with in your lab. For example you might have an Action Module for your liquid handler, another for your plate reader, and another for your LIMS.

Resource#

A Resource is a python class that inherits from ResourceBase. Resources are used by action modules to manage a connection and syncing digital twin status with a physical device.

Action#

An Action is a method defined on an Action Module and decorated with the @action decorator. Actions are the fundamental unit of work in a Workflow, and are intended to encapsulate a single step in a lab process. For example, you might have an Action that tells a liquid handler to dispense a certain volume of liquid into a certain well of a plate, or an Action that tells a plate reader to take a measurement of a plate.

Actions must be associated with an Ability. For more information on Actions, Actors and Abilities, see How An Action Gets Executed.

Actor#

An Actor is an abstraction defined in the Adapter configuration and represents a collection of Abilities. We recommend that you configure one Actor for each type of system you’ll need to interact with in your lab. For example, you might have an Actor called liquid_handler that represents all the liquid handlers in your lab, and an Actor called plate_reader that represents all the plate readers in your lab.

For more information on Actions, Actors and Abilities, see How An Action Gets Executed.

Ability#

An Ability is an abstraction defined on an Actor and represents a thing that an external system can do. For example, a liquid handler might have an ability called handle_liquid, and a plate reader might have an ability called read_plate.

Abilities also have a capacity, which is the maximum number of times Actions linked with the ability can be used simultaneously. Capacity is used to prevent two workflows from trying to Do the same thing at the same time. For example, if you have a “Do Science” Workflow that calls a run_hamilton_protocol Action associated with a handle_liquid Ability with capacity 1, then if you run two “Do Science” jobs at the same time, the first job’s call to run_hamilton_protocol must complete before the second job’s call to run_hamilton_protocol can start.

For more information on Actions, Actors and Abilities, see How An Action Gets Executed.