When the Reference Color Became a Variable

Solving a Three-Week Standoff in Three Hours

As a yield management engineer, I often sit between process teams and equipment teams. Both sides are technically correct — yet nothing moves, because they’re speaking different languages. Over time I learned that my job wasn’t to be the smartest person in the room. It was to make two smart people understand each other.

Judging measured data as pass or fail sounds straightforward. But in manufacturing, ambiguity is where real problems live. That’s especially true for optics — where “what you see” can be shaped by conditions that have nothing to do with performance.

Cosmetic defect inspection is one of the hardest examples. The defects may not affect electrical performance, but customers still reject them. Inspection has to be consistent — even when the underlying reality refuses to cooperate.

ITO and an Unexpected Problem

Our final metal scheme changed. What had been opaque metal became ITO (Indium Tin Oxide).

ITO is a transparent conductive oxide. Electrically, it behaves like a conductor. Optically, it behaves like a thin film — meaning its apparent color shifts with thickness.

The first time I saw the wafers after the change, I thought they looked defective. They weren’t — I knew that intellectually — but the eye doesn’t care about intellectual certainty. In some conditions, a thickness change on the order of tens of nanometers could turn the surface from green to purple. It was dramatic enough to feel like a defect, even when it wasn’t.

From a process standpoint, achieving perfectly uniform thickness across an entire wafer is physically unrealistic. Variations between center and edge — and across positions — are natural. A certain range of thickness variation is simply “normal.”

And yet the optical inspection tool didn’t care what was normal.

The Original Inspection Logic

Back then, cosmetic inspections were transitioning from manual microscope checks to automated optical inspection.

The basic logic looked like this:

1. Set a reference color (the color of a “good” product)
2. Measure color difference (pixel-by-pixel deviation from the reference)
3. Judge defects if the area exceeding a tolerance threshold passes a ratio limit (for example, 30%)

A fixed reference color works fine when “good” products are visually consistent.

ITO broke that assumption.

Three Weeks of Deadlock

With ITO, chips on the same wafer could appear in different colors — green, purple, blue — simply due to natural thickness variation. There was no electrical issue. But the inspection tool interpreted those color shifts as defects.

For three weeks, meetings went nowhere.

The equipment engineer said: “If the color keeps changing, inspection is impossible. Stabilize the process.”

The process engineer replied: “±5% thickness variation is within spec. This isn’t a defect — it’s thin film optics.”

Both were correct. Both were stuck.

Meanwhile, shipment deadlines approached. Production was effectively stalled by an inspection rule that no longer matched reality. I spent those weeks listening to arguments that weren’t really arguments — they were two different definitions of “normal.” And as the yield engineer in the middle, I had to help the teams move from being right to being able to ship.

Redefining the Problem

I already knew that “standardizing all chip colors” wasn’t a realistic ask. But telling the equipment team to “just solve it” wouldn’t help either.

So instead of arguing about blame, we did something simpler: we aligned on what was true.

Step 1: Establish common ground

All three of us agreed on these points:

1. The color variation caused by ITO thickness variation could not be eliminated within current process capability.
2. The inspection method labeled defects based on the ratio of area that deviated from the reference.
3. If the reference color was assumed to be a constant, inspection would keep collapsing under normal variation.

Step 2: Ask a different question

Then I asked the equipment engineer one question:

“What if reference color isn’t a constant?”

I wasn’t proposing a brilliant insight. I was just asking whether we could stop fighting the variation and start accounting for it.

More concretely: Instead of enforcing one global reference for all chips, what if we defined the reference per chip — using each chip’s dominant color as its own baseline?

For example: When inspecting a chip, identify the color that occupies most of its area — say around 80% — and treat that as the reference for that chip. Then detect defects as “regions that deviate from the chip’s own baseline,” rather than “regions that deviate from an external standard.”

I didn’t feel clever when I asked it. I felt something closer to relief — because for the first time in three weeks, the problem sounded like it might actually be solvable.

The equipment engineer paused, looked puzzled, and then — almost visibly — reframed the problem in his head.

“…If we do it that way,” he said, “it should be possible.”

The Fix: Three Hours

The equipment developer modified the logic in a few hours. We tested it on the floor immediately, and it worked.

Here’s what changed — not implementation details, just the core decision:

Before: Fixed reference (constant)

The system used one global reference color for all chips. Each chip was compared against this single standard. If too much of the chip deviated from that fixed color, it was rejected.

After: Adaptive reference (variable)

The system calculated a reference color for each individual chip based on its dominant color (the color occupying most of its area). Each chip was then compared against its own baseline, not a global standard.

Nothing about the physics changed. Nothing about the process magically became more uniform. We simply stopped asking the inspection tool to compare every chip to a reference that no longer existed.

In plain terms: we stopped treating variation as the enemy. We made it the baseline.

Verification: Numbers That Mattered

We ran 1,000 chips in the first week after the modification.

A note on the numbers — since “over-detection” and “under-detection” can be ambiguous:

• Over-detection = false rejects (good chips incorrectly labeled defective), confirmed via manual review against golden reference
• Under-detection = missed rejects (true cosmetic defects incorrectly labeled good), also verified by review criteria

Old method (fixed reference)

• Over-detection: 45%
• Under-detection: 2%
• Inspection pass rate: 53% (actual electrical yield was far higher; inspection was the bottleneck)

New method (adaptive reference)

• Over-detection: 8%
• Under-detection: 2% (maintained)
• Inspection pass rate: 92%

We met the shipment deadline without delay, and the stalled line started moving again. I remember the mood shift more than the numbers — the quiet moment when everyone stopped debating and started working.

What This Was Really About

In hindsight, this wasn’t a technically complicated problem.

It was a problem of measurement reference.

The original inspection logic treated reference color as something intrinsic and stable — like metal. But ITO changed the world underneath that assumption. The reference itself became variable, so the measurement system had to adapt.

The key wasn’t superior code. It was recognizing that the real question wasn’t “How do we stabilize the process?” or “How do we make the tool smarter?”

It was: “What should be constant, and what should be allowed to vary?”

That single reframing did what three weeks of argument could not.

Turning Chaos into Structure

This happened nearly 20 years ago, but the pattern hasn’t changed.

Manufacturing is full of situations where teams are individually right and collectively stuck. When that happens, progress depends on someone who can translate constraints into a shared problem statement — and then reshape the logic so reality fits inside it.

That day left me with a habit I still use: before I argue about solutions, I look for the hidden constant. Most deadlocks are built on one.

The fix wasn’t “adaptive reference color.”

The fix was converting chaos into structure — by changing the unit of comparison from the whole system to the individual chip.

And once you see that move — constant to variable — you start seeing it everywhere.

Twenty-three years in chaotic manufacturing taught me this: the hardest problems aren’t solved by smarter algorithms. They’re solved by better questions. And the best questions often start with: “What are we holding constant that should actually be allowed to move?”