A maintenance shift replaces a failing lamp with a unit of a different colour temperature, or re-shims a conveyor by two millimetres to stop a jam. Mechanically the job is closed out the same evening. For the inspection model running above that conveyor, the world just changed — and nothing in the reliability pack knows it. A physical-environment change on the line is a model change, and it should enter the same change-control queue.
That is the whole procedure in one sentence, but the sentence hides the interesting part: which changes count, what a re-baseline actually involves when you cannot stop the line for half a day, and who is allowed to say the line may restart. This piece is the change-control procedure for the reliability artefacts — not a description of what those artefacts are. For the artefact inventory itself, see the reliability artefacts an industrial CV inspection pack needs.
Why does a lighting retrofit break a reliability pack that reports green?
Because the pack is usually pinned to the wrong thing. Version pinning, in most deployments we see, records the model weights, the container image, and maybe the preprocessing config. All three are unchanged after a lamp swap. Every dashboard stays green while the input distribution the model is scored against has moved underneath it.
The baselines are the specific casualty. A drift monitor computes distance from a reference distribution; if that reference was captured under 4000K lighting and the line now runs at 5000K, the monitor either fires continuously (and gets muted within a week) or was tuned loosely enough that it never fires at all. The golden image set has the same problem: it now describes a line configuration that no longer exists, so a regression run against it certifies nothing about today’s parts.
Reliability artefacts pinned only to model weights will report a healthy system while the physical line drifts away from the conditions those artefacts describe. That is the divergence point. Packs pinned to line state force an explicit, dated re-validation decision instead.
The economic argument is short. On lines that route lighting and fixturing changes through a pack re-validation step, measurement trust is recovered inside the same shift as the retrofit — rather than several days spent arguing whether a rejection-rate shift is real product variation or an uncalibrated camera (observed across TechnoLynx industrial-CV engagements; not a published benchmark).
Which changes trigger a re-validation, and which are log-only
Not every physical change deserves a re-baseline. Treating them all as triggers produces a queue nobody works, which is functionally the same as having no procedure. The useful split is whether the change can plausibly move pixels inside the inspection region of interest.
| Change event | Classification | Required action before restart |
|---|---|---|
| Lamp replaced with different colour temperature, CRI, or diffuser | Trigger | Re-baseline capture, threshold recompute, golden-set extension |
| Ambient light path altered (bay door, skylight blind, adjacent cell lighting) | Trigger | Re-baseline capture; recompute only the illumination-sensitive drift channels |
| Fixture swapped, shimmed, or re-machined | Trigger | Re-baseline capture, ROI/geometry check, golden-set extension |
| Camera or lens remounted, refocused, or re-aperture’d | Trigger | Full re-baseline; treat as equivalent to a sensor change |
| Conveyor speed step change | Trigger if it changes motion blur or presentation timing | Re-baseline at the new speed; verify exposure margin |
| Like-for-like lamp replacement, same part number | Log-only | Record event, model version, timestamp; no capture |
| Guarding, walkway, or cabling change outside the optical path | Log-only | Record event only |
| Routine lens cleaning on the existing schedule | Log-only | Record in maintenance log; escalate if cleaning restores a drift signal |
The log-only column is not a dead letter box. When an unexplained rejection-rate excursion appears three weeks later, the log is the only artefact that lets anyone correlate it with a “harmless” change. Two of the most useful metrics for this whole procedure are re-baseline turnaround per change event and the number of unexplained rejection-rate excursions that were eventually traced to an unlogged physical change.
Taking a re-baseline without giving the line back to manual inspection
The objection is always time. A plant will not hand over ninety minutes of takt for an image capture, and it should not have to.
A workable capture runs in the ramp-up window that follows the maintenance job anyway — the first parts through after a retrofit are already being watched. The steps:
- Capture in shadow mode. The updated pipeline scores frames but does not gate accept/reject; the previous model version, or manual inspection, holds the decision. Nothing about the capture requires a stop.
- Pull a stratified sample, not a bulk dump. Cover the SKU mix scheduled for that shift, both shift-lighting states if the line sees daylight, and the known-marginal part classes. A few hundred well-chosen frames beat tens of thousands of frames of one SKU.
- Seed known defects deliberately. Re-run the seeded-defect coupons the original validation used, under the new lighting or fixturing. This is the only part of the capture that produces positive-class evidence, and it is the part teams most often skip.
- Record the capture conditions as structured metadata, not a note in a ticket: lamp part number, measured lux at the inspection plane, fixture revision, camera exposure and gain, conveyor speed setpoint.
- Recompute reference statistics offline from those frames, using the same summary-record format the running drift telemetry already emits.
Step 5 is what keeps the cost bounded: if the line already emits compact per-inspection summary records rather than raw frames — the approach described in line-side drift telemetry instrumenting CV inspection without losing throughput — a re-baseline is a recomputation over a fresh window, not a new data-engineering project. In practice, on lines where that telemetry sidecar already exists, we see the capture-and-recompute cycle finish inside one shift.
Recomputing thresholds without tuning away a real defect signal
This is the step where change control goes wrong quietly. After a retrofit, the drift monitors are noisy. The tempting fix is to widen the bands until the alerts stop. That silences the retrofit’s effect and, in the same motion, silences whatever real defect signal shares that channel.
Three rules keep the recompute honest.
Recompute from the new baseline, never by adjusting the old thresholds. A threshold derived by widening yesterday’s band encodes both the old line state and an arbitrary fudge factor; a threshold derived from the new reference window encodes only the new line state. The distinction matters when an auditor asks where a number came from.
Hold the false-reject and escape targets fixed across the change. The quality outcome is the invariant. Thresholds are free to move; the rejection-rate and escape budget they are meant to protect are not. If the new baseline cannot meet the same targets, that is a finding about the retrofit, not a reason to relax the budget.
Verify against seeded defects before the thresholds go live. The seeded coupons from step 3 are the control: if the recomputed thresholds still catch them at the agreed sensitivity under the new conditions, the recompute did not eat the signal. If they do not, the change has genuinely degraded detectability and the model — not the monitor — needs work.
Extend the golden set, do not replace it
The golden image set should grow at every line change. Replacing it destroys the only evidence you have of how the model behaved under the previous configuration, which is exactly what you need when a regression appears and someone asks whether the retrofit caused it.
Keep the old images, tag them with the line configuration they were captured under, and add the new capture as an additional configuration cohort. Regression runs then report per-configuration, and a model that improves on the new lighting while collapsing on the old one becomes visible rather than invisible. There is a real cost — the regression suite gets slower every refresh — so retire a cohort only when the line configuration it describes can no longer physically recur, and record the retirement decision with a date and an approver.
Pinning the pack to line state
Version pinning is what makes the whole procedure auditable. The pack revision has to name the line configuration it governs, with an effective-from timestamp, so that any inspected part can be traced back to the model version and the physical conditions in force when it was inspected.
A minimal pin record carries: pack revision ID, model version hash, line and station ID, line-configuration revision (lighting spec, fixture revision, camera settings), effective-from and effective-to timestamps, the change event that triggered the revision, and the sign-off record. Store it where the line-side telemetry can be joined against it — the point of the pin is reconstruction, and a pin nobody can query during an incident is decoration.
Who signs the restart
Three parties have a stake and none of them can sign alone. Maintenance owns the physical change and its record. Quality owns the rejection-rate and escape budget the recomputed thresholds must protect. The model owner — the named accepting owner from the line-side model ownership transfer — owns whether the evidence is sufficient.
The practical rule we apply: maintenance closes the mechanical job, the model owner certifies the re-baseline and threshold recompute against the seeded-defect control, and quality authorises the return to model-gated inspection. Until all three are recorded, the line runs in shadow mode with the previous decision path holding. That is a slower restart, and it is the difference between a line that survives a refresh and one that quietly reverts to manual inspection because nobody trusted the numbers any more.
None of this replaces the underlying reliability engineering; it is the change-control layer that keeps that engineering true across line refreshes. Our broader approach to keeping production vision systems measurable after go-live is set out under production AI reliability.
The open question, on most of the lines we have worked with, is not procedural — it is scheduling. Pack re-validation has to fit inside the same maintenance window the retrofit occupies, and on a plant running three shifts that window is rarely generous enough for both. Whether the answer is a smaller capture, a pre-staged shadow-mode window, or simply a planned production loss is still line-specific, and we would not claim otherwise.
Frequently Asked Questions
What does updating the reliability pack when line lighting or fixturing changes mean in practice?
Changes to line lighting or fixturing trigger a mandatory refresh of baseline imagery throughout the CV reliability pack. It means a physical change to the line enters the same change-control queue as a model change. A re-baseline image capture is taken under the new conditions, drift telemetry thresholds are recomputed from that baseline, the golden image set is extended with a new configuration cohort, and the pack revision is pinned to the new line state with a dated sign-off.
Which physical-environment changes should trigger a pack re-validation, and which are safe to log only?
Anything that can move pixels inside the inspection region of interest is a trigger: lamp or diffuser changes, ambient-light path changes, fixture swaps or shims, camera remounting, and conveyor speed steps that alter motion blur. Like-for-like lamp replacements, guarding or cabling work outside the optical path, and routine scheduled cleaning are log-only — recorded with a timestamp so a later rejection-rate excursion can be correlated against them.
How is a re-baseline image capture taken under the new lighting or fixturing without stopping the line for long?
Run the updated pipeline in shadow mode during the ramp-up that follows the maintenance job, with the previous decision path still gating parts. Take a stratified sample across the shift’s SKU mix and known-marginal classes rather than a bulk dump, re-run the seeded-defect coupons under the new conditions, and record capture metadata as structured fields. Where a telemetry sidecar already emits compact summary records, the recompute is a fresh window over existing infrastructure.
How are drift telemetry thresholds recomputed after a change, and how do you avoid re-tuning them to hide a real defect signal?
Recompute from the new baseline rather than widening the old bands, hold the false-reject and escape targets fixed across the change, and verify the new thresholds against seeded defects before they go live. If the recomputed thresholds no longer catch the seeded coupons at the agreed sensitivity, detectability has genuinely degraded and the model needs work — relaxing the budget is not the remedy.
Should the golden image set be replaced or extended when the line configuration changes?
Extended. Keep the previous images, tag them with the configuration they were captured under, and add the new capture as an additional cohort so regression runs report per-configuration. Replacing the set destroys the evidence needed to attribute a later regression to the retrofit; retire a cohort only when its line configuration can no longer recur, with a dated approval.
How does version pinning tie a pack revision to a specific line state so auditors can reconstruct which model governed which parts?
The pin record names the pack revision, model version hash, line and station ID, line-configuration revision (lighting spec, fixture revision, camera settings), effective-from and effective-to timestamps, the triggering change event, and the sign-off. Stored where line-side telemetry can be joined against it, that record lets anyone reconstruct both the model and the physical conditions in force when a given part was inspected.
Who signs off the re-validation — maintenance, quality, or the model owner — and what evidence is required before the line restarts?
All three, in sequence. Maintenance closes and records the mechanical change, the model owner certifies the re-baseline and the threshold recompute against the seeded-defect control, and quality authorises the return to model-gated inspection against the unchanged rejection-rate and escape budget. Until every signature is recorded, the line stays in shadow mode with the previous decision path holding.
When physical conditions shift, your pack must follow
Three changes to lighting geometry will invalidate more assertions than six months of model drift, so version control and re-validation cadence matter more than the initial build. If Updating CV Reliability Pack is on your roadmap, the next step is to map it onto your own constraints rather than copy a reference architecture.
