Manufacturing Recipe Change Control

Recipe change control is a human workflow problem

A process deviation rarely begins as a clean software transaction. An operator may notice incomplete cure, a controls engineer may find an incorrect timer, or a process engineer may learn that one Machine needs a different setting for the same Product.

The person who sees the problem may not own the approved Recipe. The person who prepares the technical solution may not be the appropriate approver. The approved change may need to wait for a trial, scheduled run, customer decision, or internal review.

Without clear stages, “approved,” “changed,” and “Current” can mean different things to different people. A chat message may approve an investigation while someone else interprets it as permission to update production values.

One practical Recipe change-control model

1. Request the change. Record the affected Recipe, Current base Version, proposed parameter changes, reason, and useful timing or priority context.
2. Review the request. An engineer or other authorized reviewer compares Current and requested values and checks whether the request is technically understood.
3. Accept, return, or reject the request. A request may need more evidence, different values, or no implementation.
4. Create a Draft Recipe Version. An accepted request can produce a Draft based on the approved Version. The request and resulting Version remain connected.
5. Adjust and validate the Draft. An engineer completes any needed Recipe Parameters, notes, and change summary. Values are checked against their definitions.
6. Submit the Version. The Draft moves to Pending Approval and becomes protected from ordinary editing during review.
7. Approve or return the Version. An authorized person compares Current and proposed values, then approves or returns the Version to Draft.
8. Make the approved Version Current. Approval opens the new Version's effective period and Supersedes the former Current Version.
9. Keep the previous Version in history. The prior values, context, and approval evidence remain available.

Some plants will combine steps. Others will add trials, quality review, electronic signatures, work orders, or scheduled effective dates. A change to an advisory setpoint may need less control than a critical process parameter. The model should reflect the operation's real risk and responsibility.

Why separate request, Draft, approval, and Current?

Each stage answers a different question. Should we investigate or pursue this change? What exact configuration would result? Has an authorized reviewer accepted that configuration? Which approved Version is Current?

Separating the stages reduces ambiguity during handoffs. It also lets an operator propose a change without granting direct authority to edit approved engineering information.

Approving a Change Request does not necessarily change the production Recipe

Request approval can mean “this proposal is accepted for implementation.” It does not necessarily mean “these values are now the Current Recipe.” There may still be required fields to complete, parameter validation to resolve, or a separate reviewer to approve the implemented Version.

In Summit, implementing an Approved Change Request creates and populates a Draft Recipe Version. The request then becomes Applied. The resulting Draft must still be submitted and approved through the Recipe Version lifecycle before it becomes Current.

This distinction is intentionally visible. A team can trace the request to its resulting Draft without treating request review as Recipe approval.

Example: an operator notices a process problem

An operator sees incomplete cure on Product A running on Press 2. The Current Recipe uses a cure temperature of 175 °C and a hold time of 42 seconds.

1. The operator requests 178 °C and records the observed defect and batch context.
2. A process engineer reviews the Current base Version and the proposed temperature change.
3. The engineer returns the request because the hold time also needs to be evaluated.
4. The operator and engineer update the proposal to 178 °C and 45 seconds with the trial reason.
5. An authorized reviewer approves the request for implementation.
6. Implementation creates a Draft Version based on the Current approved Version.
7. The engineer checks all required parameters, records the trial summary, and submits the Draft.
8. Another authorized reviewer compares the two changed values and approves the Recipe Version.
9. The new Version becomes Current. The 175 °C and 42-second Version remains Superseded history.

The values are illustrative. The appropriate technical validation and authority depend on the actual process.

Match roles to the way your plant works

Not every customer needs Operator-originated requests. A plant might allow only engineers to create requests, or may receive proposals through an existing maintenance or quality system. What matters is that the approved Recipe is not changed through an informal side channel.

Summit's role model allows active Operators, Engineers, and Client Administrators to create and submit Change Requests. Engineers and Client Administrators can review and implement them, subject to the organization's configured self-approval policy. View-only users can see information without receiving mutation authority.

For Recipe Versions, Engineers and Client Administrators can create Drafts, edit, submit, review, approve, and retire according to lifecycle and self-approval rules. Platform-wide support access does not by itself grant direct client mutation authority.

What evidence should follow a change?

• The Recipe, Machine, Product, and approved base Version.
• The Current and proposed parameter values.
• A clear reason for each significant change.
• The requester, submitter, reviewer, and implementer where applicable.
• Submission, review, implementation, and Recipe approval times.
• Review feedback, returns, rejections, or cancellation reason.
• The resulting Draft and its later Recipe Version status.
• The previous Current Version after it becomes Superseded.

The goal is not to collect text for its own sake. It is to let a future engineer understand what happened without reconstructing the decision from email, memory, and file timestamps.

Change control and Version control work together

Change control manages the proposal and decision path. Manufacturing Recipe Version control protects the exact configuration and its lifecycle. One can exist without a separate request process, but a new Current Recipe should still be connected to a controlled Version.

For a broader view of ownership, parameter structure, and spreadsheet tradeoffs, read the Manufacturing Recipe Management guide.