Best Practices for Using Cookbooks

Run Settings

• Set Top Runs significantly lower than the total available runs to ensure meaningful comparisons.
• Define run boundaries carefullyto capture true production periods—especially for continuous processes.
  • Use shift changes for historical analysis.
  • Use campaign-based boundaries (e.g., flavor, color, packaging) where applicable.
  • If no boundary exists, add a field called production date to the pipeline and use day as a boundary condition.
• Align run quantification with the client’s process (e.g., wheel type or unit of production).

Conditions

• Choose condition fields that result in a sufficient number of runs per recipe—avoid over-bucketing.
• Avoid creating too many conditions, as this can lead to recipes with insufficient data points.
• Do not presuppose conditions (e.g., shift, flavor, speed) unless requested—validate run settings first.
• Skip product selection during cookbook creation unless products truly differ in outcomes or logic.
  • Instead, configure product as a condition when appropriate. Instead, configure product as a conditionwhen appropriate.
    • If there are other significant conditions, use product selection to avoid too many factorial outcomes in conditions.
• Use uncontrollable variables (e.g., humidity, wind speed) as conditions or filters, not levers.
  • Use wisely, or you will end up with too many conditional options due to a factorial approach. Remove any conditions that have minimal impact.

Outcomes

• Use top-level KPIs (e.g., OEE) as primary outcomes when deploying cookbook insights to production.
• Add secondary KPIs (e.g., quality, efficiency) as 0-weight outcomes if needed for insight.
• Ensure outcomes are realistic, production-aligned, and defined with specific, normalized metrics
• Do not select metrics which are optimized by switching plant off.  (e.g., decrease steam)
• Confirm outcome metrics are not better suited as conditions or filters.

Levers

• Start broadly, then narrow to 20–30 meaningful leversto avoid confusion.
  • Consider creating two cookbooks: one for engineers with more levers, and one for operators, where 20–30 levers is typically the maximum they should see.
• Use lever insights to identify and retain the most influential levers.
• Remove levers that never change, cannot be controlled by operators, or represent duration, counters, or status values.
  • Levers can be determined if they can be changed typically through conversation with SMEs, PID loop tagging such as PV vs SP, or shape of data
• Common effective levers include temperature, pressure, and setpoints.
• Levers should be operator-controllable, variable, and directly influential on production outcomes.

Filters

• Use filters to exclude unwanted data (e.g., unsafe or noncompliant runs).
• Apply filters before or after scoring runs as appropriate to control what data appears in results.

Limits & Alerts

• Configure limits to reflect realistic standard deviations, warnings, and alarms.
  • The SD limits can also be changed, as well as the numerical values. Numerical minima and maxima can be hard-set (e.g., to limit to a new safety parameter).
• Adjust limits based on natural process variability, operator and engineer input, and technical documentation or machine manuals.
  • Spend sufficient time on this—frequent alerts on highly variable fields will quickly erode operator trust in the cookbook.
• Well-tuned limits ensure alerts are meaningful and actionable.

Date Range Selection

• Limit historical data to periods after major plant updates or overhauls to prevent outdated processes from skewing results.