Skip to main content

Constraints

Note about BayBE
Catalyst uses BayBE under the hood. BayBE may evolve over time. This page explains parameters in non-technical terms as they are used in Catalyst today. For the detailed technical reference that Catalyst is aligned with, see the BayBE 0.13.2

Experiments in Catalyst use constraints to describe what is allowed, safe, or practical. This page summarizes BayBE's ideas on constraints in non-technical language and explains how they appear in the Constraint step of the Create Experiment wizard.

Constraints describe what is allowed, safe, or practical. They prevent BayBE from recommending trial settings you cannot (or should not) run. In BayBE terms, constraints restrict the feasible region of the search space.

Where you see constraints in Catalyst​

In the Create Experiment wizard, constraints are configured in the Constraints step.

Create Constraints Screenshot

Constraints are optional:

  • If you don’t add any constraints, you can still run the experiment.

In Catalyst:

  • Single-parameter limits (for example, oven temperature between 150 and 200 deg C) are usually encoded as parameter ranges in the Parameters step, not as constraints.
  • Constraints in the UI always involve two or more parameters, such as "A + B ≤ 100" or "if X then not Y".

What makes the Constraints step "invalid"​

  • If constraints exist, block progress when any constraint has validation errors (missing parameters, impossible rule, malformed expression, etc.).
  • If there are no constraints, the step should be valid.

What is a constraint?​

A constraint is a rule that determines whether a proposed combination of parameter values is valid.

Examples that match the UI:

  • "A + B ≤ 100" (combined sum of two parameters)
  • "If catalyst is X, solvent cannot be Y" (dependency/exclusion between two categorical parameters)

Common constraint styles​

Keep these as the user-facing mental model:

  1. Simple bounds (via parameter ranges)

    • Limits on a single parameter (min/max)
    • Configured in the Parameters step, not in the Constraints step

  2. Combined rules (via constraints)

    • Relationships across multiple parameters
      Examples: sum/product limits, dependencies, exclusions.

Everyday example (how to think about it)​

Using the cake example from the Concepts page:

  • Oven temperature (150–200 °C)

    • Define this as a continuous parameter named oven_temperature in the Parameters step.

  • Baking time (20–35 minutes)

    • Define this as an integer parameter named baking_time in the Parameters step.

  • White sugar (0–300 g)

    • Define this as an integer parameter named sugar_white in the Parameters step.

  • Brown sugar (0–300 g)

    • Define this as an integer parameter named sugar_brown in the Parameters step.

Those are simple bounds on a single parameter each, so they live in the Parameters step.

Now add a rule that combines two parameters:

  • Total sugar (white + brown) must be at most 300 g

This rule cannot be expressed as a bound on a single parameter, because it depends on the relationship between two parameters.
Therefore, it belongs in the Constraints step.

In the UI, you would:

  • Select sugar_white and sugar_brown as the parameters
  • Choose a sum constraint
  • Set the maximum value to 300 g

This is the kind of rule Catalyst’s Constraints step is designed for: tying parameters together in ways that parameter ranges alone cannot capture.

Why constraints matter​

  • Safety: avoid dangerous operating regions
  • Feasibility: avoid impossible combinations
  • Efficiency: reduce wasted trials and focus learning where it matters

Practical tips​

  • Encode hard safety/equipment rules as either tight parameter ranges or explicit constraints when they involve multiple parameters.
  • Avoid making constraints so strict that almost nothing is allowed.
  • If constraints change mid-experiment, document why (it changes what can be explored).

Further reading​