Training a new defect model on HyperQ AI Vision takes 1,000 images, not 10,000. That factor-of-10 difference matters not because of the training time it saves but because of who can act on it. On a platform where model files live in the manufacturer's own repository and the training interface is available to the production team, 1,000 images means a line engineer can commission a retraining run on a Tuesday afternoon. On an integrator-built system where model files live in the contractor's environment, 1,000 images means nothing until a purchase order is raised and a site visit is booked. The practical question after any vision deployment is not accuracy. It is: who can retrain the model without a purchase order?
That custody question is the hidden cost most vision evaluations skip. This post maps it.
Defining the two deployment models
Integrator-led deployment. An engineering contractor builds the system: camera selection, lighting design, model training, production deployment. On go-live, the system runs. The model weights, training dataset, and retraining workflow stay in the contractor's environment. The manufacturer runs the output. The integrator holds the intellectual infrastructure.
Platform-led deployment. A software vendor provides a platform — a model training environment, production deployment tools, and ongoing model management interface. The manufacturer's team, or a lightweight configuration partner, sets up the system using the platform's tools. On go-live, the model files, training data, and retraining interface are in the manufacturer's hands. The vendor supplies the tool. The manufacturer controls what was built with it.
The difference is not primarily technical. It is about where the trained model sits after go-live and who has access to it when the product mix changes.
The hidden cost: model custody
An integrator builds a model that runs on day 1. In month 4, SKU configuration 42 is added to the line. The trained model does not cover it. The production team raises a request. The integrator schedules a site visit, collects images, retrains, validates, and pushes the updated model. Depending on the contract terms, this is a change order, a support ticket, or a scheduled maintenance event. Based on industry-standard integrator service arrangements, elapsed time from request to production-qualified deployment is typically 2 to 6 weeks.
In month 8, a raw material lot substitution changes the surface finish on an existing part family. The model's performance on the new surface is degraded. The production team detects an uptick in false positives and escapes. They raise another request. Another change order, another site visit, another 2 to 6 weeks.
The cost of each retraining cycle is not only the invoice. It is production hours between the detected problem and the corrected model. In high-mix manufacturing, model drift from new SKUs or material substitutions is not an edge case. It is the routine operating condition. A facility adding one new product variant per month and running one material lot change per quarter will trigger 10 to 15 retraining events per year under normal production dynamics.
One practitioner described the pattern plainly: the team knew the model was underperforming on the new substrate batch for three weeks before the integrator could get back on-site. The escape-rate cost in that window exceeded the original system price.
On a platform where model files are in the manufacturer's repository and the training environment runs on their infrastructure, the timeline is different. The line engineer collects images of the new defect or new surface, runs the retraining job, validates against a reference set, and deploys the updated model — without a purchase order. That is the operational meaning of "Tuesday afternoon retraining."
Comparison table
| Criterion | Integrator-built system | Platform-led deployment |
|---|---|---|
| Model custody | Model weights and training data held in integrator's environment; manufacturer accesses inference output only | Model files and training data in manufacturer's local environment or designated storage; accessible without contractor involvement |
| Retraining turnaround | 2–6 weeks from request to production deployment; change order required in most standard contracts | Hours to 2 days from problem identification to validated retrain, with no PO required |
| Contractor dependency | SKU additions, defect class changes, and drift correction require contractor engagement; system performance is bounded by contractor availability | Manufacturer team runs routine retrains; vendor support available for novel defect classes but not required for standard updates |
| Audit access | Training data version, model version, and inference performance history may not be accessible to manufacturer under standard contract terms | Full training data version, model version history, and inference performance log readable by manufacturer's quality team on demand |
| Exit path | Model weights typically do not transfer on contract termination; moving to another vendor often means retraining from zero on new infrastructure | Model files, training data, and performance benchmarks are owned by the manufacturer; migration requires effort but the training asset is retained |
Retraining frequency is not a special case — it is the maintenance schedule
A trained defect model is not a fixed configuration that runs indefinitely without intervention. It is a statistical model calibrated against a specific distribution of images from a specific production period. When that distribution shifts — new material lot, new tooling, new SKU, changed line speed, modified lighting — the model's calibration drifts relative to the new reality.
In a stable, single-product line this drift may take months to become detectable. In a high-mix manufacturing environment with active product development and regular material sourcing changes, detectable drift can arrive in weeks. The question is not whether the model will need retraining. The question is how long the production team will wait when it does.
From Hypernology's deployment experience, the pattern is consistent: the first retraining event typically happens within the first 90 days of go-live, and the most common trigger is not a new SKU. It is a material lot change on an existing part family that was not represented in the initial training set. The new lot's surface finish, reflectance, or dimensional tolerance is close enough to the original that the model was not retrained ahead of the transition, but different enough that false-positive and escape rates shift visibly within 1 to 2 weeks of the new lot entering production. After that, retraining events cluster around SKU additions and material changes, following the production team's commercial cycle, not a scheduled maintenance interval. A production team that can retrain on-demand stays ahead of the drift; a team waiting on a contractor change order processes escapes until the contractor arrives.
Why custody matters more in SG/MY high-mix manufacturing
Singapore and Malaysian manufacturers in the precision-machined and assembled-goods sectors share a common condition: product mix changes on 30-to-90-day customer-driven cycles, raw material substitutions happen faster than annual model review cycles can handle, and line expansion into adjacent product families is a routine growth event, not an exceptional one.
A components supplier running hundreds of active SKU variants cannot absorb a 4-week retraining delay every time a material lot changes surface reflectance. A precision-valve maker adding a new bore diameter to an existing product family needs the model updated before the first batch runs. An electronics assembly line responding to a customer's updated defect classification standard needs the retraining within the week the standard takes effect, not three weeks later.
The integrator model was designed for more stable manufacturing environments — a fixed production line, a defined product range, and a 12-to-36-month refresh cadence. That assumption held when vision systems were installed as fixed inspection fixtures for a single application. It breaks in high-mix environments where the production mix changes faster than the contractor relationship can respond.
This is not a criticism of integrators as a category. It is a description of a structural mismatch between the custody model and the operating environment.
What integrator-led deployments do well
An experienced integrator brings camera and optics selection expertise that most in-house production teams do not have on staff. Illumination design for a specific defect class — structured lighting angles for scratch detection, coaxial illumination for surface porosity, diffuse backlight for edge sharpness — is specialized work. A good integrator who has solved similar inspection problems before will reach a working configuration faster than a platform user learning the optics from scratch.
For a first-time vision installation on a technically demanding application — a reflective metal surface, a complex 3D geometry, a fast-moving line where motion blur is the primary constraint — the integrator's build expertise reduces commissioning risk significantly.
The integrator model also suits facilities that genuinely prefer to outsource ongoing model maintenance as a managed service. A plant running one product family on one production configuration for 5 years may have no interest in operating a training environment in-house. A managed-service contract with defined SLA terms for retraining events is a reasonable arrangement.
The failure mode is not choosing an integrator. The failure mode is choosing an integrator without understanding the model custody terms before go-live; discovering the exit constraint after the product mix changes and the retraining queue starts to back up.
The audit access problem
Model version control and training data lineage are not optional in quality management systems that feed EQMS or MES records. A quality manager who needs to explain why a defect class detection rate was 97% in Q1 and 89% in Q3 needs to know what model version was running in each period and what training data informed it.
On an integrator-built system, that audit trail lives in the integrator's version control system and data repository. The manufacturer may receive a model version number in the commissioning document, but querying the training data for that version — what images were used, what was excluded, what labeling protocol was applied — typically requires a formal request to the contractor. If the integrator is acquired, exits the market, or the service contract lapses, the training data history may be unrecoverable.
On a platform-led deployment, the training data version, model version, and inference performance log are readable by the manufacturer's quality team using the same interface the line engineer uses to run retraining jobs. The accessibility is not an add-on feature. It is a direct consequence of where the model files sit.
Cross-industry evidence
This post does not draw on a directly applicable Hypernology deployment that illustrates the integrator-vs-platform gap in isolation. The live production reference is the Tier-1 automotive-parts deployment that operates HyperQ AI Vision across 8,000+ product variants and 11,520 units per day on 6 production lines, at 99% detection accuracy. That deployment runs as a platform-led configuration: the production team manages retraining against new variant data on their schedule, without contractor involvement for routine updates. The 10x reduction in required training images — 1,000 images for a new model versus the 10,000 that hardware-locked platforms typically require — is the operational basis that makes in-house retraining practical for a team without dedicated machine learning staff.
That deployment is the reference for the "retraining turnaround" row in the comparison table. The 6 production lines and 8,000+ variant range reflect a manufacturing environment with high mix and active product change. That is the condition where model custody determines whether retraining is a Tuesday afternoon task or a 4-week procurement cycle. This cross-industry reference is explicitly not a crane, solar, or other vertical; it is used here to illustrate the platform custody architecture because no directly matched vertical case is in the public portfolio.
Reading the contract before go-live
Most manufacturers discover their model custody situation the first time they try to retrain after a product change. The relevant clause is usually in the software license section or the support terms annex, not the hardware specification. These five questions define the custody position before signing:
- Who holds the model weight files and training dataset after go-live, and can the manufacturer export them at any time in a standard portable format such as ONNX or TorchScript — formats that allow the model to run on infrastructure independent of the original vendor's platform?
- What is the commercial structure for model retraining when a new SKU is added — is it covered under the base contract, a support tier, or a separate change order?
- What happens to the trained model and training data if this contract terminates, the vendor is acquired, or the service lapses?
- Can the manufacturer's quality team query the training data version and model version deployed on any specific production date, without a formal request to the vendor?
- Is retraining infrastructure (the training environment, labeling tools, validation workflow) available to the manufacturer's team on a self-service basis or only via vendor-initiated sessions?
These are not negotiating tactics. They define whether the vision system is a depreciating capital asset or an operational tool that can adapt to the production schedule. A system that cannot retrain without a purchase order is a depreciating asset. A system where the production team controls the training cycle is an operational tool.
A reference checklist for evaluating vision contracts — including change-order risk, exclusion clauses, and accuracy-guarantee language — is covered in vision switching costs and the exit checklist. The technical basis for why learning-based platforms require far fewer training images than rule-based or fixed-algorithm systems is covered in rules-first vs learning-first vision. The HyperQ AI Vision custody model, training data ownership terms, and self-service retraining interface are detailed at /solutions/hyperq-ai-vision.
Send a description of your current or intended vision deployment — product variant count, how often new SKUs are added, and what the current retraining process looks like — to apac.hypernology.net/contact. We return a model custody assessment and retraining-architecture recommendation within 3 working days. No contract until the architecture matches your actual change cycle.
