EAN-13 traceability: duplicates and missing reads

Purpose and operating boundary

Identify whether repeated payloads mean repeated captures of one item or legitimate identical products, without losing individual no-read events.

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

Prepare consecutive units carrying the same trade-item code and a saved frame replay. Define the physical item event independently of the barcode payload. Write a failure record that another engineer can replay without guessing which image or revision was used. Include the original source, affected region, actual output, expected disposition and the first divergent intermediate result. Record whether the symptom appears on replay, live capture or both. After a correction, rerun the original failure and the previously successful neighboring conditions. A fix that removes one alarm by excluding its region or accepting a missing result changes the requirement rather than resolving the cause. If the failure remains unresolved, keep the affected operation in Review or inhibited state with its reason; do not label an untested workaround as a validated solution. Keep decoding, identity validation, print verification and unit tracking as separate records. The EAN-13 value identifies a trade item and is normally shared by multiple physical units; it is not a per-frame sequence number or a unique serial. A successful decode does not prove print-quality compliance, correct product master data or successful downstream rejection. This series uses EAN-13 as its bounded example because that is the confirmed public PC evaluation scope. Other symbologies, QR, direct-part marks and reader hardware require their own confirmed integration. The original source image must retain bars, spaces and quiet zones; a cropped display or cleaned binary image alone is insufficient failure evidence. Specify how a missing frame and an unreadable code differ in the traceability database. Troubleshoot from the earliest observable divergence. Replay the same saved source through the unchanged baseline and candidate and compare intermediate images, regions, numeric values and result states. If the source itself differs, the comparison no longer isolates the algorithm. Change a single suspected cause, write the expected effect before running, and retain the negative result when the hypothesis fails. Separate unreadable evidence, a rule mismatch, missing dependencies and an execution fault; they require different remedies. A replay can reproduce a software failure but cannot validate the live trigger, illumination timing or physical reject path. Keep those acquisition and line checks as separate follow-up experiments.

Procedure

1. Compare acquisition IDs and item events before deduplicating repeated strings.
2. Keep no-read, missing frame and invalid payload distinct; inspect the original image for each event.
3. Replay a saved acquisition to test idempotent receipt, then feed separate real acquisitions with identical payloads.
4. Check restart and queue ordering using event identity; never deduplicate all units solely because their EAN-13 text matches.

Interpret the trial

In the hypothetical record, 4 distinct item events with the same EAN-13 require 4 unit records. A repeated delivery of 1 acquisition requires 1 unit record, with receipt history retained. EAN-13 identifies a trade item and is not inherently a unique physical-unit serial.

Recording worksheet

Two engineering views

Failure diagnosis

• Counting payload uniqueness hides legitimate repeated products.
• Replacing a missing frame with the preceding successful read creates traceability that the evidence never established.

Acceptance and handover

Accept event accounting when each expected item has one terminal record and replay cannot create an extra item. Reconcile expected triggers, received images, no-reads and terminal records without removing failed events.

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.