Every electronic product you own has a PCB inside it. The PCB does the unglamorous job of connecting everything together. We rarely notice it.
But tiny defects matter. A single hairline crack, a missing hole, or a tiny patch of unnecessary copper can render an entire product unusable. And sometimes these faults don’t manifest themselves immediately. A board can leave the production line working perfectly, then fail a few months later in the field.
This is why catching these defects early on is so important. It lowers the amount of rework needed and stops bad boards from getting to your customers. It provides manufacturers with a fair chance of discovering where a problem began rather than trying to figure it out afterwards.
The problem is, these small defects are easily overlooked. Quality-control personnel can examine hundreds or even thousands of boards in just one day. After spending hours looking at boards under bright lights, even the most experienced professional can miss something.
Traditional inspection systems have their own problems. Human inspectors get tired, while rule-based optical inspection machines need technicians to reprogram them whenever the product changes. Neither approach gets better with experience or scales easily as production grows.
That’s the gap Inspeqtr aims to fill. It monitors board images from a camera or video feed and uses AI to spot anything that looks unusual. It then shows the operator what it found and saves the evidence for later review.
The system also learns from operator feedback over time. When people correct its predictions, those corrections become useful training data for future models.
Inspeqtr isn’t designed to replace quality control people. It gives them another set of eyes. The goal is to help them catch more defects without relying entirely on attention, fatigue, or luck.
Why a model alone is not enough
Most AI inspection starts with a straightforward concept. Above the line: a camera, an execution of a model, and the triggering of an alert.
That can be helpful, but it isn’t enough to put into production.
A factory team needs to know which board triggered the alert, which camera saw it, what that image looked like, whether the detection was accurate, which model was in operation, which data was used to train that model, and whether a newly-deployed model can be rolled back quickly if it causes issues.
That is the philosophy behind Inspeqtr.
It combines inspection pipelines, telemetry and object storage, dataset curation, model training, MLflow tracking, edge deployment and rollbacks into a single workflow. Instead of representing each detection as an individual event, it builds a history around it.
That history is what allows an AI system to gain trust.
Inspection at the edge, where it matters
Factories often cannot afford to rely on a cloud connection for real-time inspection. Video streams need bandwidth, the production imagery can be sensitive, and an inspection decision that is a minute late has less value than one that’s a second early. Inspeqtr is designed to run as close to the line as possible.
Inspeqtr supports a range of Intel-based inference using DL Streamer and OpenVINO and a range of NVIDIA inference using DeepStream and TensorRT. At deployment time, the edge node will pick the hardware stack that matches the environment, not that the same accelerator is present in every factory.
This isn’t just a hypothetical. For example, one plant may prefer Intel industrial PCs because they’re small and inexpensive, while another may need the higher workloads of a GPU. Inspeqtr provides both environments with a consistent control surface, and lets the inference run on whichever hardware makes sense for the factory.
The edge services all provide a common pipeline lifecycle contract that can check the status of a pipeline, start a pipeline, stop a pipeline, and see if a pipeline is healthy. This makes the control plane less vendor-specific, and leaves the platform room to support new runtimes later on.
Klyff Bridge, the thing orchestrating all of it
At the heart of the edge environment is a service called Klyff Bridge.
Klyff Bridge acts like the operational coordinator for connected inspection devices. It reads the desired device configuration from the Klyff environment, compares it with what is currently running on the edge node, and starts or stops pipelines when the configuration changes.
If a camera is disabled, the bridge can stop its pipeline. If a new device is added, it can bring that pipeline online. If configuration changes, it can reconcile the running environment with the desired state.
The bridge also listens for MQTT messages from inference pipelines. These messages contain information such as detected labels, bounding box coordinates, timestamps, pipeline state, frame identifiers, frame rate, and image storage references.
That is where raw AI output becomes useful operational information.
Klyff Production Dashboard
Inspeqtr can group inspection activity into meaningful production units. Depending on the configuration, it can treat each frame as an inspection unit, group frames into a time window, or use an external signal such as a barcode, serial number, PLC event, or board index to define when one unit ends and another begins.
This allows the platform to calculate metrics that matter to quality and operations teams.
It can calculate First Pass Yield(FPY), which shows how many units pass inspection correctly the first time. It can also calculate quality, availability, performance, and Overall Equipment Effectiveness (OEE). These metrics help teams understand whether the line is improving, slowing down, or producing more issues than expected.
A raw total of detected anomalies does not tell the full story. A properly grouped inspection history does.
Where everything actually lives: RustFS
When a model flags a possible defect, an operator needs to see the actual board image.
Inspeqtr uses RustFS, an S3-compatible object store, to keep inspection frames, curated datasets, model artifacts, and MLflow outputs in one storage approach. The platform avoids storing unnecessary duplicate images. It can render the highlighted defective unit only when someone requests it.
This is a thoughtful design choice. It preserves the original evidence, reduces duplicate storage, and gives the product flexibility later. The visual style of annotations can change without rewriting every image ever captured.
The bridge can also enforce image retention rules so teams can decide how long historical evidence should remain in storage.
Where the model actually learns: the dataset curator
The quality of an AI model depends heavily on the quality of its training data.
Inspeqtr includes a curator service to help teams turn raw images or sensor data into controlled, reusable datasets. It supports importing inspection images from object storage, uploading images through a browser, handling CSV files for structured data, removing duplicates, and maintaining project-specific manifests.
For PCB object detection, quality engineers can review images and add bounding box annotations around defects. For image classification, teams can organize data around whole image labels. For sensor data, they can work with CSV and JSON Lines-based records.
The curator also supports a useful CSV workflow. Instead of overwriting source data directly, it can keep curation changes as an overlay and later create an immutable derived CSV when the data is ready for training.
When a dataset is released, the curator packages it deterministically, calculates a SHA-256 digest, publishes it to object storage, and registers the version with the training orchestrator.
That means a dataset is no longer just a folder that someone named “final version.” It has an identity, a checksum, a release record, and a relationship to the model that used it.
More than Visual Inspection
PCB anomaly detection is one use case of Inspeqtr, but it reaches beyond visual inspection.
Inspeqtr supports object detection through YOLOv11 and RT DETR. It supports image classification through MobileNet V3 and EfficientNet B0. It also supports time series classification through Random Forest, XGBoost, LightGBM, CatBoost, and LSTM. For regression problems, it also supports time series regression through Random Forest, XGBoost, LightGBM, CatBoost, and LSTM.
This creates a useful path for manufacturers. The same platform that inspects boards visually can also work with machine temperature, vibration, pressure, humidity, current, flow, and other industrial telemetry.
A factory may begin with PCB defect detection and later use the same platform to identify machine conditions, estimate process output, or detect patterns that point to equipment degradation.
Training with traceability
The orchestrator service owns the training lifecycle.
It manages projects, datasets, dataset versions, training requests, job status, algorithm validation, candidate records, approvals, deployment requests, and audit events. Training jobs are stored in PostgreSQL so they are durable and observable instead of existing only in memory.
When a job is ready, a worker launches an isolated training container. This is useful because every run begins in a controlled environment. A training failure does not need to affect the orchestration API, and each run can be tracked independently.
The trainer validates the dataset checksum before extracting it. It rejects unsafe archive members, trains the selected model, records training progress, logs metrics, exports deployment artifacts, and publishes the candidate model.
MLflow gives every experiment a history
MLflow is the experiment memory of Inspeqtr.
It records the parameters used for training, the dataset archive, the dataset version, model metrics, reports, exported artifacts, candidate identity, and project information. Its metadata is stored in PostgreSQL, while the larger artifacts are stored in RustFS.
This becomes extremely valuable over time.
Six months after deployment, teams can use MLflow to identify which model runs on a specific production line, trace the data that trained it, review the parameters used, measure its performance, and verify who approved it. Proper MLflow tracking keeps this information accessible instead of burying it in chat messages, spreadsheets, or forgotten folders.
Safer deployment through staging and rollback
A newly trained model should not overwrite the current production model without a safety net.
Inspeqtr includes a model manager that supports staged deployment. Extract the model into a staging directory while keeping the current active model intact.
Eligible devices can enter staged comparison mode, where teams evaluate a reviewed model before promotion. Once approved, the staged model replaces the active model, while the existing model remains securely available as a backup for safe rollback.
If something goes wrong, the previous model remains available.
The OTA service extends the same principle to edge updates. It can manage model updates, configuration changes, binary updates, and container image updates through Klyff.
Before replacing a container or package, the OTA service stores rollback information. It verifies checksums or expected container-image digests, validates pipeline health after deployment, and restores the previous state if validation fails.
This is the kind of operational detail that matters on a factory floor. A model update should not become a production outage.
Why Inspeqtr matters
Inspeqtr is valuable because it gives manufacturers more than an AI model.
It gives them a way to run inspection close to the line, preserve evidence, understand what happened, involve quality engineers in data preparation, train models with traceability, compare candidates carefully, and recover safely when something changes.
It supports the reality that factories evolve. New board revisions arrive. Lighting changes. Cameras move. Defect patterns shift. Equipment behaviour changes. A model that worked well last quarter may need better data next quarter.
Inspeqtr gives teams a practical way to handle that reality.
The goal is not to remove human judgment from quality control. The goal is to give quality teams a better system around that judgment. Our system captures every event, presents clear evidence, tracks model training, and guides each improvement through a safer, more transparent process.
Every model promoted to production keeps its predecessor on standby, so a rollback is a switch, not a scramble. To see how staged deployment and rollback work in a live PCB inspection line, book a technical demo with us.