EAN-13 traceability: decode and data rules

Purpose and operating boundary

Separate symbol decoding, check-digit validation and product-master association so that a readable code cannot silently identify the wrong trade item.

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

Freeze supported symbology, expected product-source revision and no-read policy. Keep the expected identifier outside decoder input and identify any model dependency separately. 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. 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. 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. Decode the original ROI and retain raw payload, symbology and source ID before validation.
2. Check declared length and check digit without repairing a mismatched digit from the expected answer.
3. Look up the approved product mapping and distinguish unknown identifier from a known product mismatch.
4. Return a structured result for read, no-read, invalid data, mismatch and execution error; test these before any PLC output.

Interpret the trial

For hypothetical first digits 123456789012, alternating sums are 26 and 22. The weighted sum is 26 + 3 × 22 = 92 and the check digit is 8, giving 1234567890128. This is an arithmetic fixture, not an allocated customer GTIN. A correct check digit does not prove the identifier belongs to the expected product.

Recording worksheet

W = 26 + 3 * 22 = 92
c = (10 - (92 % 10)) % 10 = 8

Two engineering views

Failure diagnosis

• A checksum repair can convert a real wrong label into a false match.
• A decoder response with no declared symbology or source identity is incomplete evidence, even when its text looks plausible.

Acceptance and handover

Accept each rule on independent images and approved reference records. Keep decode success, checksum validity and product association as distinct acceptance fields; none alone establishes GS1 print verification.

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.