How Grasim Moved Quality Inspection From Sampled to Continuous

By the time Grasim Industries brought us in, the quality-control problem on the line wasn't visibility — it was reach. Manual inspection at production scale is, by structure, sampled inspection: an operator examines a fraction of units, escalates suspected defects, and trusts the sample to represent the run. At Grasim's throughput, the units the operator never sees are the ones that quietly carry defects downstream — into packaging, into shipment, occasionally into customer-side rejections. The team had floor-level discipline and decades of process knowledge, but no surface that could look at every unit, every minute, without slowing the line. Adding more operators doesn't scale; slowing the line is not an option. What was missing was a vision layer that worked at line speed and at the edge — without depending on a network round-trip to a central server, and without taking the line down to install.

The Grasim quality inspection system is a production-line computer vision platform deployed at the edge. Industrial cameras mounted along the line capture every unit as it passes; the captured frame is processed locally on edge inference hardware optimised with TensorRT, against a YOLO-family detection model trained on Grasim's own defect corpus. Pre-processing and frame normalisation run through OpenCV. The entire detect-classify-decide loop completes in under a second per unit, which is what makes the system viable at line speed. The pipeline runs in three stages. The capture stage handles camera triggering, exposure correction, and frame routing for each unit. The inference stage runs the trained YOLO model against the frame, producing bounding boxes, defect class labels, and confidence scores; the model itself was tuned against a labelled corpus assembled in collaboration with Grasim's QA team, so the defect taxonomy reflects the actual failure modes that matter on this product line, not a generic catalog. The decision stage applies confidence thresholds, routes pass/fail signals to the line's diverter, and writes every inspection event — pass or fail, with the original frame — into a local event store for QA review. Crucially, the system is fully edge-resident. There is no network dependency for the inspection itself; if the wider network drops, the line keeps inspecting. A daily batch synchronises inspection events and any new edge-cases back to the central training surface, where Grasim's QA team can confirm or correct the model's labels and feed those corrections into the next training cycle. The model improves on Grasim's data, on Grasim's product line, on Grasim's tolerances — not on a generic manufacturing corpus.

Two things, honestly. First, we under-scoped the labelling effort. The model's ceiling on this kind of deployment is set by the quality of the defect corpus, not by the architecture, and the first six weeks of labelling were the single highest-leverage activity in the project — but we treated it as preparation rather than as the work. On the next line we'd embed two QA engineers and a labelling-tools setup from week one, not week three. Second, we built the edge inference path before the QA review console. That's the wrong order for adoption. The console is what gives the QA team agency over the model's behaviour; shipping detection without a confident review surface meant the first two weeks of live running felt like a black box to the floor team. Next deployment, the console ships in week four, with synthetic data, before the cameras go live.