Detection, Measurement & Inspection Logic

This topic sits inside your roadmap’s Vision, Imaging & Inspection Systems domain, especially the parts around measurement systems, defect detection concepts, and practical inspection workflows.

---

PART 1 — WHAT INSPECTION LOGIC REALLY DOES

Inspection logic is the part of the vision system that turns visual evidence into an operational decision.

The camera does not “fail” a wafer.

The image processing pipeline does not “reject” a part.

The detector does not necessarily decide quality.

The inspection logic is where the system asks:

• Is there a defect?
• Where is it?
• How large is it?
• How severe is it?
• Does it exceed tolerance?
• Should the product pass, fail, be reworked, or require human review?

In a wafer inspection machine, the system may capture a high-resolution image of a die, process the image, detect suspicious regions, measure their size or intensity, classify them as scratch / particle / stain / pattern defect, then decide whether the die is acceptable.

A useful mental model is this:

Raw Image
   ↓
Image Processing
   ↓
Detection
   ↓
Measurement
   ↓
Classification
   ↓
Inspection Decision
   ↓
Machine Action / UI / Storage

These stages are related, but they are not the same.

Image processing prepares the image. It may normalize contrast, remove noise, enhance edges, or isolate regions.

Detection finds candidates. For example: “There is something suspicious at X=1200, Y=830.”

Measurement quantifies something. For example: “The defect area is 18.4 µm²” or “The width is 49.2 µm.”

Classification assigns meaning. For example: “This candidate is likely a particle defect.”

Final decision applies business, process, recipe, or quality rules. For example: “Fail this die because particle area exceeds the recipe limit.”

The key architectural point is this:

Detection finds evidence. Inspection logic decides what that evidence means.

That separation matters a lot.

A detector may produce ten candidate defects. The final inspection may ignore five because they are outside the region of interest, downgrade three because they are below threshold, flag one for review, and fail one because it violates a critical rule.

In real systems, inspection logic is not just an algorithm. It is a controlled decision system.

---

PART 2 — DETECTION CONCEPTS

Detection means finding something of interest in an image or region.

That “something” may be:

• a defect
• an edge
• a hole
• a missing component
• an alignment mark
• a particle
• a scratch
• a blob
• an incorrect pattern
• a surface stain
• a broken line
• a foreign object

Detection usually produces candidate findings, not final decisions.

For example:

Processed Image / Features
          ↓
      Detector
          ↓
 Candidate Findings
          ↓
 Inspection Logic

A candidate finding usually contains structured information:

CandidateFinding
  ├─ Location
  ├─ Region / BoundingBox
  ├─ Score / Confidence
  ├─ Size / Area
  ├─ Category Hint
  ├─ Source Detector
  └─ Supporting Measurements

A detector may say:

Candidate defect found:
- Location: X=12.482 mm, Y=8.731 mm
- Area: 23.7 µm²
- Contrast score: 0.82
- Detector: BrightParticleDetector
- Region: Die active area

But that does not automatically mean the product fails.

Why?

Because detection is evidence, not judgment.

The inspection logic still needs to ask:

• Is this region inspectable?
• Is the candidate inside a critical area?
• Is the size above threshold?
• Is the confidence high enough?
• Is the defect type relevant for this recipe?
• Is this candidate duplicated by another detector?
• Is the image quality good enough to trust this result?
• Is the measurement calibrated?
• Is this a fail, warning, review, or ignored condition?

A common mistake by software engineers new to vision systems is to let detector output directly drive machine decisions.

Bad design:

if detector.FoundDefect:
    result = FAIL

Better design:

Detector Output
      ↓
Candidate Validation
      ↓
Measurement
      ↓
Rule Evaluation
      ↓
Decision Reason
      ↓
Final Result

Detection should be treated as one input into a decision model.

---

PART 3 — MEASUREMENT SYSTEMS

Measurement means extracting quantitative values from image data.

Examples include:

• distance
• width
• height
• diameter
• angle
• area
• perimeter
• center position
• offset from expected location
• edge position
• intensity value
• intensity profile
• defect density
• gap between features
• alignment error

In wafer inspection, a measurement may answer:

How far is this feature from its expected location?
How wide is this line?
How large is this particle?
How much does this pattern shift from reference?

In component inspection, it may answer:

Is the component present?
Is it rotated?
Is it shifted?
Is the solder area large enough?
Is the pin bent?

A measurement is not just a number. It has context.

Bad model:

Width = 49.2

Good model:

Measurement
  ├─ Name: LineWidth
  ├─ Value: 49.2
  ├─ Unit: µm
  ├─ Nominal: 50.0
  ├─ Tolerance: ±2.0
  ├─ CoordinateSpace: WaferStage
  ├─ CalibrationId: Calib-2026-04-20
  ├─ ImageId: Frame-88412
  ├─ RegionOfInterest: ROI-ActiveArea-3
  ├─ Quality: Good
  └─ Uncertainty: ±0.4

The same numeric value may mean different things depending on calibration, resolution, image quality, and coordinate mapping.

For example, 49.2 µm may be acceptable if the tolerance is 50 ± 2 µm.

But it may be suspicious if:

• calibration recently changed
• edge contrast is weak
• the image is slightly blurred
• the measurement is near the tolerance boundary
• the coordinate transform is stale
• the result differs from previous machines

Measurement depends on several things:

Image Quality
   ↓
Edge / Feature Stability
   ↓
Pixel Resolution
   ↓
Calibration
   ↓
Coordinate Mapping
   ↓
Measurement Value
   ↓
Decision Confidence

This is why experienced engineers do not treat measurements as plain numbers.

They treat them as:

value + unit + context + confidence + traceability.

---

PART 4 — THRESHOLDS, TOLERANCES, AND CLASSIFICATION

Thresholds define decision boundaries.

Tolerances define acceptable ranges.

Classification maps findings into meaningful categories.

Examples:

Defect area > 10 µm²
    → Fail

Width < 48 µm or Width > 52 µm
    → Fail

Confidence < 0.7
    → Review

Particle inside critical region
    → Fail

Particle outside critical region
    → Warning only

A simple inspection decision flow may look like this:

+----------------------+
| Candidate Finding    |
+----------+-----------+
           |
           v
+----------------------+
| Validate ROI / Mask  |
+----------+-----------+
           |
           v
+----------------------+
| Measure Properties   |
+----------+-----------+
           |
           v
+----------------------+
| Apply Recipe Rules   |
+----------+-----------+
           |
           v
+----------------------+
| Classify Severity    |
+----------+-----------+
           |
           v
+----------------------+
| Pass / Fail / Review |
+----------------------+

A more realistic decision tree:

Candidate Defect
      |
      v
Inside inspectable region?
      |
   +--+--+
   |     |
  No    Yes
   |     |
Ignore  Measure size / contrast / location
          |
          v
     Image quality acceptable?
          |
       +--+--+
       |     |
      No    Yes
       |     |
    Review  Apply thresholds
              |
              v
       Exceeds fail limit?
              |
           +--+--+
           |     |
          No    Yes
           |     |
        Pass /  Fail
        Warning

Thresholds are usually recipe-driven.

That means the threshold is not hardcoded in the algorithm. It comes from the inspection recipe.

For example:

Recipe: Product-A / Customer-X / Layer-3

Defect Rules:
  - MaxParticleArea: 8.0 µm²
  - MaxScratchLength: 15.0 µm
  - MinConfidenceForAutoFail: 0.85
  - LowConfidenceAction: Review
  - IgnoreRegions: EdgeExclusionMask

Why recipe-driven?

Because different products, customers, process layers, or manufacturing steps may have different quality requirements.

The same defect may be acceptable in one context and fatal in another.

For example:

Small particle in non-critical region
    → acceptable for Product A

Same particle in active circuit region
    → fail for Product B

This is why inspection logic must be configurable but controlled.

Too rigid, and the machine cannot support real production variation.

Too flexible, and recipe mistakes can destroy quality consistency.

---

PART 5 — FALSE POSITIVES, FALSE NEGATIVES, AND STABILITY

A false positive means the system flags a defect when the product is actually acceptable.

A false negative means the system misses a real defect.

Both are dangerous, but in different ways.

False positives cause:

• unnecessary rejects
• lower throughput
• operator distrust
• extra manual review
• customer complaints about over-rejection
• pressure to loosen thresholds

False negatives cause:

• bad parts escaping
• quality incidents
• customer returns
• loss of confidence in the inspection system
• potentially expensive downstream failures

In real factories, the best inspection system is not simply the most sensitive one.

If sensitivity is too high, the machine may fail too many good products.

If sensitivity is too low, the machine may miss real defects.

The architect’s challenge is to design software that supports controlled trade-offs.

Too Sensitive
   ↓
Many false positives
   ↓
Low trust / low throughput

Too Loose
   ↓
Many false negatives
   ↓
Quality escape risk

Balanced Inspection
   ↓
Stable detection + explainable thresholds + review path

Inspection stability means:

The same product, inspected under the same conditions, should produce the same decision.

Instability is one of the most painful production problems.

It looks like this:

Run 1: PASS
Run 2: FAIL
Run 3: PASS
Run 4: REVIEW

For the same product.

This destroys trust.

Common causes include:

• lighting variation
• focus drift
• vibration
• unstable edge detection
• threshold too close to noise
• calibration mismatch
• inconsistent region selection
• nondeterministic processing order
• floating-point or rounding differences
• machine-to-machine variation
• recipe version mismatch

A strong inspection system should be designed to expose why decisions changed.

Not just:

FAIL

But:

FAIL
Reason:
- Defect D-004 exceeded MaxParticleArea
- Measured area: 10.8 µm²
- Threshold: 8.0 µm²
- Region: CriticalDieArea
- Recipe: Product-A v17
- Detector: BrightParticleDetector v3.2
- Image quality: Good

That kind of result is diagnosable.

---

PART 6 — RESULT MODELING

Pass/fail alone is not enough.

A serious industrial inspection result should contain enough information to explain, replay, review, and diagnose the decision.

A useful model looks like this:

InspectionResult
  ├─ Decision
  │    ├─ Status: Pass / Fail / Review / Warning
  │    ├─ ReasonCodes
  │    └─ Severity
  │
  ├─ Measurements
  │    ├─ Name
  │    ├─ Value
  │    ├─ Unit
  │    ├─ Tolerance
  │    └─ Quality
  │
  ├─ Defects
  │    ├─ Type
  │    ├─ Location
  │    ├─ Size / Area
  │    ├─ Score
  │    └─ Region
  │
  ├─ Context
  │    ├─ ImageId
  │    ├─ FrameId
  │    ├─ Wafer / Die / Part Position
  │    ├─ RecipeVersion
  │    ├─ CalibrationId
  │    └─ AlgorithmVersion
  │
  └─ Diagnostics
       ├─ ImageQualityFlags
       ├─ RuleEvaluations
       ├─ Warnings
       └─ ProcessingTime

This model matters because real production problems often happen days or weeks later.

Someone will ask:

Why did this wafer fail?
Why did this die pass yesterday but fail today?
Which threshold caused the decision?
Was the image quality bad?
Was the recipe changed?
Was the algorithm updated?
Did this machine behave differently from another machine?

If the result model only says:

Result = FAIL

you cannot answer.

A better result says:

Decision: FAIL
Reason: WidthOutOfTolerance
Measurement:
  Name: LineWidth
  Value: 46.7 µm
  Allowed: 48.0 - 52.0 µm
Context:
  Recipe: Product-A v18
  Calibration: Calib-2026-04-22
  Image: Frame-883391
Diagnostics:
  EdgeQuality: Medium
  FocusQuality: Good

That is the difference between a demo system and a production inspection system.

---

PART 7 — REAL-WORLD FAILURE SCENARIOS

Scenario 1: Threshold works in lab but fails in production lighting variation

In the lab, the detector works well. The sample images are clean. The lighting is stable. The threshold looks reasonable.

In production, the same threshold causes many false defects.

What it looks like:

Morning shift: mostly PASS
Afternoon shift: sudden increase in FAIL
Night shift: many REVIEW results

Why it happens:

• lighting intensity changed
• surface reflectivity varies by batch
• exposure setting drifted
• illumination angle makes harmless texture look like defects
• lab samples did not represent production variation

How experienced engineers handle it:

• compare image quality metrics across shifts
• inspect raw and processed images side by side
• look at score distributions, not single examples
• separate image quality problems from rule problems
• tune thresholds using production data
• add warning flags when image conditions are outside expected range

Key architecture lesson:

Thresholds need context. A threshold without image quality evidence is fragile.

---

Scenario 2: Measurement shifts because calibration changed

A measurement that used to be stable suddenly shifts by a small but significant amount.

What it looks like:

Before calibration:
Width average = 50.1 µm

After calibration:
Width average = 48.9 µm

The product did not change, but the measurement changed.

Why it happens:

• pixel-to-world calibration changed
• wrong calibration file loaded
• camera resolution setting changed
• lens or magnification changed
• coordinate transform changed
• calibration was done poorly

How experienced engineers diagnose it:

• compare calibration IDs in results
• replay old images with old and new calibration
• check pixel measurements versus world-unit measurements
• verify calibration target data
• compare results across machines
• check whether only world-unit values shifted

Key architecture lesson:

Measurement results must record calibration context.

Without calibration traceability, engineers may blame the product when the measurement system changed.

---

Scenario 3: Defect detection unstable near image noise

A tiny candidate appears and disappears between runs.

What it looks like:

Run 1: no defect
Run 2: particle detected, area 7.9 µm²
Run 3: particle detected, area 8.2 µm²
Run 4: no defect

Why it happens:

• defect is close to noise level
• image contrast is weak
• focus is marginal
• threshold is too close to natural variation
• detector is sensitive to small pixel changes

How experienced engineers handle it:

• analyze score distribution
• inspect borderline candidates
• define review zones near thresholds
• add confidence or quality flags
• avoid hard binary decisions near unstable boundaries
• improve image acquisition if needed

Better logic:

Area < 7.0 µm²
    → Pass

Area 7.0 - 9.0 µm²
    → Review

Area > 9.0 µm²
    → Fail

Instead of:

Area > 8.0 µm²
    → Fail

Key architecture lesson:

Borderline cases need explicit handling.

---

Scenario 4: Algorithm detects candidate but decision logic interprets it incorrectly

The detector finds the right object, but the decision layer applies the wrong meaning.

What it looks like:

Detector: Candidate found in non-critical edge region
Decision: FAIL

But according to process rules, that region should have been ignored.

Why it happens:

• wrong region mask
• wrong coordinate mapping
• missing rule condition
• detector output category misunderstood
• recipe parameter mapped to wrong rule
• inspection logic assumes all defects are equal

How experienced engineers diagnose it:

• inspect candidate location
• overlay detection on region masks
• review rule evaluation trace
• compare expected versus actual rule path
• check recipe-to-rule mapping

Key architecture lesson:

Detection output should not bypass rule evaluation.

The decision layer must understand regions, masks, product context, and recipe rules.

---

Scenario 5: Pass/fail result cannot be explained later

A customer asks why a product failed.

The system only stored:

Product: FAIL
Time: 10:42:11

No measurements. No thresholds. No image ID. No reason code.

What it looks like:

• engineers cannot reproduce the decision
• operators cannot explain rejects
• customer support becomes guesswork
• teams argue based on screenshots or memory

Why it happens:

• result model too shallow
• no decision trace
• thresholds not recorded
• recipe versions not stored
• algorithm versions not stored
• diagnostic data discarded

How experienced engineers handle it:

• design structured inspection results
• store decision reason codes
• store rule evaluations
• store recipe and algorithm versions
• support offline replay
• keep enough context for review

Key architecture lesson:

Every fail should be explainable.

---

Scenario 6: Same product gets different decisions across machines

Machine A passes the product. Machine B fails it.

What it looks like:

Machine A:
Measured width = 50.1 µm → PASS

Machine B:
Measured width = 47.8 µm → FAIL

Why it happens:

• different calibration
• different lighting
• different focus behavior
• different camera settings
• different recipe version
• different algorithm version
• mechanical alignment differences
• environmental differences

How experienced engineers diagnose it:

• compare recipe versions
• compare calibration IDs
• compare image quality metrics
• inspect raw images from both machines
• run golden sample tests
• replay same image through both software versions
• compare measurement distributions

Key architecture lesson:

Machine-to-machine consistency requires versioned recipes, calibration traceability, and comparable diagnostics.

---

Scenario 7: Recipe change affects inspection unexpectedly

A process engineer adjusts one threshold to reduce false positives.

Suddenly another defect class behaves differently.

What it looks like:

Change:
ParticleMinArea = 6.0 → 8.0

Unexpected effect:
Scratch classification rate changes

Why it happens:

• shared parameter used by multiple rules
• unclear recipe semantics
• hidden coupling between detectors
• rule dependency not documented
• no recipe validation
• no regression testing on image sets

How experienced engineers handle it:

• version recipes
• diff recipe changes clearly
• validate recipe changes offline
• run regression image sets
• show affected rules before activation
• require approval for critical parameters

Key architecture lesson:

Recipe parameters are production logic. Treat them with the same seriousness as code.

---

PART 8 — SOFTWARE DESIGN IMPLICATIONS

Inspection logic must be explicit, traceable, and testable.

A good architecture separates concerns:

Processed Image + Metadata
        ↓
Detection / Measurement
        ↓
Inspection Rules
        ↓
Decision + Diagnostics
        ↓
Machine / UI / Storage

The components should not be mixed together.

Bad design:

ImageProcessor
  ├─ filters image
  ├─ detects defects
  ├─ applies thresholds
  ├─ updates UI
  ├─ writes database
  └─ sends fail command to machine

This becomes hard to test, hard to explain, and dangerous to change.

Better design:

+----------------------+
| Image Processing     |
| prepares evidence    |
+----------+-----------+
           |
           v
+----------------------+
| Detection Service    |
| finds candidates     |
+----------+-----------+
           |
           v
+----------------------+
| Measurement Service  |
| produces values      |
+----------+-----------+
           |
           v
+----------------------+
| Inspection Rules     |
| evaluates criteria   |
+----------+-----------+
           |
           v
+----------------------+
| Result Builder       |
| creates explanation  |
+----------+-----------+
           |
           v
+----------------------+
| Machine/UI/Storage   |
| consumes result      |
+----------------------+

The rule layer should be explicit.

For example:

Rule: FailIfParticleAreaExceedsLimit

Inputs:
  - Defect.Type
  - Defect.Area
  - Defect.Region
  - Recipe.MaxParticleArea
  - ImageQuality.Status

Output:
  - Pass / Fail / Review
  - ReasonCode
  - DiagnosticMessage

Do not hide this logic inside image algorithm code.

A good inspection result should answer:

What was found?
Where was it found?
How was it measured?
Which rule evaluated it?
Which threshold was used?
Which recipe version provided the threshold?
Why was the final decision made?
Was the image reliable enough?
Can we replay the same case later?

A bad system says:

FAIL

A good system says:

FAIL because Defect D-17 was classified as Particle,
inside CriticalRegion-2,
with measured area 12.4 µm²,
exceeding recipe threshold 8.0 µm²,
using Recipe Product-A v21,
Algorithm DefectClassifier v3.4,
Calibration Calib-2026-04-18.

That is production-grade inspection logic.

---

PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS

A strong way to explain this in an interview:

In an industrial vision system, image processing prepares the data, detection finds candidate evidence, measurement quantifies that evidence, classification gives it meaning, and inspection logic applies recipe-driven rules to produce a traceable decision. I would avoid letting raw detector output directly control pass/fail. Instead, I would produce structured results with measurements, thresholds, recipe version, calibration context, decision reason, and diagnostics so the system is explainable, replayable, and stable in production.

Another strong point:

Pass/fail alone is not enough. In production, engineers need to know why something failed, which rule fired, what threshold was used, whether the image quality was acceptable, and whether calibration or recipe changes affected the result.

Common mistakes software engineers make when entering vision systems:

Mistake 1:
Treating detector output as final decision.

Mistake 2:
Hardcoding thresholds in code.

Mistake 3:
Ignoring calibration and units.

Mistake 4:
Returning only pass/fail.

Mistake 5:
Not storing rule evaluation details.

Mistake 6:
Not handling borderline cases.

Mistake 7:
Assuming lab performance equals production performance.

Mistake 8:
Ignoring false positives and operator trust.

Mistake 9:
Ignoring false negatives and quality escape risk.

Mistake 10:
Making recipe changes without offline regression testing.

What strong engineers understand:

Detection is evidence.
Measurement is contextual.
Thresholds are decision boundaries.
Recipes are production logic.
Pass/fail must be explainable.
Borderline cases need careful handling.
Calibration changes can shift measurements.
Image quality affects decision confidence.
Stable decisions matter as much as accurate algorithms.
Replay and diagnostics are architecture requirements, not nice-to-have features.

The core lesson:

Industrial inspection software is not just about finding defects. It is about making reliable, explainable, repeatable decisions from imperfect visual evidence under real production variation.