OCR labels: native workflow and exact match

Purpose and operating boundary

Separate text detection, recognition and business-field validation, and preserve uncertain text instead of replacing it with the expected lot.

This tutorial defines an engineering evaluation, not a ready-to-run product certification. The current Deyi Vision public PC example covers an EAN-13 workflow on confirmed sample images. Native OCR and detection work in the engineering code must be checked against the installed runtime, bound models and job before use. A browser template does not prove browser execution: the planned OpenCV.js backend needs separate verification. Cloud recognition requires explicit approval of the image scope, provider, model and cost. A review archive is not an executable release package. Camera, firmware and driver compatibility require their own check. All worksheet values below are hypothetical; they are not Deyi Vision measurements or customer results.

Prepare the evidence

Bind the confirmed OCR package, language dictionary and preprocessing revision. Inspect installed capabilities rather than treating an editable OCR template as executable. Check the intermediate output against its contract before interpreting the final flag. A missing region, malformed text field, invalid coordinate or non-finite numeric value must remain an explicit failure, not a default good result. Record the actual execution backend and dependencies used for that run; do not transfer acceptance from another backend with the same template name. If a new model or preprocessing revision is selected, preserve the previous version and rerun the fixed comparison rather than combining results across identities. Present the complete number of attempted cases, how many returned usable evidence and the decision made for the remainder. These quantities describe coverage and failure handling as well as recognition quality. OCR label verification is a data-integrity task rather than a search for plausible words. Define each field, its location, expected alphabet, exact comparison policy and the trusted source of the expected value. A lot field, date field and product name may need different rules. Keep the text detection polygon and recognizer output before normalizing spaces or case. Do not silently replace I with 1 or O with 0: that can make a wrong label appear correct. The original engineering evidence includes a narrow OCR boundary case that returns NoResult or Review; increasing a crop does not establish general recognition readiness. A readable field can still contain the wrong lot, while a correct expected value does not justify filling an unreadable field with that value. Treat a workflow as a sequence of typed decisions, not as a single model answer. Bind the input identity, region transform, node versions, preprocessing and model package before running an experiment. Separate parameter selection on development images from evaluation on a frozen set whose answers were not used for tuning. Keep the baseline and candidate results for every case, including unsuccessful execution. An AI suggestion can propose a revision but cannot confirm the reference answer, grant data upload permission or approve production use. If a provider call has an uncertain receipt, preserve the request identity and investigate that receipt before considering any resend. Runtime availability, recognition quality and release approval are independent checks.

Procedure

1. Feed only the source-linked field into detection and retain the returned polygon before recognition.
2. Preserve raw recognized text, then apply only the written normalization policy; record both versions and the rule.
3. Compare against the trusted lot field exactly and distinguish a readable mismatch from NoResult or Review.
4. Select model or threshold changes on development data, then rerun the frozen comparison including confusing characters.

Interpret the trial

LOT123 is the hypothetical expected field. LOTI23 is a readable mismatch even though both have 6 characters. A model confidence value is not permission to replace I with 1. Missing detector/recognizer dependencies block execution; the public PC example alone does not prove this native OCR chain is ready.

Recording worksheet

Two engineering views

Failure diagnosis

• A correct text value associated with the wrong field polygon must fail binding review.
• A provider answer without the required source/request identity must not become an accepted local OCR receipt.

Acceptance and handover

Accept only the bound runtime that was actually evaluated. Save polygons, raw text, normalized text, expected-value source, revision and the disposition of each failed field.

Keep the source images, the expected decision, the exact revision and the complete result record together. Freeze the evaluation set before selecting the final parameters. If those answers are later used to tune the workflow, mark that set as development data and obtain a new independent acceptance set. Keep Review, NoResult, execution error and missing acquisition visible in the denominator; do not turn them into passes by filtering rows. Save a reproducible failure alongside the successful sample. The handover should identify who may change the recipe, how a prior approved revision is restored and which device output remains inhibited until acceptance. A software result alone does not establish that a moving physical part reached the correct destination.