Map
Identify read-only integration points into IBM DB2 without touching MES schema
The situation
Our client operates three silicon fabrication sites in Japan, producing high-precision wafer substrates for advanced electronics under strict quality mandates. Their manufacturing execution system — a mature IBM DB2 MES built up over more than a decade — tracked every lot, sublot, and wafer through every production stage, and could not afford to be touched.
Before the platform, the quality team was working with:
- ~45 minutes of operator time per lot reviewing wafer image grids manually
- No shared disposition logic across the three fab sites
- Visible hold-rate variation between sites, with no practical way to standardise
- Disposition records that captured the outcome but not the reasoning or images reviewed
- A queue that kept backing up as inspection volume grew, without added headcount
There had been earlier discussions about automation, but the standard answer from the MES team was always the same: any change to the inspection workflow risked disrupting live production. The challenge wasn't a lack of will — it was finding an approach that never touched the MES at all.
The challenge
The challenge was to give three fab sites a consistent, auditable AI-assisted inspection workflow — without restructuring, or even touching, a mature MES that the whole operation depended on staying stable.
Our approach
The defining constraint shaped every decision: extend the existing MES, don't replace it. The AI pipeline, staging database, and operator UI needed to sit beside the MES, not inside it, while production kept running.
Our objective was to:
Build
Stand up a 5-stage AI pipeline — ETL, SONAR, inference, QC, disposition — beside the MES
Guardrail
Give operators validation rules that make untraceable overrides impossible
Scale
Deploy the same codebase safely across three fab sites with isolated data
What we did
1
Built a five-stage pipeline that sits beside the MES, not inside it
The MES is read from via existing DB2 views — DOPEHIS, DLOT, DSUBLOT, DWAFER. The AI pipeline, staging database, and operator UI all live alongside it. Production kept running throughout the entire build and deployment.
The five stages:
- ETL ingestion — a .NET 8 worker polls DB2 on delta checkpoints with Polly-based retries
- SONAR integration — inspection images sourced via YDC SONAR XML templates and CSV ingest
- AI inference — a Python worker on an NVIDIA H100 runs YOLOv8 (ONNX Runtime, CUDA)
- Manual QC — only lots the AI marks HOLD or NG are surfaced for human review
- Disposition and reporting — every decision logged with user, timestamp, and fab site
2
Kept AI inference fully on-prem
This wasn't a cost decision — it was a data sovereignty decision. Wafer images and MES lot data are treated as proprietary manufacturing intelligence, and sending them to a cloud inference API was never an option the client would consider.
What on-prem inference removed:
- No wafer images or lot data ever leave the fab network
- No dependency on a third-party inference SLA for a production-critical step
- The H100 GPU runs continuously as a containerised background process on-site
3
Designed a WinForms UI that makes procedural mistakes hard to make
Role-based access — Operator, QC, Supervisor — means each person only sees the screens relevant to their job. The wafer grid shows 25 slots at a glance with AI results pre-populated: OK, HOLD, or NG.
Guardrails built into every critical action:
- An operator can't save an NG without selecting a defect code
- An AI result can't be overridden to OK without a documented reason
- Post-inference rules apply defect class gating, area thresholds, and end-face masking
These guardrails weren't designed to slow operators down — they eliminate the class of errors that produce untraceable quality issues.
4
Deployed across three fab sites from a single codebase
Imari2, Kubara1, and Kubara2 all run the same AI model and business rules, with per-site configuration files and enforced data isolation in Oracle — a record from Kubara1 is never visible in the Imari2 queue.
What this gave the quality team, for the first time:
- A single, consistent defect classification standard across the entire operation
- Excel export and a live supervisor dashboard showing run/stop status and queue depth per site
- A full disposition log — AI result, override, defect code, timestamp, user ID, fab site
How it works
A five-stage pipeline that reads from the existing MES and writes back to it — without ever touching its schema.
1
ETL ingestion
A .NET 8 worker polls IBM DB2 on delta checkpoints and stages new lot and wafer records.
.NET 8 worker · DB2 delta poll2
SONAR integration
Inspection images are resolved from YDC SONAR XML templates and linked to staged records.
YDC SONAR XML / CSV3
H100 AI inference
A YOLOv8 ONNX model runs on an on-prem NVIDIA H100, applying business rules after inference.
YOLOv8 ONNX · CUDA on H1004
Operator QC review
Only lots the AI marks HOLD or NG are surfaced for human review in a role-based UI.
WinForms · Japanese locale5
Disposition & reporting
Every decision is logged with user, timestamp, and fab site, exportable per site or date range.
Oracle state machine · Excel export“
“Operators don’t touch AI or databases — they see lots, wafers, and pictures, and press Approve.” That was the design brief from the start. The complexity lives entirely in the back end.
Atomic Loops project brief
73%
Faster manual review
~45 min per lot to ~12 min per lot
~70%
Lots cleared by AI alone
No operator intervention required
100%
Decisions traceable
User, timestamp, and fab site on every record
0
MES disruption
Production ran uninterrupted through build and rollout
The outcome
What changed across the three fab sites:
- Manual review time per lot cut from ~45 minutes to ~12 minutes
- Roughly 70% of lots cleared by the AI without any operator intervention
- A single, consistent defect classification standard across all three fabs — hold-rate variation between sites resolved on its own once the same logic ran everywhere
- A complete audit trail turned post-disposition investigations that once required interviewing operators into something reconstructable from the Oracle logs in minutes
- Fully on-prem inference — zero cloud dependency, zero external data egress
- New operators productive within a single shift, with no CLI or database access required
Frequently asked questions (FAQs)
1) What is a non-invasive MES integration?
It means building new capability — an AI pipeline, a staging database, an operator UI — that reads from an existing manufacturing execution system through existing views, without changing its schema or workflow, so the MES itself is never at risk.
2) Why deploy AI inference on-prem instead of in the cloud for semiconductor manufacturing?
Wafer images and MES lot data are proprietary manufacturing intelligence under strict information security requirements. On-prem inference keeps that data on the fab network and removes dependency on a third-party uptime guarantee for a production-critical step.
3) What is YOLOv8 and how is it used in wafer defect inspection?
YOLOv8 is an object detection model. Exported to ONNX and run on-prem, it scans wafer images for defect patterns like carrier scratches and flags them for review, pre-screening the majority of lots before any human sees them.
4) How does an AI inspection system maintain traceability across multiple fab sites?
Every decision — AI result, operator override, defect code, timestamp, user ID, and fab site — is logged centrally, giving quality teams a full audit trail regardless of which site a lot came from.
5) What are the risks of automating quality inspection on a legacy MES?
The main risk is disrupting a system the whole operation depends on. Designing the automation as a non-invasive layer that only reads from the MES, rather than modifying it, removes that risk.
6) How does human-in-the-loop QC work alongside AI inspection?
The AI clears the majority of lots automatically and surfaces only the ones it flags as HOLD or NG for human review, so operator time is spent on judgment calls rather than routine screening.
7) What is ONNX Runtime and why does it matter for on-prem inference?
ONNX Runtime executes a trained model in a portable format with hardware acceleration — in this case CUDA on an NVIDIA H100 — allowing fast, on-prem inference without a cloud dependency.
8) How does Atomic Loops help manufacturers modernise inspection without disrupting production?
By treating the existing MES as a fixed constraint and designing every new component to sit alongside it — validated in a pilot before multi-site rollout, with production running throughout.
Industry Services
Education
Focus areas - Education
© 2026 London School of DIGITAL BUSINESS.
All Rights Reserved