Give AI assistance a bounded task
Give AI assistance a bounded development request: propose a supported image workflow that exposes required visible parts and evaluates the declared relationship. Supply the reference classes, observation limits and permitted variables. Do not ask an assistant to infer hidden fastening quality from an attractive image or to replace unknown evidence with a confident answer. A proposed graph is a hypothesis to test, not a released inspection recipe. Keep the approved camera and lighting baseline unchanged while assessing the processing proposal, so any improvement can be attributed to a declared workflow change rather than a different specimen or a more convenient view.
Freeze the image and coordinate evidence
Freeze source-image identity, original dimensions, crop transform, fixture revision and independently assigned reference class for every development case. Overlay the observation zones on the full original frame, including failed and obscured examples. If an image is resized or cropped, the downstream coordinates must retain their declared relationship to that source. Do not interpret local detections as physical positions without the necessary validated geometry. A result from another frame, an earlier crop or an uncertain source identity is not admissible evidence for the current assembly, even if its part labels and display overlay appear plausible.
Construct an explicit typed chain
Construct a chain with explicit image preparation, foreground extraction, configured-region evidence and a spatial rule when that bounded method matches the task. Configured region labels identify observation zones; they do not establish learned part identity or rejection of every wrong-looking SKU. A separately validated detector may be a candidate when appearance requires recognition, but its model identity, class mapping, filtering and duplicate handling need their own evidence. Raw detector boxes are not automatically unique parts. Confirm supported nodes and installed contracts before connecting the chain, and preserve the typed detection validity rather than reducing every upstream outcome to an anonymous count.
Signed relationship uses a declared coordinate basis
A directional rule depends on label order and image-local centers; it does not measure hidden engagement.
- Original image and crop transform
- First required label centre
- Second required label centre
- Declared signed relation and interval
Define the spatial relation precisely
Define whether the relation is signed horizontal separation, signed vertical separation or Euclidean image-local distance. The reviewed relation route uses centers of the uniquely identified labels and includes the declared interval boundaries. A directional separation is not interchangeable with unsigned distance, and reversing the label order changes its sign. The synthetic code illustrates an inclusive boundary only; it does not set a production tolerance or establish physical calibration. Preserve the exact labels, order, coordinate basis and rule revision in the workbook. A visually left-hand part can still fail the agreed interval, while a permissive interval must not be presented as proof of proper mechanical engagement.
# Synthetic image-local centre example, not calibrated mechanical acceptance.
first_center_x = 4.0 # px
second_center_x = 14.0 # px
signed_separation = second_center_x - first_center_x # 10.0 px
minimum = 10.0 # px
maximum = 12.0 # px
inside_inclusive_interval = minimum <= signed_separation <= maximum
# True at the lower boundary. Native validity and unique-part checks are separate prerequisites.Preserve ambiguous and missing evidence
Keep observation validity ahead of the relation decision. In the reviewed bounded route, invalid visibility and multiple candidates for a required label produce Review; an absent required label with otherwise valid evidence produces Fail. A missing part outside the view is not equivalent to an observed empty valid zone. Preserve native rule reasons and upstream ambiguity so a later step cannot silently convert review into acceptance. Execution errors, malformed results and unknown states need their declared nonpassing disposition. The actual installed contract must be checked, because the presence of a familiar node name does not prove that its current output or model behavior matches this source-level example.
Compare candidates on frozen groups
Compare the baseline and each proposed workflow on the same frozen development groups, including absence, misplacement, duplicate candidates, clipping and allowed fixture variation. Change a declared processing variable at a time and keep the original failed outputs. Inspect which cases improve and which become unobservable or incorrectly assigned; do not optimize a passing screenshot alone. Retain the planned denominator for review and execution failures as well as decisions. Choose a candidate only with its remaining limits recorded, then reserve independent assemblies for acceptance. A parameter search result is not an independent test of the final selected graph.
Record the workflow workbook
Record image and assembly identities, fixture and graph revisions, crop coordinates, evidence method, configured labels or model identity, filtering settings, raw detections, validity, rule interval and final outcome. Add the reference rationale and the observation that explains any mismatch. The table separates an accepted visible relationship from ambiguity, missing parts and execution failure; it does not invent an accuracy percentage. Keep original and candidate graphs with reproducible input material. A receiving engineer should be able to see whether the result came from fixed foreground zones or a validated recognition model, instead of assuming that an AI-assisted development process made every label a learned industrial classifier.
| Evidence condition | Bounded route outcome | Interpretation |
|---|---|---|
| Valid unique required labels within interval | Pass | Declared visible relation only |
| Valid evidence with required label absent | Fail | Observed required-part absence |
| Multiple candidates or invalid visibility | Review | No unique trustworthy relation |
| Malformed or unavailable execution result | Explicit nonpassing handling | Not a fresh valid inspection |
Keep runtime and mechanical claims bounded
Treat this workflow as a bounded visible-assembly development procedure, not a guarantee of hidden joint quality or current production readiness. Historical fixed-station source tests do not prove that the current Windows package, model assets or real camera chain have passed acceptance. Browser-local OpenCV.js execution is not implemented in the reviewed product scope. Cloud or segmentation proposals require their own explicitly supported runtime and validation; they are not implied by the visible relation example. Deyi Vision can assist graph investigation and evidence comparison, but the released station must demonstrate the agreed inputs, outputs, event association and unresolved limits separately.
An AI proposal must become reproducible evidence
Preserve validity and reference groups while comparing an explicit candidate workflow.
- Freeze visible references and source images
- Build supported typed evidence chain
- Evaluate relation with ambiguity intact
- Compare groups and retain release limits
Sources and technical references
These references explain the methods and limits used in this tutorial. Example checks are guidance; production acceptance requires evidence from your own samples.
- Contours: Getting StartedOpenCV
Extracted foreground structure is input evidence and must not be confused with semantic part recognition.
Checked - Deyi Vision Vision WorkbenchDeyi Vision
Supported saved-image workflow development is distinct from validation of installed models, runtime and physical station integration.
Checked
Component and selection references
- machine vision software
- Machine Vision Acceptance Test Checklist
- Automated Visual Inspection
- EAN-13 traceability: decode and data rules
- Stable camera acquisition: buffers, timeouts and reconnection
- Accept and integrate a visible fill-level workflow
- AI-assisted workflow for a visible level proxy
- Link inspection records, images and part identifiers
- OCR labels: acceptance and PLC contract
- OCR labels: native workflow and exact match
- Accept and integrate open-package completeness checks
- Build an AI-assisted open-package completeness workflow
- Build a PLC–vision handshake with explicit states
- Seal and bead appearance: line acceptance
- Seal and bead appearance: workflow rules
- SKU color sorting: acceptance and unknown route
- SKU color sorting: typed color and SKU rules
- Surface defects: acceptance and line output
- Surface defects: bounded AI evaluation
- Load-test latency from trigger to PLC decision
- Version and roll back the complete vision recipe
