4.1. Getting Started

The Citrine Platform provides tools to make data-driven decisions for materials research and development using artificial intelligence (AI) workflows. AI Workflows are composed of modules, which provide the ability to programmatically codify domain knowledge, research capabilities, and experimental objectives. Workflows leverage data and domain knowledge to help materials researchers make traceable, data-driven decisions in pursuit of their research and development goals. These capabilities include generating candidates for Sequential Learning, identifying outliers, or imputing missing values.

4.1.1. Workflows Overview

Currently, there are two workflows on the AI Engine: the DesignWorkflow and the PredictorEvaluationWorkflow. Workflows employ reusable modules in order to execute. There are three different types of modules, and these are discussed in greater detail below.

4.1.1.1. Design Workflow

The DesignWorkflow is the core AI workflow on the platform. This workflow generates scored candidates for Sequential Learning. It executes in the following manner:

  • Material candidates are pulled from the design space.

  • The predictor adds additional information to the candidates.

  • Enriched candidates are scored.

  • The Citrine Platform selects the next batch of candidates to pull from the design space.

After a given number of iterations, candidates are ranked according to their score and the best materials are returned. (Here, the best materials are those that are most likely to optimize an objective and satisfy a set of constraints.)

Design workflows are further parameterized by Scores, which codify experimental objectives and constraints on desired candidates, and define the strategy for candidate acquisition.

4.1.1.1.1. Branches

A Branch is a named container which can contain any number of design workflows, and is purely a tool for organization. If you do not see branches in the Citrine Platform, you do not need to change how you work with design workflows. They will contain an additional field branch_id, which you can ignore.

4.1.1.2. Predictor Evaluation Workflow

The PredictorEvaluationWorkflow is used to analyze a Predictor. This workflow helps users understand how well their predictor module works with their data: in essence, it describes the trustworthiness of their model. These outcomes are captured in a series of response metrics.

4.1.2. Modules Overview

Modules are re-usable computational tools used to construct workflows. The modules dictate how the platform utilizes research data to generate computational results. There are 2 types of modules on the platform:

  • Design Spaces define the domain of controllable experimental parameters, their allowable values and relevant bounds.

  • Predictors define relations between variables in a table of experimental data.

    A predictor can be composed of machine-learned models, featurizers, and analytical relations.

4.1.2.1. Archiving

Modules and workflows start active by default when created. An archived resource will not show up when listing, and an archived module cannot be used in workflows. To archive a resource with a known uid, use the .archive() method of the relevant collection (e.g., DesignWorkflowCollection.archive()). Use .restore() to un-archive the resource.

4.1.3. Registration and validation

Both modules and workflows are registered with a project and validated before they are ready for use. Once registered, validation occurs automatically. Validation status can be one of the following states:

  • Created: The module/workflow has been registered with a project and has been queued for validation.

  • Validating: The module/workflow is currently validating. The status will be updated to one of the subsequent states upon completion.

  • Invalid: Validation completed successfully but found errors with the workflow/module.

  • Ready: Validation completed successfully and found no errors.

  • Error: Validation did not complete. An error was raised during the validation process that prevented an invalid or ready status to be determined.

Validation of a workflow and all constituent modules must complete with ready status before the workflow can be executed.

4.1.3.1. Experimental functionality

Both modules and workflows can be used to access experimental functionality on the platform. In some cases, the module or workflow type itself may be experimental. In other cases, whether a module or workflow represents experimental functionality may depend on the specific configuration of the module or workflow. For example, a module might have an experimental option that is turned off by default. Another example could be a workflow that contains an experimental module. Because the experimental status of a module or workflow may not be known at registration time, it is computed as part of the validation process and then returned via two fields:

  • experimental is a Boolean field that is true when the module or workflow is experimental

  • experimental_reasons is a list of strings that describe what about the module or workflow makes it experimental