Best Practices for Using Cookbooks

Prev Next

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.