What is predictive quality? Quality prediction in production

In traditional manufacturing, quality testing comes at the end. The part is produced, inspected - and then it becomes clear whether it fits or not. If not: rejects, rework, complaint. The reaction to a quality problem is always retrospective: something has gone wrong, now we analyze why.

Predictive quality reverses this logic. Instead of checking whether a part is good after production, it is predicted during production whether a part will be good - based on process parameters, machine data and historical samples. Quality inspection shifts from final inspection to process control.

That sounds like a dream of the future. But it is not. The underlying technologies - machine learning, process data integration, real-time monitoring - are mature. The limiting factor is not the technology, but the database: if you want to introduce predictive quality, you don't need AI specialists, you first need complete, linked process data.

This article explains what predictive quality actually means, what data you need, how typical ML workflows work and where the method is already delivering measurable results in practice.

What predictive quality actually means - and what it doesn't mean

Predictive quality is a data-driven approach that predicts the likely quality of a product before or during production - based on process parameters, machine conditions and historical patterns.

The three core elements of predictive quality

1. process parameters as quality indicators

Every quality characteristic - dimensional accuracy, strength, surface quality - is influenced by process parameters: temperature, pressure, speed, feed rate, cycle time, tool condition. Predictive Quality identifies which parameter combinations have historically led to quality problems.

2. machine learning for pattern recognition

ML models recognize complex, non-linear relationships between process parameters and quality results - relationships that are not visible to humans. A model learns from historical data: "If temperature > X and pressure < Y and tool age > Z, then probability of error = 73%."

3. inline integration for real-time forecasting

The trained model is integrated into the production line. At each production step, the current process parameters are recorded, transferred to the model and a probability of error is calculated - in real time, while the part is still in the line.

What predictive quality is not

• No substitute for quality testing: Predictive quality predicts probabilities, not certainties. Inspections remain necessary - but they can be used in a more targeted manner.
• Not a black box: good predictive quality systems show why a part is classified as risky (feature importance). This is crucial for process improvement.
• No guarantee of accuracy: A model with 95% accuracy means that 5% of predictions are incorrect. Predictive quality reduces errors, but does not eliminate them.

Differentiation: Predictive quality vs. SPC vs. inline testing

Predictive quality is not the only approach to quality assurance during production. The differentiation from other methods clarifies when which approach makes sense.

When to use which approach?

SPC is useful when:

• Processes are to be kept stable
• Reaction to drift is sufficient
• Few, clearly defined process parameters are monitored

Inline testing is useful if:

• 100 % proof of quality is required
• Testing is possible quickly and cost-effectively
• defects can be reliably measured

Predictive quality makes sense when:

• Many process parameters interact
• Testing is expensive or destructive
• Defects only become visible at a late stage
• Data is already available but unused

The approaches are not mutually exclusive - they complement each other. Predictive quality can build on SPC data and control inline testing based on risk.

What data predictive quality needs

The most common reason for failed predictive quality projects is not an incorrect ML model, but missing or unlinked data. Before talking about algorithms, the database must be checked.

The three data categories for predictive quality

The critical link: serial number as key

Predictive quality learns from the question: "Which process parameters produced which quality result?"

This question can only be answered if the process parameters and quality result can be assigned to the same unit. This requires a continuous key - typically the serial number or a combination of batch + cycle number.

Problem in practice: In many companies, process parameters are stored in the MES, inspection results in the QMS and batch information in the ERP - without a common key. The data exists, but it cannot be linked.

Data quality checklist for predictive quality

Typical data sources and their suitability

The ML workflow: from raw data to predictive model

Machine learning sounds complex - but the basic workflow is structured and comprehensible. The following six phases describe how a functioning predictive quality model is created from raw data.

PHASE 1 | DURATION: 1-2 weeks

Problem definition and target value

What exactly should the model predict?

Activities:

• Define target variable: Probability of error, quality class, specific characteristic (e.g. dimensional accuracy)?
• Binary classification (OK/NOK) or regression (predict measured value)?
• Business case: What is the value of a correct prediction? What is the cost of a false negative (unrecognized error)?
• Narrow down the scope: A product, a line, a quality feature as a pilot

Output: Documented problem definition with target value, scope and success criteria

PHASE 2 | DURATION: 2-4 weeks

Data collection and integration

What data do we need - and how do we get it together?

Activities:

• Identify data sources: MES, QMS, PLC, ERP, sensors
• Data extraction: SQL queries, API connection, CSV export
• Data linking: Establish common key (serial number)
• Create data set: One row = one unit, columns = features + target variable

Output: Integrated raw data set with process parameters and quality results per unit

PHASE 3 | DURATION: 2-3 weeks

Data cleansing and feature engineering

How do we make the data modelable?

Activities:

• Dealing with missing values: Remove, impute or as a separate category?
• Identify outliers: Plausibility check, ±3σ filter
• Feature engineering: Create derived features (e.g. temperature gradient, tool age category)
• Normalization: Scaling of features for model stability
• Train/test split: 70-80% training, 20-30% test - chronological, not random

Output: Cleaned, feature-engineered data set, split into training and test

PHASE 4 | DURATION: 1-2 weeks

Model selection and training

Which model fits - and how good is it?

Activities:

• Select model candidates: Logistic regression, random forest, gradient boosting, XGBoost
• Train baseline model: Simple model as reference
• Hyperparameter tuning: Grid Search or Random Search for optimal configuration
• Cross-validation: K-Fold (k=5 or 10) for robustness testing

Typical model selection according to data situation:

Output: Trained model with documented hyperparameters

PHASE 5 | DURATION: 1-2 weeks

Model evaluation and interpretation

How good is the model - and why does it make which decisions?

Activities:

• Performance metrics on test data: Accuracy, Precision, Recall, F1-Score, AUC-ROC
• Analyze Confusion Matrix: How many false positives, how many false negatives?
• Threshold value optimization: At what probability is a part classified as a "risk"?
• Feature Importance: Which process parameters have the greatest influence?
• SHAP analysis: Why was this part classified as high-risk?

Critical metrics for predictive quality:

Output: Evaluated model with documented performance and interpretable results

PHASE 6 | DURATION: 2-4 weeks

Deployment and monitoring

How does the model get into production - and does it stay good?

Activities:

• Model deployment: integration into MES, edge device or cloud service
• Real-time inference: prediction for every production cycle
• Monitoring: Continuous monitoring of model performance (drift detection)
• Feedback loop: New test results → model retraining
• Threshold adjustment: Based on practical feedback

Output: Productive model with monitoring and retraining process

5 typical use cases in production

Predictive quality is not an end in itself - the benefits arise from specific use cases. The following five use cases show where predictive quality has the greatest leverage in practice.

USE CASE 01

Inline fault prediction with real-time warning

"This part has a 78% probability of dimensional deviation - check immediately."

Situation: Injection molding line, 12 process parameters per cycle. Dimensional deviation is only detected in the final inspection - 40 cycles later.

Predictive quality approach:

• Model trained on historical data: Process parameters → dimensional deviation yes/no
• Real-time prediction for each cycle
• For error probability > 60 %: Warning to operator + part marked for immediate inspection

Result:

USE CASE 02

Adaptive test planning (risk-based)

"Parts with low probability of error: random sample. Parts with high probability: 100%."

Situation: Assembly line, non-destructive final inspection possible, but time-consuming (45 sec./part). Current: 100 % inspection.

Predictive quality approach:

• Model predicts defect probability per part
• Inspection strategy: < 20 % → random sample (10 %). 20-60 % → normal inspection. > 60 % → extended inspection
• Inspection capacity is focused on risk parts

Result:

USE CASE 03

Replacement for destructive testing

"Instead of destroying the part, we predict the strength from the process parameters."

Situation: Weld seam strength test, destructive. Current: Sample 1 of 50, uncertainty for the other 49.

Predictive quality approach:

• Model trained on: Welding parameters (current, speed, gas) → Tensile strength (from destructive test)
• Regression model predicts strength for each part
• Destructive testing only for model validation and for predicted risk

Result:

USE CASE 04

Early warning of process drift

"The process is drifting - in 200 cycles Cpk will fall below 1.33."

Situation: Milling process, Cpk value drops slowly with tool wear. Current: Reaction only at Cpk < 1.33.

Predictive quality approach:

• Time series model on Cpk curve + tool age + process parameters
• Forecast: When will Cpk < 1.33 be reached?
• Early warning 2-4 hours before expected undershoot

Result:

USE CASE 05

Root cause analysis through feature importance

"The three most important drivers for rejects are Coolant temperature, tool age, shift change break."

Situation: scrap rate fluctuates between 0.3 % and 1.2 % - with no recognizable pattern. 14 process parameters recorded.

Predictive quality approach:

• Classification model for all parameters → rejects yes/no
• Feature Importance and SHAP analysis: Which parameters drive scrap?
• Identification of the top 3 drivers for targeted measures

Result:

Predictive quality is not a technology project - it is a quality improvement project that uses technology. The value is not created by the model, but by the measures that follow from the findings.

- Amadeus Lederle, CTE, CSP Intelligence GmbH

Prerequisites: When is your company ready?

Predictive quality does not require a perfect database - but it does require a sufficient one. The following checklist shows whether your company meets the minimum requirements.

Readiness check for predictive quality

If requirements are not met

If one or more dimensions show "Not yet", this is no reason to write off Predictive Quality - it shows where investments need to be made first.

The 6-step implementation path for

predictive quality does not have to start as a major project.

The following implementation path is designed for a pragmatic proof of concept - 8-12 weeks, one quality feature, one product.

STEP 1 | DURATION: 1 week

Define pilot scope

Activities:

• Select one product, one line, one quality feature
• Criteria for pilot: enough data, measurable problem, dedicated process owner
• Define target value:
• Defect classification or measurement prediction?
• Define success criteria:

• What model performance justifies follow-up?

Output:

Documented pilot scope with target value and success criteria

STEP 2 | DURATION: 2 weeks

Extract and link data

Activities:

• Export process parameters from MES/PLC (6-12 months)
• Export quality results from QMS
• Establish link via serial number
• Validate data set:

• Completeness, consistency, plausibility

Output:

Linked analysis data set

STEP 3 | DURATION: 2 weeks

Exploratory data analysis

Activities:

• Descriptive statistics: Mean values, distributions, correlations
• Visualization: Time series, box plots, scatter plots
• Identify patterns:

• Are there recognizable correlations between parameters and quality?
• Prioritize feature candidates

Output:

Analysis report with identified patterns and feature candidates

STEP 4 | DURATION: 2 weeks

Train and evaluate model

Activities:

• Train/test split (temporal, not random)
• Baseline model: Logistic regression or random forest
• Performance metrics: Recall, Precision, F1, AUC-ROC
• Analyze feature importance

Output:

Trained model with documented performance

STEP 5 | DURATION: 2 weeks

Validation on the store floor

Activities:

• Apply model to new data (not used in training)
• Compare predictions with actual results
• Involve process experts:

• Are the identified drivers plausible?
• Analyze false positives and false negatives

Output:

Validated model with store floor feedback

STEP 6 | DURATION: 2 weeks

Decision and next steps

Activities:

• Evaluate results against success criteria
• Calculate business case:

• What savings are realistic with rollout
• ? Go/No-Go for productization
• Roadmap for rollout or further pilot

Output: Decision + roadmap

)

Limits and typical errors

Predictive quality is not a panacea. The method has clear limitations - and typical mistakes during implementation can be avoided if you are aware of them.

Limits of predictive quality

Typical errors during implementation

PRACTICAL TIP

The data basis for predictive quality

Predictive quality rarely fails because of the algorithm - but because of a missing or unlinked database. IPM solves precisely this problem: all process parameters, test results and traceability data are stored in an integrated database, with the serial number as the continuous key.

For predictive quality, this means

• Linking out-of-the-box: process parameters + quality result + context data per serial number - no subsequent integration necessary
• Machine-set time stamp: Synchronized, ISO 8601, no manual input errors
• Mandatory fields technically enforced: No missing values for key parameters
• Unlimited history depth: All data is saved, not deleted after 90 days
• ML export-capable: CSV, Parquet or direct database query for Python/R

The result: Data integration - typically 50% of the effort of a predictive quality PoC - is eliminated. Instead of weeks for data collection: start analyzing immediately.

→ Arrange a demo

Frequently asked questions

Do we need a data science team for predictive quality?

Not to get started. An initial proof of concept can be carried out by a process engineer with basic Python knowledge - or with low-code ML platforms (DataRobot, Azure AutoML, H2O). The core competence is not ML, but process understanding: Which parameters are relevant? Which data is reliable? What do the results mean? External expertise can be useful for productization and scaling - but the PoC should be driven internally.

How many data points do I need as a minimum?

As a rule of thumb: at least 500-1,000 data points in total, including at least 50-100 error cases (positive class). This becomes difficult with highly unbalanced data (0.1 % rejects) - techniques such as oversampling (SMOTE) or adapted loss functions can help here. More important than the absolute number is the variability in the data: Does the data cover different batches, tools, shifts, seasons?

What is the difference between classification and regression?

• Classification: Model predicts a category (e.g. OK/NOT OK, defect type A/B/C)
• Regression: Model predicts a continuous value (e.g. strength in N/mm², dimensional deviation in mm)

Classification is more common for predictive quality - but regression can be more valuable if the specific measured value is important (e.g. replacement for destructive testing).

How do we explain the model decision?

Modern ML models are no longer black boxes. Two approaches:

• Feature Importance: Shows which parameters are the strongest drivers overall (e.g. "Temperature explains 34% of the variance")
• SHAP values: Show for each individual prediction which parameters have acted in which direction (e.g. "For this part: temperature was 3°C too high → +18 % probability of error")

Interpretability is crucial for acceptance on the store floor and for deriving improvement measures.

How often does the model need to be retrained?

That depends on the process stability. Typical intervals:

• Stable process, few changes: Every 3-6 months
• Frequent batch changes, tool changes: Monthly
• Continuous drift: Online learning or weekly retraining

Monitoring is more important than a fixed rhythm: if the model performance drops significantly on new data, retraining is necessary - regardless of the calendar.

What does the introduction of predictive quality cost?

The costs vary greatly depending on the scope and data situation. Orientation:

The ROI results from: reduced rejects, lower inspection effort, avoided complaints, earlier defect detection. Typical: 2-3× ROI in the first year of successful implementation.

Can we also use predictive quality for predictive maintenance?

Yes - the basic logic is identical. The difference:

• Predictive quality: Predicts product quality (rejects, dimensional deviations)
• Predictive maintenance: Predicts machine condition (failure, maintenance requirements)

Both use process parameters and historical patterns. The same data is often relevant - and a common data model can serve both use cases.