Seal and bead appearance: workflow rules

Purpose and operating boundary

Bind visible path coverage, gap evidence and Review states to source images; an AI proposal cannot turn appearance into leak or strength certification.

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 the reference path, inspected projection, foreground polarity and executable backend. Keep good, visible-gap and hidden-path controls independent of predicted answers. Define the visible acceptance feature before building a seal or bead mask. A tamper-seal edge, a heat-seal band and an adhesive bead have different physical meanings and must not share an undeclared appearance rule. Record the reference path, permitted projection, substrate and state of the material at capture. Wet adhesive, cured material and a reflective backing can produce different boundaries without an equivalent change in joint integrity. Include a deliberately visible gap, an offset path, a plausible reflection and an obscured section as separate controls. The assigned image rule evaluates observable surface appearance only. It cannot establish airtightness, leak rate, peel strength, bond strength, cure or a hidden interface. Those claims need their own process-specific evidence. If the required interface is hidden, return insufficient evidence or choose another validated observation method; do not complete the path from an expected drawing. 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. 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. The coverage worksheet here is a proposed vendor-neutral evaluation that needs a separately implemented and verified evaluator. It is not the native classic_glue output contract. That engineering operator evaluates a declared horizontal observation band and reports the longest run of columns with zero foreground width through number/rules. It does not supply the reference-path coverage field or general path geometry proposed here. Verify the installed implementation before using either method; neither supplies leak or strength certification.

Procedure

1. Locate the substrate datum, map the declared path into source coordinates and retain the transform.
2. For the proposed vendor-neutral coverage study, create a visible mask with recorded preprocessing; count covered reference-path pixels and retain every missing segment separately.
3. Compare one candidate on the same development originals, checking whether it removes real gaps or admits reflections.
4. With a separately verified evaluator, record coverage, geometry, validity and reason; do not present these as the current native classic_glue fields. Unavailable runtime or hidden evidence must not borrow a prior passing result.

Interpret the trial

The hypothetical coverage study covers 970 of 1000 reference-path pixels, giving 97%. With a trial criterion of 99%, that proposed rule fails. The total missing path is 30 px; at an assumed local scale of 0.05 mm/px its total projected missing length is 1.5 mm. This total does not identify the longest contiguous gap: measure the ordered missing segments separately. These values neither prescribe a customer limit nor establish functional seal performance or native operator outputs.

Recording worksheet

# Proposed vendor-neutral worksheet; not a native operator output contract.
coverage = 970 / 1000 = 97%
97% < 99% -> Fail
total_missing = 1000 - 970 = 30 px
total_projected_missing_length = 30 * 0.05 = 1.5 mm
# Measure ordered missing segments separately to find the longest contiguous gap.

Two engineering views

Failure diagnosis

• Morphological closing can fill a real gap in the mask without adding adhesive to the part.
• A model score does not supply hidden interface evidence or approve the executable package.

Acceptance and handover

Accept the rule only on independent visible and unobservable controls with fixed references. Keep mask coverage, physical appearance and functional joint testing separate; any cloud-based extension needs explicit data, provider, model and cost approval.

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.