An acceptance sheet signed at go-live does not transfer ownership of a line-side inspection model. Ownership transfers when a named person inside the plant can pin a model version, execute a rollback and restore accurate rejection-rate reporting without calling the team that built the system. Everything else is paperwork.
The naive handoff looks complete because it is ceremonially complete. The integrator demonstrates accuracy on the running line, quality signs, the project closes, and the model is assumed to belong to the plant. Nobody has asked the awkward question: when the rejection rate moves next month after a lamp is replaced, who is authorised to act, and with what in hand?
Why does a signed handoff still leave the model unowned?
Because the signature records agreement about accuracy, not capability to intervene. The divergence point is always the first drift incident after handoff — a lighting change, a packaging redesign, a fixture swap during maintenance. At that moment the accepting owner either holds the drift telemetry baseline, the version-pinning record and the rollback runbook, or escalates back to a build team that has moved on to another site.
Without a transfer pack, the practical owner of a line-side model becomes whoever last touched it. That is not a role, it is an accident, and it degrades predictably: nobody is authorised to roll back or retrain, so the line reverts to manual inspection while the model quietly stays switched on or quietly gets switched off. We see this pattern regularly on lines where the CV asset was never entered into the same maintenance and on-call structures as the PLCs, drives and vision lighting around it.
The artefacts do not replace ownership. They are what makes ownership exercisable — the distinction that most commissioning checklists collapse.
Which role actually accepts ownership?
There is no single correct answer, and pretending there is one is how transfers fail. Four candidate owners typically sit in the room, each able to accept a different part of the responsibility.
| Candidate accepting owner | Can genuinely accept | Cannot accept alone | What they need handed over |
|---|---|---|---|
| Plant engineering / maintenance | Physical-environment changes, fixture and lighting change control, on-call first response | Model retraining, dataset curation | Rollback runbook, pinned last-known-good version, change-request trigger list |
| Controls / automation | Line integration, PLC interlocks, switching between model and manual inspection | Drift interpretation, accuracy trade-offs | Rollback execution steps, interlock and bypass procedure, alarm routing |
| Quality | Rejection-rate reporting, false-reject tolerance, disposition of flagged batches | Version control, telemetry infrastructure | Drift telemetry dashboard, baseline rejection-rate distribution, escalation thresholds |
| Central data / ML team | Retraining, model registry, version pinning | Line-side timing, physical change awareness | Reproducible build evidence, training data lineage, telemetry export |
In our experience the workable arrangement on a single line is a plant-side accepting owner with on-call responsibility, backed by a central team that owns retraining under a defined request path. What does not work is naming the central data team as the sole owner: they are not on the shift rota, and drift incidents surface on shifts.
The minimum contents of an on-call ownership transfer pack
This is the acceptance list. If an item is missing, the corresponding failure mode has no owner.
- Named accepting owner and deputy, entered on the line’s on-call rota alongside its other assets — not a distribution list.
- Pinned last-known-good model version, with the artefact stored where the plant can retrieve it, plus the container image or runtime bundle it was validated against.
- Reproducible build evidence — which dataset revision, which training configuration, which preprocessing produced that pinned version.
- Drift telemetry baseline — the normal operating distribution of the monitored signals, so a deviation can be recognised as one. Instrumentation without a baseline is a log file.
- Rollback runbook with named trigger conditions, the switch procedure, and the expected line state during and after the switch.
- Change-triggering event list — the physical and process changes (lighting retrofit, carton redesign, fixture swap, conveyor speed step, new SKU) that require re-baselining before they reach the line.
- Escalation path with an expiry date — who at the build team answers, for what class of problem, and until when.
- Contact and authority record — who is permitted to disable the model, and whose sign-off retraining requires.
What acceptance test proves the transfer happened?
A rehearsal, not a signature. Before the engagement closes, the accepting owner executes a rollback on the live line under observation, using only the pack, with the build team present but silent. If they need to be asked a question, the pack has a gap and the gap is fixed before close.
Three metrics make the transfer measurable afterwards, and they are the ones worth tracking into the first year:
- Mean time to rollback — from trigger condition met to the line running on the pinned version or manual inspection.
- Share of post-handoff incidents closed by the plant owner without vendor escalation.
- Model uptime across the first two line changes — a refresh or retool is the real test, because that is where unowned models drop out of service.
The pattern we observe across industrial CV engagements is directional rather than benchmarked: lines with a completed transfer pack tend to keep the inspection model in service across line refreshes and operator shift changes, while lines without one accumulate unowned drift and revert to manual inspection within roughly a quarter of go-live. Treat that as a planning heuristic, not a measured rate — the underlying cause is authority, not model quality.
Re-transfer is a recurring event, not a one-off
Ownership does not transfer once. Every retrain, every line refresh, every retool moves the pack out of date, and a stale pack is worse than an absent one because it invites confident wrong action. A re-baseline capture after a physical change updates the telemetry baseline and the golden image set; a retrain updates the pinned version, the build evidence and the rollback target. If the accepting owner changes — a shift reorganisation, a role backfill — the rehearsal is repeated. The structural causes of this drift-versus-artefact mismatch, and the wider reliability set the transfer pack closes out, are developed in our work on what makes a production AI deployment reliable rather than merely accurate.
The escalation path deserves a date rather than an open promise. A bounded window — long enough to cover the first genuine drift incident and the first line change, with a defined scope of what the build team will answer — is more honest than indefinite goodwill support that quietly evaporates when the original engineers rotate off.
Frequently Asked Questions
What does ‘who owns the line-side model post-handoff and what evidence transfers with ownership’ mean in practice?
Line Side Model Ownership is one of those terms that hides a simple idea. It means identifying the person inside the plant who is on-call for the inspection model, and the evidence they must hold to act on it. In practice that is a named owner and deputy on the line’s rota, plus a pack containing the pinned model version, drift telemetry baseline, rollback runbook and build evidence. Ownership without that evidence is nominal.
Which role actually accepts ownership — plant engineering, controls, quality, or a central data team — and what does each need to accept it?
Each accepts a different slice: plant engineering takes physical change control and first response, controls takes the switch between model and manual inspection, quality takes rejection-rate reporting and thresholds, and a central team takes retraining and version control. On a single line the practical arrangement is a plant-side on-call owner backed by a central retraining path. A central data team named as sole owner fails because it is not on the shift rota.
What is the minimum contents list of an on-call ownership transfer pack for a line-side inspection model?
Named accepting owner and deputy on the rota; the pinned last-known-good model version with its runtime bundle; reproducible build evidence; the drift telemetry baseline; a rollback runbook with named triggers; the list of physical and process changes that require re-baselining; and an escalation path with an expiry date. Missing items map directly to failure modes with no owner.
How does drift telemetry, version pinning and the rollback runbook change hands so the new owner can act without the build team?
They transfer by being usable, not by being delivered. The telemetry has to be visible on a surface the plant already watches, the pinned version has to be retrievable from storage the plant controls, and the runbook has to be executable by the named owner. The proof is a supervised rollback rehearsal on the live line before the engagement closes.
What acceptance test proves the transfer actually happened, rather than being signed off on paper?
The accepting owner executes a rollback on the running line using only the pack, with the build team observing without intervening. Any question they have to ask marks a gap in the pack, and that gap is closed before the engagement ends. Afterwards, mean time to rollback and the share of incidents closed without vendor escalation keep the answer honest.
How does ownership and its evidence get re-transferred when the line is refreshed, retooled or the model is retrained?
Each of those events invalidates part of the pack, so each triggers an update: a physical change requires a re-baseline capture and a refreshed golden image set, a retrain requires new build evidence and a new rollback target. If the accepting owner changes with a shift reorganisation or backfill, the rollback rehearsal is repeated with the new owner. A stale pack is more dangerous than a missing one because it invites confident wrong action.
What escalation path stays with the original build team, and for how long?
A bounded window with a defined scope — long enough to cover the first genuine drift incident and the first line change — is preferable to indefinite goodwill support. The scope should name which problem classes the build team answers and which the plant owns outright. Open-ended promises decay silently as the original engineers rotate onto other work.
Three ownership models, three failure modes
Ownership ambiguity kills production AI systems faster than drift: when no single team holds both accountability and access, incidents stall in handoff limbo.
