Below is a list of the key terminology used throughout the Uncountable platform.
*As a note, all terms marked with an asterisk at the end can actually be re-defined by either a User for themselves or Admin for the whole company via the Language settings.
Experiment*
An experiment in Uncountable represents a unique record of a set of inputs and outputs associated with a unique ID, meant to encapsulate a formulation of ingredients, its process parameters, and all measurements taken for that formulation. A measurement can have multiple replicate samples associated with it, so if a recipe is made into 3 dogbones for tensile testing, you can record each measurement as a replicate of the same experiment.
Project*
A project is a folder in which experiments are grouped together, often made in pursuit of a goal or customer specification. Projects can have Child Projects, in a similar manner to folders in a standard desktop operating system like Windows. All experiments that exist in a Child Project, automatically are visible and editable from their parent project. Projects can also be set up and used for larger organization, like grouping all development from one region together or separating development experiments and production experiments.
Material Family*
A Material Family is the entity that projects reside in, acting as a division within a customer’s data for different chemistries or business lines. Material Families represent the high level of structure in Uncountable, and are often used to visually and functionally separate non-relevant experimental work. Experiments from different material families are not transferrable, but ingredients, process parameters, and outputs can be linked between material families to maintain equal information for each material family. For example, a compounding company may have PVC compounds in a different material family from TPU compounds.
Input*
Inputs are for all ingredients, process parameters and input calculations in the platform.
Ingredient*
An ingredient in Uncountable is to be used for any raw materials in the platform, where the commercial name of the ingredient is used (rather than a generic ingredient name like N550 or DINP).
Process Parameter*
Process parameters in Uncountable are used to capture critical information about how a formulation or composition on ingredients was processed. Typical process parameters including mixing speeds and times, or denote the name of a specific piece of equipment used. Process Parameters can be either numeric, text, categorical, or a date.
Output*
Outputs represent a collection of all properties or dependent variables in the platform, used for recording any measurements taken on experiments or during the processing of a sample. Outputs are used for properties like tensile strength, viscosity, and adhesion. Outputs can be numeric, categorical, text fields, dates, images, files, curves, color type formats (lab values) time series curves, and calculations. All outputs that are numerical in type are required to have a unit specified. Outputs belong to categories, and can have attributes associated with themselves.
Input Calculation*
Input calculations are used for creating calculations where the only variables in the calculations are dependent on input values (either ingredient or process parameters). Some examples of common calculations used for recipes are for formula cost, stoichiometric ratios, or just simple ratios.
Output Calculations are for calculations that incorporate some variable that includes a measurement value, but may also include features that are inputs, output metadata or condition parameters. Examples of output calculations could be the percent change in tensile strength over time, or a ratio of viscosities measured at different shear rates, or a reaction yield.
Input Groups can be used to add a set of Inputs (Ingredients and Process Parameters) that can be added in bulk, either while editing a recipe or defining a Step in a Workflow. Input Groups can be set up by the user in either the Inputs library, and can be made private or public.
Output Groups can be used to add a set of measurements with predefined condition parameters in bulk. Output Groups can be made either private, shared with all users, or shared with only specific users. Output Groups are commonly used to represent a set of measurements done frequently (like basic physical properties of hardness, tensile, and viscosity) or a set of measurements done at multiple aging times (like viscosity after 1d, 3d, and 7d). There is no limit to the number of measurements that can be used in an Output Group. Output groups can be referenced in Test Sample Templates and Workflow definitions.
Experiment Groups are an organizational method of clustering experiments into a nested Group on the dashboard. Users can reduce the number of line items available on the Project Dashboard by using Experiment Groups. Experiments Groups can be expanded on the Dashboard by clicking on the expand icon on the left side.
Notebook* Is an unstructured, free-form word processing document associated with a project and/or an experiment. Notebooks are currently used for project reports, as an experimental ELN, as a scrapbook for collecting visualizations and tables, as a dashboard for common visualizations, and as documents for future reference or context around the analysis done.
Recipes* are used in reference to an experiment’s set of ingredients and process parameters. When you are editing or creating a formulation’s composition, you are in the “Recipe Editor” view.
Measurements* are used in reference to an experiment’s recorded Output values. When the values of Tensile Strength are being typed into the platform, you are in the “Measurement Editor” view.
A Condition Parameter is a descriptor variable for how a measurement is conducted that differentiates one way an output is measured from another. For instance, how long a sample is aged should be listed as a Condition Parameter, or what substrate is used for adhesion tests. Condition Parameters are shared across outputs, and can be either text, numeric or date in type. A “default” set of Condition Parameters can be set up for any output, either on a user basis or material family wide.
Experiment Metadata* is used to collect and store information that isn’t a process parameter or relevant to the composition of a recipe. For example, the plant location or recipe date created may be listed in Recipe Metadata.
Measurement Metadata is used to collect and store information that is relevant to certain measurements, but not necessarily something that is meant to always visible or differentiate one measurement from another. Examples of Measurement Metadata may be the sample number, or the exact tray holder used. Measurement Metadata fields can be created in the Output library and then values can be edited in the Measurement Editor view.
An Ingredient Attribute is a descriptor of a raw material in the platform. The descriptor could be used for text, numeric, or PDF information. For instance, the following could all be an ingredient attribute: the supplier, the molecular weight, or the TDS. Ingredient attributes are 100% configurable by the user, and are searchable in all views and plottable in the visualization tools.
A Measurement Attribute is the measurement equivalent of ingredient attribute – meaning it could be a Test Method # or a full Test Method SOP document.
An Ingredient Category* is used to categorize all similar ingredients. The categorization of ingredients is crucial for all modeling exercises, and also acts as the 1st hierarchical ordering factor when sorting/organizing ingredients. Ingredient Categories can also be used in any filtering operation and visualization, like Fillers, or Plasticizers.
A Subcategory* is a more specific categorization of ingredients, most often used to group similar ingredients together within a category. For example, if you have a Category for Fillers, you would be able to make a Subcategory for Carbon Blacks and Silica Fillers to further differentiate the ingredients. You will be able to search, filter, and plot by Subcategories.
Experiment Tags are used to label experiments with a virtual “sticky note”. Tags are often used to group mini-experiments or studies together – for instance, if you have 15 experiments within one project that all look at some new filler, you could add a tag to those 15 experiments so you can easily filter or plot by the Tag. Tags are 100% configurable by the user. An experiment can have multiple tags, and tags can be shared across projects, or be made to only show for a single user.
Project Tags are used in a similar way to experiment tags, but at the project level. Project Tags can be used to link projects together, maybe showing all projects that are coordinated in a single region, or to mark certain projects as true development projects vs small localization projects.
A Lab Request* is designed as the main component of a trial request system, where a user can create a Lab Request with certain recipes and then request any measurements to be done to those recipes. Lab Requests can have any type of field associated with them for easy configuration and filtering. Further, individual measurements can be assigned and delegated within the Request manager.
A Lab Task is a simple reminder that can be used for smaller activities around the lab, like cleaning out a piece of testing equipment or taking a sample out of the oven after a certain amount of time.
Lots* differentiate the different batches of raw ingredients that are received from a supplier, usually with a unique identification number for each. For instance, if you buy carbon black from a supplier, most likely every shipment comes some sort of Lot #, a COA, and an expiration date that you may want to reference when using carbon black in an experiment. Lots can be created and stored in the platform directly, and they can have their own measurements – such as molecular weight or particle size, and are frequently used with our inventory module.
Mix Order is a recipe editing option that allows the user to create a completely custom order of operations for how ingredients are mixed together to create a recipe. Often used by paint formulators or compounders when defining what ingredients are added when, mix order can be turned on by the user, and then the user can drag and drop ingredients, process parameters and notes into any order possible.
Workflows* can be created to help a user define a complex recipe structure, such as a synthesis reaction with a monomer mixture, proportioning, and other steps are involved and critical to separate for instructional or mathematical purposes. Workflows are made up of named Steps, where things like the default ingredient units of each step and whether Mix Order is defined. Further, users can specify which input calculations are associated with the Workflow, which Product is associated with the Workflow itself or the products that used in individual Steps.
Steps can be used to separate parts of a recipe. For instance, if you have a 2K formula, you can use steps to define Part A, Part B, and the mix ratio. Or if you utilize a multi-stage compounding process, you can define Steps for each stage of the compounding process. Steps can be custom added by the users, or incorporated into Workflows.
Products* are utilized within the platform to represent the idea that there is a repeatable unit (either ingredient or experiment) utilized when creating/defining a recipe such that the user can reference the Product and/or specific instances of the Product in the form of lots or other component recipes. As an example, if the user is trying to develop a new coating for wood products, and there is a separate team that develops polymers for the coatings team to use an “ingredient” in their formulas, the user could define “Internal Polymer” as a Product of ingredient type. After selecting the Internal Polymer when formulating, the list of experiments presented to the coatings formulators is restricted to the polymer experiments as generated by the polymer team.
In a separate example, let’s say a company is making batteries. There may be a team that develops slurries, a team that develops electrodes, and a team that makes and tests cells. Each experiment that the slurry team uses to capture their recipes and outputs could be made into a Product “Slurry”, and that Slurry Product is now immediately referenable by the Electrode team directly in their Workflow when defining how they made that Electrode. A similar story would exist for the Cell team, who could now pull specific Electrode Products (Anodes and Cathodes could be different Products) into their Cell designs. The use of Products allow teams to work together seamlessly as they may develop different types of components or recipes for the larger organization.
Constraints work to define limits for inputs for any experimental suggestion. Within a Constraint, a user can define how often an ingredient should be used (always, sometimes, or never), and then define the bounds on that usage (minimum and maximum quantities). For instance, if you want to use a certain polymer in your formulas, but never more than 25% of the formula or less than 10%, you can define the constraint to be 10 -> 25%. Constraints can also include bounds on Process Parameters, Input Calculations, and complex ratios between ingredients or categories.
Specs* are a set of output goals that a user defines either for a project or a specific optimization target. A user can define a set of CTQs for a list of measurements, defining the priority level of that measurement, whether you want to maximize or minimize the measurement towards a specific value. For instance, if you want to design a set of experiments to have a Tensile Strength above 15 MPa and Elongation above 150%, you can define such goals in a Spec. Specs are required for any optimization job, and are used for objective search as well as coloring measurement values in the Compare Experiments view.
Test Samples* represent the idea of an aliquot or child sample of a parent Experiment, used when a specific unique ID is needed for traceability and naming. Test Samples themselves are Experiments, but they have an inherent link to the parent Experiment. When Test Samples are created, they are shown in the current project on the project dashboard, but their actual home location is designated upon template creation. Test Samples can be made via a Lab Request or directly from Enter Measurements.
Test Sample Templates represents the idea of a template set of inputs and outputs that automatically get associated upon the generation of a Test Sample (either via Lab Requests or on Enter Measurements). Test Sample Templates combine the idea of Input Groups and Output Groups, such that users can define which input fields (ingredients/process parameters) are present automatically, as well as which outputs (measurements and conditions) are present.