Recipe Version History With 30-Day Cpk Validation Per Change
By Larry Eilson on May 30, 2026
Somewhere on most plant floors, a recipe says one thing and the line runs another. A version label reads v3.2, but an engineer quietly nudged a mixing temperature two degrees last Tuesday "to make it run," and nobody can say what the parameter was before, who changed it, or whether the new value is even capable of holding spec. That gap — between the recipe that was approved and the recipe that is actually executing — is where quality drift, failed audits, and untraceable defects are born. iFactory's Recipe Parameter Change Audit closes it with a rule that sounds simple and changes everything: a version bump is not just a label. Before v3.2 is allowed to replace v3.1, the platform captures the exact before and after band for every parameter and validates the proposed change against the last 30 days of Cpk data. If the change cannot prove it stays capable, it does not go live. A recipe validation platform built this way makes "what changed and was it safe" a question you can always answer.
iFactory Recipe Parameter Change Audit
Recipe Version History With 30-Day Cpk Validation Per Change
Every parameter change shows its before/after band, names the requestor and approver, and is validated against 30 days of capability data before it is ever allowed to go live.
On paper, most sites "have recipes." In practice those recipes live in three places at once: a spec in QA, a set of parameters in automation, and a pile of tribal knowledge in the heads of the night shift. A simple version number papers over all of it. It tells you a change happened — not what moved, not by how much, not who decided, and crucially, not whether the new setting is still capable of producing in-spec product. That is the difference between a label and an audit.
Version Label Only
A Number That Explains Nothing
"v3.2" with no record of which parameter moved or by how much
Engineers tweak PLC set-points after deployment with no trace
No proof the new value can actually hold specification
An auditor's "what changed and why" can only be answered by interview
Change Audit + Cpk Gate
A Record That Proves It
Exact before/after band captured for every parameter touched
Set-points locked; overrides require a reason and an approval
Validated against 30 days of Cpk before the change can deploy
Requestor and approver named — reconstruct history from records alone
What the Change Audit Captures
Every parameter change is recorded as a complete, self-contained story — not a diff buried in a log. This is the anatomy of a single change record, the unit of evidence an inspector or a quality engineer reads to understand exactly what happened.
Change Record — Mixing Temperature
v3.1 to v3.2
Parameter
Mixing temperature set-point
Before band
72.0 ± 1.5 °C
After band
74.0 ± 1.0 °C
Requestor
Process Engineering
Approver
Quality (e-signed)
Reason code
Yield optimization
30-day Cpk check
1.41 — PASS, change allowed
Timestamp
Captured, immutable
The 30-Day Cpk Gate — How It Works
This is the mechanic that sets the feature apart. A capability number quoted on a fresh, hand-picked sample is choreography; capability that survives a real audit window is evidence. So before a parameter change is allowed, iFactory pulls the actual production data from the last 30 days, recomputes capability against the proposed band, and only lets the change proceed if the process stays capable. A change that would quietly push Cpk below the threshold is stopped at the gate — not discovered three weeks later in a deviation.
Proposed Change Validated Against 30 Days of Live Cpk
Live Cpk — recomputed against the proposed parameter band over 30 days
The gate — stay above the threshold and the change deploys; fall below and it's blocked
Built Like a Validated System Should Be
A change-control feature is only as good as the rules it refuses to break. iFactory's recipe audit is built to pass the same behavior tests a validated, regulated system is held to — the controls that turn "we have recipes" into "we can prove what ran."
Immutability
An effective recipe version cannot be edited in place — a change is always a new, traceable version, never a silent overwrite.
Approval Enforcement
No change deploys without the required approval. The requestor proposes; a separate approver signs. The gate is not optional.
Segregation of Duties
Self-approval on a controlled change is blocked — the person making the change cannot be the only one signing it off.
Batch Locking
Start a batch on v3.1 and deploy v3.2 mid-run, and the running batch stays on v3.1 — no version swap under a live batch.
Execution Binding
Runtime set-points come from the approved version and are not editable on the operator screen — what's approved is what runs.
Complete Audit Trail
Old value, new value, user, timestamp, and reason on every change — tamper-evident and reconstructable without interviews.
Want to see the Cpk gate block a non-capable change live? Book a 30-minute walkthrough and we'll run a real before/after band against your own capability data.
Reading the Lineage of a Recipe
Because every change is a versioned record, the full lineage of a recipe becomes a readable timeline — each step showing what moved, who signed it, and whether it cleared the capability gate. This is how you answer "why is the process set where it is?" in seconds instead of a forensic investigation.
v3.0
Baseline mixing temp 72.0 ± 1.5 °C
Established · Cpk 1.36
v3.1
Tightened tolerance band, same target
QA approved · Cpk 1.38 PASS
v3.2
Target to 74.0 ± 1.0 °C for yield
QA approved · Cpk 1.41 PASS
What This Changes for the Team
The payoff is not just a tidier log. It removes a whole category of risk — undocumented drift, failed-audit scrambles, and the slow erosion of capability that nobody notices until a batch fails. The value lands differently for each role that touches a recipe.
Quality
Walks into an audit able to reconstruct every change from records alone — before/after, who, when, why, and the capability proof behind each one.
Process Engineering
Proposes optimizations with confidence, knowing the gate catches a change that would quietly erode capability before it reaches the floor.
Operations
Runs exactly the approved version — no shadow tweaks, no "the night shift does it differently," no version swap under a live batch.
Every recipe change becomes evidence instead of a mystery. Want it configured to your parameters and capability targets? Talk to our quality engineers.
Frequently Asked Questions
What exactly does the 30-day Cpk validation do?
Before a parameter change is allowed to deploy, the platform pulls the last 30 days of actual production data and recomputes process capability against the proposed band. If the change keeps the process capable — above your Cpk threshold — it proceeds; if it would push capability below the line, the change is blocked at the gate. It turns "we think this is fine" into a validated, data-backed decision before the change ever reaches the floor.
Why a 30-day window specifically?
A capability number from a fresh, hand-picked sample proves little — it can hide normal variation, shift changes, and lot-to-lot differences. A 30-day window includes routine variation across shifts and material lots, so the Cpk it produces is evidence that survives an audit rather than a single favorable snapshot. The window reflects how the process really behaves, not how it behaves on its best afternoon.
What does the before/after band capture that a version number doesn't?
A version number tells you a change happened; the before/after band tells you exactly what moved — the prior set-point and tolerance versus the new ones, parameter by parameter. Paired with the requestor, approver, reason code, and timestamp, it makes each change a complete record. An inspector can reconstruct what happened by reading records, not by interviewing the night shift.
Can someone bypass the gate by editing the live recipe directly?
No — that's what immutability and execution binding prevent. An effective version can't be edited in place; any change creates a new version that must clear approval and the Cpk gate. Runtime set-points are bound to the approved version and aren't editable on the operator screen, so the recipe that was approved is the recipe that actually runs.
What happens to a batch already running when a new version deploys?
It stays on the version it started with. Batch locking means deploying v3.2 mid-run does not swap the running batch off v3.1 — the batch finishes on its approved version, and the new version applies to subsequent batches. This prevents a mid-batch parameter change from silently altering product that's already in process.
A Version Bump Should Have to Prove Itself.
See the Cpk Gate Validate a Real Change — in 30 Minutes
Bring a recipe change you'd normally make on instinct. We'll capture the before/after band, run it against 30 days of your capability data, show the gate pass or block it, and walk the full version lineage with requestor and approver on every step.
