Manufacturing Recipe Version Control

What is a manufacturing Recipe Version?

A Recipe is the stable identity for a setup, such as Product A on Extruder 3. A Recipe Version is a numbered snapshot of that identity's parameter values and notes at a particular point in its lifecycle.

This distinction matters because “create a new Version” and “create a new Recipe” mean different things. A new Version proposes a change to the same controlled setup. A new Recipe creates a separate business identity, usually for a different Machine/Product relationship or purpose.

A practical Recipe Version lifecycle

Each row reads from the current state, through an action, to the resulting state.

A Draft is the editable working state. Submission freezes it for review as Pending Approval. An authorized reviewer can approve it or return it to Draft with feedback. Once approved, the Version becomes the open-ended Current approved Version for that Recipe.

When a later Version is approved, the prior Current Version becomes Superseded. It stays in history, but it is no longer Current. A Draft, Pending Approval, or Approved Version may also be Retired when the organization needs to close it without replacing it through normal approval.

Different manufacturers may use different names or more review steps. What matters is a clear boundary between working values and the values the organization recognizes as Current.

What makes a Recipe Version Current?

Current should be an explicit controlled status, not an assumption based on a filename, modified date, or version number. The highest Version number might still be Draft. A more recently edited file might never have been approved.

In Summit, the Current Version is the one Approved Version for a Recipe whose effective period remains open. The system enforces at most one such Version. Approval of a later Version closes and Supersedes the former Current Version as part of the same transition.

Why should Approved Versions be immutable?

If an Approved Version can be edited in place, history stops representing what was approved. A displayed approval could appear to cover values the reviewer never saw.

Immutability solves that ambiguity. To change a value, create a new Draft Version. The Approved snapshot stays intact. The new proposal receives its own comparison, summary, submission, and approval evidence.

In Summit, Recipe fields and parameter values are editable only while the Version is Draft. Pending Approval, Approved, Superseded, and Retired Versions are protected from ordinary edits. This does not mean a plant can never correct a setting. It means the correction becomes a traceable new Version.

Compare Current vs. proposed values

A useful review should surface what changed without asking the reviewer to scan every unchanged parameter. Consider a proposed change for a drying process:

The comparison is only part of the review. The engineer should also record a clear change summary, such as “Reduce incomplete cure observed during controlled trial.” Notes can explain parameter-specific context. Creation, submission, return, approval, and effective timestamps show how the Version moved through the workflow.

Summit provides a Current-versus-proposed review comparison and Recipe history views. A reviewer can focus on additions, removals, and changed parameter values, then return the Version to Draft or approve it according to the organization's permissions and self-approval policy.

What should Recipe history preserve?

• The stable Recipe identity and its Plant, Machine, and Product.
• Every numbered Recipe Version and lifecycle status.
• The values, units, and notes associated with that Version.
• Who created, submitted, approved, returned, or retired it, where applicable.
• When those actions occurred.
• The reason or summary for the change.
• Which Version a later approval Superseded.
• Any source Change Request connected to a resulting Draft.

History should answer both “what value did we use?” and “how did that value become Current?” Those are related but different questions.

Why Git-style source control is not the same thing

Git is excellent source control for text files and software. It records commits, branches, authors, and differences. Engineering teams can use it effectively for PLC source, configuration-as-code, and related technical assets.

Manufacturing Recipe control adds a different business context. Production users need Plant, Machine, Product, Parameter definitions, units, validation rules, Recipe status, effective periods, manufacturing roles, and an approval workflow. They often need to review a few changed values without understanding branches or merge operations.

Git and Recipe management can coexist. One should not be presented as a poor version of the other. They control different artifacts and serve different users.

Connect Version control to change control

A request to change a Recipe is not itself a new Current Recipe. It can describe the problem, proposed values, and reason. After review, it may produce a Draft Recipe Version. That Draft still moves through its own completeness, submission, and approval workflow.

This separation prevents an approved idea from being mistaken for an approved production configuration. Read the manufacturing Recipe change-control model for the full sequence.