AI Adoption GuideManufacturingMake
Incoming Material Scrap Risk Prediction
ML scores inbound material lots against certificate data and historical process performance to predict above-threshold scrap probability before release to production.
Manufacturing processPlanSourceMakeInspectPackShipServiceReturn
By Don, DoneThat’s AI coach · updated
What this use case does
Incoming material scrap risk prediction scores each inbound lot before it is released to production. The model combines certificate-of-conformance (CoC) fields, receiving inspection results, and historical scrap and yield on similar lots, materials, and process routes. The output is a probability that the lot will drive scrap above a threshold you define, not a pass/fail disposition.
Quality still owns the release decision. The score is an early signal for inspection depth, containment, or supplier follow-up. It does not auto-block, auto-accept, or rewrite disposition rules in SAP QM or your QMS.
Typical inputs include material and supplier identifiers, heat or batch numbers, certificate chemistry and mechanical properties, dimensional or attribute results from receiving, storage age, and prior scrap rates for the same material-process combination. Outputs should be lot-level, timestamped, and explainable enough that an inspector can see which certificate or history features drove a high score.
When required CoC or certificate fields are missing, the score must be empty (null), not a default mid-range value. An empty score means “insufficient evidence,” which is different from “low risk.” Release and sampling policies should treat missing certificates under existing hold rules, not under the model.
When it is worth building
This use case pays off when scrap after release is expensive, recurring, and correlated with inbound variability you already capture on paper or in systems but do not use until after the damage is done. Examples include lots that meet certificate limits yet sit near process edges your lines cannot absorb, suppliers whose “in-spec” material still produces high scrap on specific SKUs, or materials where late escapes force rework, sorting, or line stops.
It is usually a weak fit when scrap is dominated by process setup or tooling that has little to do with inbound lots, when certificate data is sparse or inconsistently transcribed, or when disposition is already so conservative that every lot gets the same heavy inspection regardless of risk. If you cannot define an above-threshold scrap event that operations and finance agree on, you do not yet have a label to train or evaluate against.
Prerequisites on the shop floor side: stable lot identity from receipt through consumption, a scrap or yield event that can be attributed back to lot or heat with acceptable lag, and a release workflow where a risk score can change inspection plan or hold queue without inventing a parallel shadow process. Prerequisites on the data side: digitized CoC fields (not only PDFs), historical scrap tagged by material and preferably by supplier and process route, and a clear policy for missing certificates.
Related work on Process Parameter Optimization often shares the same process-performance history. Inspection Escape Root Cause Correlation is useful when you need to separate inbound contribution from in-process escapes. Supplier Lead-Time Risk Scoring addresses delivery reliability, not scrap quality; keep those scores separate even when both sit on a supplier scorecard.
How the model and workflow fit together
Treat the problem as lot-level risk ranking before release. Labels come from historical lots: whether consumption of that lot (or heat) was followed by scrap above your threshold on the intended process route within a defined window. Features come from certificate and receiving data available at release time, plus rolling history for that supplier-material-route combination. Do not use post-release process tags that would not exist when the lot is still in receiving.
Score empty when mandatory CoC fields are absent or unparseable. Do not impute critical chemistry or mechanical properties just to force a number. Optional enrichment (for example prior supplier scrap rates) can still exist, but the published lot score for release should remain empty until certificate completeness rules are met.
Human workflow:
- Lot is received and certificate data is entered or ingested.
- If required fields are missing, score stays empty and existing incomplete-certificate holds apply.
- If complete, the model returns scrap-above-threshold probability plus top contributing features.
- Quality applies policy: standard sample, tightened sample, lab hold, or supplier notification. Disposition remains a quality decision.
- After consumption, scrap outcomes feed back for monitoring and periodic recalibration.
Keep thresholds and policies versioned. A probability of 0.35 means nothing without a shared definition of the scrap event, the time window, and what action each band triggers. Publish calibration checks so a “high” band actually concentrates more scrap events than a “low” band over recent lots.
Systems to connect
You do not need a greenfield stack. Most plants already hold the pieces in quality and industrial data systems; the work is joining them at lot grain and serving a score at release time.
SAP QM often owns inspection lots, usage decisions, and certificate recording for goods receipt. Use it as the system of record for release status and as the place where a risk score or risk class can appear as an informational characteristic or companion field. Do not let the model silently change usage decision codes.
InfinityQS (or similar SPC/quality platforms) is a common home for in-process scrap, defect, and yield signals that become labels and for ongoing monitoring after release. Align lot or heat identifiers with receiving so history joins cleanly.
HighByte (or equivalent industrial dataOps) helps normalize certificate, MES, and historian payloads into a consistent lot-centric model without brittle point-to-point scripts. That matters when CoC fields arrive as files, EDI, or supplier portals with uneven schemas.
Integration pattern that holds up: ingest and validate certificate fields → compute score only when complete → write score and explanation back to the release UI or QMS companion table → write outcomes later from scrap/yield systems for drift checks. Prefer event-driven updates on goods receipt and certificate post rather than overnight-only batches if release happens same day.
Operating the score without false confidence
Govern the use case like any other release-adjacent control. Define owners for feature definitions, threshold bands, and override logging. When quality releases a high-risk lot, record the rationale so you can audit whether policy or model guidance is being ignored for good reason.
Watch for failure modes that look like “AI success” but hurt the plant: scores that always sit mid-range because features are weak; empty scores treated as low risk; suppliers gaming certificate transcription; label leakage from using post-process scrap codes that encode the disposition you already made; and drift after a recipe, tooling, or supplier mix change.
Evaluation should stay operational. Track precision at the action band you actually use (for example, lots sent to tightened inspection), catch-positive rate against true above-threshold scrap lots, and the share of lots with empty scores due to missing certificates. If empty-score volume rises, fix data capture before retuning the model.
Start with one material family and one process route where scrap attribution is clean. Prove that high scores enrich true problem lots and that inspectors trust the explanations. Expand only after release policy, certificate completeness, and feedback loops are boringly reliable. The goal is fewer surprise scrap events after release, with quality still firmly in control of every lot that enters production.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first