In many machine vision projects, the algorithms are already functional, yet they simply can’t be delivered.

The most common scenario on site is as follows:

The customer said:

“How come this wasn’t detected?”

The engineer said:

“This counts as a boundary sample; it’s not necessarily a bad one.”

The customer said again:

“This definitely can’t leak out.”

The supplier says again:

“But in the samples provided earlier, this situation was considered acceptable.”

No matter how much we talk, in the end it just turns into bickering.

On the surface, everyone is arguing about whether the algorithm is accurate or not. In reality, what’s really at stake is something much more fundamental:

What exactly counts as qualified, and what counts as unqualified?

If this issue isn't clarified from the start, no matter how much you adjust the algorithm later, you'll be at a disadvantage.

Many projects aren't failing because the algorithms are inadequate—rather, it's because the standards haven't been clearly defined.

Machine vision doesn't rely on subjective judgment—it essentially executes standards.

But the most troublesome aspect of many projects is that the standards are initially vague.

Obviously good products—no one has any objections. Obviously bad products—no one has any objections either.

The samples that really tend to run into trouble are those stuck in the middle.

For example, minor scratches, shallow dents, small burrs, localized reflections, and slight dirt.

It looks a bit problematic, but it’s not particularly serious.

On-site personnel might find it acceptable, while quality inspectors might feel it can’t be approved. The customer might say it’s okay today but change their mind tomorrow.

This type of sample is a boundary sample.

The boundary samples are unclear and inconsistent; there will definitely be repeated arguments later on.

If boundary samples aren't clearly defined in advance, problems will definitely arise later on.

Because an algorithm is not a human, it cannot understand these words:

“Close enough is fine.”

“It depends on the situation.”

“You’d better not have this.”

“This is occasionally acceptable.”

If you don’t give it a clear boundary, it can only make judgments based on data and rules.

The result is:

The customer feels the algorithm is missing detections. The engineer believes the customer has temporarily changed the standards. The customer thinks the supplier lacks competence. The supplier feels the customer’s standards keep changing.

In the end, the project wasn't stuck on technical issues—it was stuck on communication and standards.

A limited sample is, in essence, simply clarifying things in advance.

Therefore, limit samples are very important.

Simply put, the limit sample approach means everyone sits down in advance and carefully identifies the samples that are most likely to spark arguments, confirming them one by one:

Is this considered?

Does this have to be classified as a negative?

Is this level still acceptable?

Would it be okay if it got any more serious?

Once these samples are confirmed, it’s as if a line has been drawn for the visual system.

This line isn't just for the algorithm—it's also visible to customers, suppliers, on-site personnel, and quality inspectors.

Without a limited sample, everything that follows is just speaking based on intuition. With a limited sample, there’s something solid to base your arguments on afterward.

Without limit samples, it’ll just be a constant cycle of patching up.

Many projects are initially reluctant to spend time on this task, thinking it’s better to get the algorithm running first.

It wasn't until the acceptance phase afterward that we realized the real trouble wasn't the model training itself—it was that everyone had completely different interpretations of what “qualified” meant.

Then I started making repeated revisions.

Today, the customer said this needs to be detected, so the engineer added a rule. Tomorrow, there’ll be too many false positives, and we’ll have to relax the criteria again. The day after tomorrow, we’ll switch to a new batch of materials, and the threshold will change once more.

In the end, the software ended up with a pile of parameters, the system became increasingly complex, yet the project grew ever harder to deliver.

At this point, you’ll realize:

Everyone thinks they’re tuning the algorithm, but in reality, they’ve been constantly filling in the blanks for standards that weren’t clearly defined earlier.

A mature visual project will definitely define the sample boundaries in advance.

In more mature machine vision projects, limit samples will definitely be prepared in advance.

Don't wait until there's a dispute during acceptance testing—instead, define the sample boundaries at the very beginning of the project.

We should try our best to confirm in advance which samples are clearly qualified, which are clearly unqualified, and which are borderline samples that are likely to be controversial.

Especially those samples—those that customers care about most, that are most prone to on-site fluctuations, and that algorithms are most likely to misjudge—deserve even closer scrutiny and thorough discussion.

Because what’s truly challenging about visual projects isn’t always detecting defects—it’s first getting everyone to acknowledge them.

Is this thing actually considered a defect?

The limit sample is not merely a formality—it is the basis for delivery.

Algorithms can be optimized, but they cannot replace humans in setting standards.

That’s precisely where the value of the limit sample lies.

It’s not just about displaying a few samples or going through the motions to keep records—it’s about turning vague verbal requests into universally accepted criteria for judgment.

Without this basis, no matter how powerful the algorithm is, it will easily be questioned later on.

With this basis, engineers know exactly where to adjust the algorithms, customers know what to check during acceptance, and there’s something to refer to in case of disputes on-site.

Therefore, in machine vision projects, the selection of a limited sample is by no means a minor or optional matter.

It often directly determines whether the project will be delivered smoothly or end up in endless disputes.

A lesson learned through blood and tears

Many times, a project gets stuck not because the algorithm is flawed, but because nobody clearly defined from the start what “qualifies as acceptable.”

If you’ve ever worked on a visual project, you should easily understand this situation:

The most exhausting part isn't tuning the parameters—it's that the standards keep changing every time.

What I fear most isn't the difficulty of detecting defects—it's that today they say it's okay, but tomorrow they say it's not.

So, when it comes to machine vision projects, don't just focus on algorithms.