Silicon Fab Inspection Pipeline

Our client is a large semiconductor manufacturer operating three silicon fabrication sites in Japan (Imari and Kubara). The company produces high-precision wafer substrates used in advanced electronics, operating under strict quality mandates that govern every production stage. With tens of thousands of wafer inspections processed per month across the three sites, even small inconsistencies in the quality review process translate directly into scrap, rework, or downstream yield loss.

Their manufacturing execution system — a mature IBM DB2 MES environment built up over more than a decade — was the operational backbone of the fab. It tracked every lot, sublot, and wafer through every production stage. Stable, well-understood, and central to everything, it was also the constraint: any new capability had to integrate around it, not touch it.

The DSP carrier scratch inspection step sits at a critical juncture in the fab's production flow. A wafer that passes this checkpoint incorrectly — either a true defect approved in error, or a clean wafer unnecessarily held — carries a cost in either direction. False negatives mean defective product advancing to the next stage. False positives mean yield loss and production delays.

As inspection volumes grew across the three sites, the manual review process became an increasingly visible bottleneck. The team processing quality holds was the same team responsible for disposition — and at peak volumes, the queue was backing up. Leadership had committed to improving throughput without adding headcount, and the manual review process was the clearest opportunity.

There had been earlier discussions about automation, but the standard answer from the MES team had always been the same: any change to the inspection workflow risked disrupting live production on a system that could not afford downtime. The challenge was not a lack of will to automate — it was finding an approach that did not require touching the MES at all.

Manual inspection at scale

Every lot that entered the DSP inspection stage required an operator to open the inspection record, navigate a wafer grid of up to 25 slots, and review the image set for each wafer — typically four to six images per wafer across different focus planes. The review required trained judgment to distinguish acceptable surface variation from a genuine scratch defect. Across hundreds of lots per day at three sites, this process consumed approximately 45 minutes per lot in operator time.

No system-level consistency

The three fab sites operated separate inspection workflows with no shared disposition logic. A defect classification decision made at Imari was invisible to the QC team at Kubara. Over time, site-to-site variation in hold rates and defect code usage had grown wide enough to be visible in quality audits — but because everything lived inside the MES, there was no practical way to standardise without a full MES project.

No traceability

Disposition decisions were recorded in the MES, but the record contained only the outcome — approved, held, or escalated — not the reasoning, the images reviewed, or the identity of the operator who made the call. When a quality issue was escalated post-disposition, the investigation had to start from scratch. There was no audit trail that could answer the question: who saw what, and what did they decide?

“

"Operators don't touch AI or databases — they see lots, wafers, and pictures, and press Approve."

Principle: extend, do not replace

The defining constraint was that the existing MES — IBM DB2, SONAR inspection tooling, NAS file stores, lot/wafer/hold workflows — could not be restructured. Aarya Global designed the entire solution as a non-invasive layer: the MES is read from via existing DB2 views (DOPEHIS, DLOT, DSUBLOT, DWAFER); the AI pipeline, staging database, and operator UI all sit beside it, not inside it. Production kept running throughout the entire build and deployment.

The five-stage pipeline

• 01ETL ingestion — A .NET 8 background worker polls the DB2 MES at regular intervals, pulling delta changes using checkpoint markers and Polly-based retry logic. New lots and wafer records are staged in an Oracle database, which serves as the central state hub throughout the pipeline.
• 02SONAR integration — Inspection images are sourced from YDC SONAR via XML templates and CSV ingest. The worker serialises and stages the image paths alongside lot metadata in Oracle, ready for the AI inference step.
• 03AI inference — A Python worker running on a dedicated NVIDIA H100 GPU picks up staged lots and runs wafer images through a YOLOv8 model exported to ONNX format, executed via ONNX Runtime with CUDA acceleration. Post-inference business logic applies defect class gating, minimum area thresholds, and end-face overlap masking before writing the result back to Oracle. The worker is containerised with Podman and runs continuously as a cron-style background process.
• 04Manual QC — Lots that the AI marks as HOLD or NG are surfaced to the operator UI for human review. Approximately 70% of lots are cleared by the AI without any operator intervention. The QC step is where human judgment is applied — but only where it is genuinely needed.
• 05Disposition and reporting — Approved lots are written back through the Oracle staging layer. Every decision — AI result, operator override, defect code, timestamp, user ID, and fab site — is recorded. QC leads can export the full disposition log to Excel; supervisors have a dashboard showing live run/stop status and queue depth per site.

Why on-prem GPU inference, not cloud

This was not a cost decision — it was a data sovereignty decision. Semiconductor fabs operate under strict information security requirements. Wafer images and MES lot data are treated as proprietary manufacturing intelligence. Sending them to a cloud inference API was not an option the client would consider. The H100 sits in the fab network; inference results never leave it.

The on-prem model also eliminated the SLA dependency that cloud inference introduces. Inspection is a production-critical step. The team needed the AI to be available when the fab was running — and that availability needed to be governed by local infrastructure, not a third-party uptime guarantee.

The operator interface

The WinForms UI was built for one purpose: making it impossible for operators to make procedural mistakes. Role-based access (Operator, QC, Supervisor) ensures each person sees only the screens relevant to their job. The lot tree navigates like a folder hierarchy. The wafer grid shows 25 slots at a glance with AI results pre-populated — OK, HOLD, or NG — and image thumbnails load from the NAS on click.

Validation is built into every critical action. An operator cannot save an NG without selecting a defect code. An AI result cannot be overridden to OK without a documented reason. These guardrails were designed not to slow operators down, but to eliminate the class of errors that produce untraceable quality issues.

Multi-fab deployment

All three sites — Imari2, Kubara1, and Kubara2 — run from a single codebase with per-site configuration files. Site-level data isolation is enforced in Oracle: a record from Kubara1 is never visible in the Imari2 queue. The same AI model and business rules apply across all three sites, which for the first time gave the quality team a consistent defect classification standard across the entire operation.

Before and after

Manual review time

Before~45 min per lot

→

After~12 min per lot (73% reduction)

AI automation rate

~70% of lots cleared without operator intervention

Cross-site consistency

Single defect classification standard across all 3 fabs

Traceability

BeforeZero audit trail

→

After100% — every decision logged with user, timestamp, site

Cloud / external dependency

Fully eliminated — all inference and data stays on fab network

Operator training

New operators productive within one shift; no CLI or database access required

MES disruption

None — production ran uninterrupted throughout build and deployment

Outcomes beyond the original brief

The cross-site consistency effect was not part of the original project scope — it emerged as a by-product of standardising the AI model and business rules across all three fabs. The quality team noted that hold rate variation between sites, which had been an open issue for some time, resolved itself once all three sites were running the same inference logic.

The traceability improvement also created value in the post-disposition investigation workflow. With a full audit trail available, quality investigations that had previously required interviewing operators and reconstructing decisions from memory could now be completed in minutes from the Oracle logs.

Following deployment across all three fab sites, Aarya Global has remained engaged in a support and continuous improvement capacity. Model retraining cadence, business rule refinements as new defect patterns are identified, and additional reporting capabilities are in scope for the next phase. The reusable pipeline architecture — ETL, AI worker, Oracle state machine, operator UI — is also being evaluated for application to other inspection points in the production flow.

Reusable Capability

The architecture built for this engagement — non-invasive MES integration, on-prem GPU AI, human-in-the-loop QC with guardrails, and multi-site deployment from a single codebase — is directly reusable for other fabs or manufacturing environments that run legacy MES infrastructure and need AI-augmented quality control without a full systems rebuild.

If your organisation is navigating a similar challenge — automating inspection on a legacy MES, deploying AI in an air-gapped or controlled environment, or standardising quality decisions across multiple production sites — we would be glad to share how we approached it and whether a similar model could apply to your situation.