In manufacturing, it is not uncommon to encounter the problem of having taken defect photos but being unable to locate similar past cases and their corresponding dispositions. When considering the implementation of AI-based similarity search for defect photos in manufacturing, relying solely on the ranking of image models does not drive action on the shop floor. What is needed is a business process design that, starting from images captured by operators or quality engineers, presents past cases involving the same or similar parts, processes, or defect modes, and safely connects to records of containment, disposition, root cause investigation, and corrective action. This article is written for a Thai factory and organizes the workflow from data preparation through PoC, RFP, FAT, and SAT in practical sequence. The numbers, durations, and thresholds cited in the text serve as examples for drafting procurement specifications and do not represent actual results or generally guaranteed performance values.
Clarification: What Does Similar Defect Photo Search Return?
Fixing a camera on the production line to automatically judge the acceptability of new workpieces—referred to as “inline visual inspection”—is a different operation from using photos of abnormalities found on-site to search for past similar cases, known as “case record search.” The output of the former is often a pass/fail judgment or defect location, which integrates with PLCs and ejection devices. The output of the latter is a list of candidate cases, serving as reference information for quality engineers to verify facts and decide on dispositions for current products. Therefore, even if the top-ranked search result is correct, never apply a past disposition to the current lot without checking its applicability. For a clearer distinction between automatic detection and case search, refer to high-speed inline AI visual inspection.
Additionally, this differs from systems that classify customer complaint texts. Complaint classification uses axes such as the meaning of the text, customer, product, and response history. In contrast, defect photo search strongly depends on imaging conditions and image location, but the image alone cannot determine part number, drawing revision, or disposition appropriateness. To connect these two, it is necessary to manage the flow of text and the linkage of photos, physical samples, and lots under the same case ID, as part of the broader workflow discussed in AI quality management. Shape similarity search of drawings primarily aims to verify drawing revisions and tolerances, and its evaluation data is separated from defect photos of actual product surfaces.
An ideal search interface does not prominently display only image similarity scores. Instead, for each candidate, it lists the defect photo, part number, part name, drawing revision, process, equipment, discovery date, lot, confirmed defect mode, provisional containment, final disposition, cause, recurrence prevention measures, approver, and record links. Cases that are not yet confirmed or whose recurrence prevention effectiveness has not been verified are clearly indicated. If customer cases without access rights are mixed in the search targets, they are excluded from the candidates. The fact that “a similar photo appeared” does not imply “the cause is the same.”
Before Deciding the Scope of Implementation, Record Three Key Questions from the Field
The first question is, “What kind of similarity are we trying to find?” Flow marks on injection-molded parts, scratches on machined surfaces, welding bead defects, foreign substances in paint, and missing components after assembly each differ in color, shape, local region, and background influence. Rather than inputting all photos into a single model and simply ranking them, narrowing down by part series and process, and evaluating according to each intended use makes the implementation decision easier. The initial PoC should start with one process where photographic records and disposition data are relatively complete.
The second question is, “Who will do what based on the search results?” Whether operators confirm defect judgments on the spot by reviewing similarity candidates, quality engineers are consulted, or line leaders initiate isolation changes the required authority and user interface. The recommended initial operation limits the system to presenting candidate cases and their sources; acceptance or rejection of new workpieces, special dispositions, rework, disposal, and customer notifications are confirmed by designated authorized personnel. Log which candidates were opened, whether they were used, the reasons, and the final disposition in an auditable history.
The third question is, “What counts as improvement?” Metrics include not only reduction in search time but also the rate of reaching appropriate past cases, the rate of opening cases for the wrong part, the rate of returning to standard procedures when searches fail, and the completion rate of disposition records. Before starting the PoC, observe current procedures using paper, shared folders, or Excel under the same conditions. Writing “halved” without measuring current time weakens accountability after implementation. It is important not to combine KPIs with different objectives into a single accuracy rate.
The Minimum Unit of a Quality Defect Photo Database Is Not the “Photo” but the Case Record
Many factories already have defect photos, but they are scattered across operators’ phones, inspection equipment, email, customer reports and shared folders. What is required for search purposes is not a mere collection of image files, but case records that link images one-to-one or one-to-many with investigation and disposition. Issue a case ID and associate the original image, cropped images, imaging information, target part, discovery process, date and time, traceability key of the actual item, confirmed judgment status, and version of the disposition document. When importing photos stored only on personal devices, verify ownership and usage scope; customer-provided images must be separated according to contractual usage conditions.
Photos vary greatly depending on shooting position and lighting. The same defect may be conspicuous under raking light but difficult to see under frontal light. Indexing images with prominent backgrounds such as desks or gloves as-is risks the model picking up background similarities. If possible, prepare fixed shooting stands, lighting, distance, and angle. Even in environments requiring free shooting, define a minimal set of images: “overall view,” “defect close-up,” and “image showing scale or part number.” Blur, reflections, overexposure, or missing workpieces should trigger warnings at registration, returning the decision to retake to a human. When correcting image quality later, do not overwrite the original image; separate the processed version and processing history.
Mandatory metadata fields should be determined before image similarity metrics. Candidates include part number, drawing revision, manufacturing line, process, equipment, mold/cavity, manufacturing lot, inspection lot, shooting date and time, product series, defect location, defect mode, inspector, disposition, and approver. However, requiring all fields at once increases operator input burden, so separate automatically acquired manufacturing records from operator input. For example, read part number and lot from barcodes; register defect location and photos on-site; add cause and permanent corrective actions later by quality engineers after investigation. Distinguish the meaning of blank fields as “unknown,” “not applicable,” or “not investigated.”
The official ISO documentation guidance for ISO 9001:2015 illustrates examples such as unique identification of outputs when traceability is required, records of nonconformities and dispositions taken, concessions, and records of authorized personnel who decided the disposition. This does not mandate the introduction of image similarity search. Rather, it should be read as a design rationale linking case record search with quality management documentation. Review the ISO Documentation Guidance against your company’s scope and customer requirements.
Similar Defect Image Search Narrows from “Image Candidates” to “Valid Cases” in Two Stages
One common method for image search is to convert photos into numerical vectors and retrieve candidates with nearby vectors. Microsoft’s Multimodal Search Overview notes that direct embeddings are suitable for visual similarity search, but mathematical representations alone do not explain why images are related. AWS’s OpenSearch Vector Search also lists image similarity search as a use case. These are technical documents demonstrating feasibility, not guarantees of accuracy on specific factory data.
The first stage collects Top-K candidates from the image. The second stage applies constraints such as part family, process, drawing revision, defect location, and inspection conditions. The order varies by business needs. If searching only for the same part, filter first by part number; if seeking similar mechanisms or treatments from different parts, broaden the candidate list while explicitly indicating “different part.” Cases with process or shape changes due to revision differences are not automatically treated as equivalent. When displaying candidates, it is important to separate visual ranking, filter conditions, and case confirmation status, and not express a single score as “treatment confidence.”
Care must be taken in cropping photos. Enlarging only the defect area may better capture texture features but loses context such as workpiece orientation and defect position. Both full images and local images should be retained, and which was used in the search recorded. Similarity values vary with model or index changes, so if displayed on screen, the version and reference standard must be clearly stated. Conditions requiring image vector recalculation, index update delays, and the time until deleted cases disappear from search results should also be confirmed in the RFP.
It is inadvisable to infer causes from images alone. For example, lines resembling surface scratches may originate from mold issues, contact during transport, cleaning marks, or reflections during photography. Search results represent “candidates to verify,” and cause investigation cross-checks actual parts, process conditions, material lots, and equipment history. Even past cases with confirmed causes require separate approval decisions for the current part number and lot. Without this separation, there is a risk of the fallacy “previously a scratch, so treat this the same.”
Connecting Lot, Part Number, and Revision Changes the Candidate Usage
The value of case records lies not only in the photos but also in the ability to trace the scope of impact. After opening candidate cases via search, confirming which processes the relevant lot passed through, which equipment, molds, jigs, and materials were used, and which inspection records and shipment destinations are linked enables discussion of recurrence risks and containment scope. Conversely, past cases with unknown lot numbers should be considered less reliable references even if the images appear similar. Acceptance criteria should include the ability to follow links from the search screen to MES, ERP, QMS, and inspection records. Even in PoCs where integration is not yet complete, saving the case ID and external keys allows for later connection.
Part numbers should separate display names from official codes, and record that application conditions vary by drawing revision, customer specifications, materials, and destination even for the same part number. Rework permitted before a revision is not necessarily allowed after. The revision number and effective start date of dispositions should be retained, and search results should be able to display “Effectiveness against the current standard document is unconfirmed.” Cases from discontinued processes should not be deleted but either excluded from default search targets or displayed with warnings as historical records. This enables returning to past decisions during later audits or root cause investigations.
Access rights require granularity. Operators may view general cases from their own line, quality engineers cross-line cases, and customer-specific drawings or photos only by authorized personnel. In multilingual factories, even if photos are shared, inconsistent translations of classification names, provisional dispositions, and work instructions can cause misuse. Translation for search terms should be distinguished from official work instructions issued on the floor, and critical dispositions should have a path back to approved documentation. Designs must avoid omitting authority or approval controls even when screen displays are in Thai or Vietnamese.
The Correct Answer Set for PoC Is Created Jointly by Search and Quality Personnel
In a PoC, the responsible personnel mix known cases they want to find with similar cases that require different dispositions. If only “reduced-size versions of the same photo” favorable to the image model are considered correct answers, actual operational performance cannot be measured. Prepare variations such as old and new cameras, lighting differences, part revisions, different shots of the same defect, visually similar but causally different examples, rare defects, low image quality, and part mix-ups. Images subject to evaluation should be withheld from indexing and parameter tuning, separated by target period or equipment. Overlapping duplicate photos or consecutive shots of the same case across training and evaluation sets will bias results positively.
The correct answer is not decided solely by one person’s memory. Quality engineers and process personnel distinguish between “useful past cases,” “cases that look similar but whose dispositions should not be referenced,” and “cases pending judgment,” documenting the rationale when opinions differ. As discussed in ASQ’s Explanation on Inspection Judgment Agreement, visual judgments inherently involve inter-operator variability. If unresolved discrepancies exist within the PoC’s “correct answers” themselves, evaluating only the search system cannot explain the reliability of on-site judgments.
Metrics should be divided into at least three layers. Search performance includes the rate at which useful cases appear within the Top-3 or Top-5 results, the rate of not forcing display when no appropriate candidates exist, and the false presentation rate of incorrect parts. Operational performance covers time to open a case, the rate of successfully tracing to disposition records, and escalation time for pending cases. Quality and safety metrics include the number of cases where incorrect past dispositions were reused, approval omissions, and isolation failures. The Top-K value and acceptance thresholds should be agreed upon in advance, considering the company’s candidate volume, risk, and existing procedures. Do not compress performance into a single “AI accuracy” metric.
When measuring, record not only successful searches but also search failures, terminal communication issues, locations where photos cannot be taken, unregistered cases, and broken links to disposition documents. Trials should be conducted using the actual terminals and permissions used by on-site operators, with quality engineers verifying the procedures afterward. NIST’s AI RMF Core emphasizes data fitness and representativeness, role-based and human oversight, and measurement and uncertainty recording before and after deployment. This approach is applied here to the evaluation design of case search. This does not imply that NIST has established numerical thresholds for this specific application.
Requirements to Specify in the RFP: Fix Operations and Data Before Model Name
At the beginning of the RFP, specify the users, input methods, search targets, and excluded scopes. For example, define: “Operators input photos taken on tablets and scanned lot numbers; quality engineers review approved past case records. The system does not automatically finalize pass/fail or disposition.” Next, indicate the current number of case records, photo formats, integration methods between existing QMS and MES, terminal environments, and network constraints. Request vendors to provide separate responses regarding data migration, access control, index creation, maintenance, evaluation, and disaster recovery scope.
Functional requirements should include retention of original images, multiple images per case, selectable cropping during search, filters by part, process, and revision, display of candidate rationale, navigation to disposition documents, approval status display, usage history, correction/deletion, version control, and audit logs. Non-functional requirements should cover display time on shop floor terminals, concurrent users, index update latency, handling during network outages, backup, recovery procedures, and data export formats. Tentative numerical acceptance criteria should be set internally and finalized after PoC results. Simply stating “propose the highest accuracy AI” does not yield comparable quotations.
Confirm data ownership and external services. Ask where photos and drawings will be stored, whether vendors or external model providers will reuse data for training, retention periods, deletion audit trails, access logs, customer data segregation, and subprocessors. If cloud use is prohibited in the process, require closed network or on-premises solutions. Since regulations and customer contracts vary, do not state uniform obligations under specific Thai laws here. This is to be verified by the company’s contract and information management departments.
The RFP should specify not only “vendor-prepared demos of successful cases” but also tests using evaluation images withheld by the purchaser, negative cases with incorrect parts, cases outside the search scope, dispositions from old revisions, and broken links. Require the response documents to include model or service version, conditions for retraining and reindexing, reevaluation methods upon updates, and cost breakdowns. When comparing specific implementations of image embedding, refer to official technical documentation such as Microsoft’s Image and Text Embedding API Description, and individually verify provision conditions and data handling.
Verify “Searchable” as an Operation in FAT and SAT
FAT is considered the stage to confirm whether the vendor’s assembly and configuration meet the requirements before factory installation. Using acceptance images, tests include importing specified formats, matching case IDs with external keys, filtering by part and process, displaying approval status, hiding by permission level, linking search results, and operation logging. Model ranking evaluation is also part of FAT, verifying that results reproduce on the same test set after index updates. Cases of failure or unexpected input include damaged images, duplicate registrations, blanks, unapproved cases, and deleted cases.
SAT tests are conducted on factory terminals, lighting, wireless networks, actual user accounts, and shifts. The workflow observed includes operators taking photos, opening candidate results, consulting quality engineers, and returning to records of approved dispositions and current lot. It is confirmed that existing containment, communication, and recording procedures can be resumed if photos cannot be taken, searches fail, or network disconnections occur. Even if top candidate images are appropriate in SAT, the business objective is not met if disposition links cannot be opened. FAT and SAT should be operated as contractual milestones for testing and approval, and defined according to each company’s standard procedures.
The acceptance record includes test ID, prerequisite part, drawing revision, lot, input photos, expected results, actual results, responsible personnel, evidence, judgment, and corrective action deadline. Not only the passing threshold for search performance but also the handling of critical mispresentations must be decided in advance. For example, defects such as confidential cases from different customers being viewable, unapproved dispositions displayed as approved, or current and old revisions automatically selected as identical can justify rejecting acceptance even if average ranking is high. Stop conditions and responsibility for retesting must be agreed upon contractually.
Procedures for Necessary Updates, Monitoring, and Discontinuation After Operation Start
New defect cases do not become searchable assets simply by registering photos. Define a state transition process including provisional registration, quality verification, addition of cause and corrective action, approval, and index reflection, and specify up to which state candidates are displayed in the list. It is safer to design the system so that unconfirmed cases serve only as investigation references and are not displayed as grounds for standard corrective actions. When corrective actions are revised, retain the old history and update links to the current version. When cases are consolidated or misregistrations corrected, ensure that search logs allow tracing what was displayed at that time.
During regular reviews such as monthly audits, verify zero-result searches, candidates viewed but not adopted, incorrect suggestions, bias by part series, search time, broken links, and authorization errors. Changes in imaging equipment or product design will alter image distribution. When introducing new models or cameras, do not reuse previous evaluation results as-is; add representative images and re-evaluate. When thresholds or models are changed, record version numbers, reasons for changes, retest results, and rollback procedures. NIST’s Explanation on AI Reliability also addresses continuous testing and monitoring after deployment.
An increase in cases does not necessarily improve search accuracy. A large volume of low-quality duplicate images may dominate top candidates. Distinguish between representative and auxiliary images, bundle burst shots of the same case, and have experts correct obvious mislabels. Allow “no matching candidates” results so that operators can switch to normal investigation methods—this is also a quality aspect of operation. At the end of model operation, confirm export or deletion of images, cases, logs, and vector indexes, and ensure consistency with business record retention requirements.
For migration of existing data, it is safer not to reuse original file names as case IDs. Identical image names may exist across departments, sometimes differing only by extension after copying. Before migration, list original storage locations, creation dates, file hash values, linked reports, and registrants; review duplicates as candidates rather than deleting immediately. If reports have been updated, distinguish between the version referenced at photo capture and the currently valid version. Mixing customer-provided images with internally taken photos can cause errors in usage permissions and disclosure scope. Record migration results not only by extracted samples but also by counts, linkability rates, unmatched rates, and authorization mismatches; reflect these in the index only after quality department approval.
Usability of terminals should be verified alongside search accuracy. Test on-site whether operators wearing gloves can take photos, whether defective areas can be specified in highly reflective locations, whether retransmissions in weak wireless environments cause duplicate registrations, and whether permissions of previous users remain after shift changes. If lot information cannot be read immediately after shooting, save the image as a draft and establish procedures for later supplementing tracking keys. However, do not display cases with unconfirmed tracking keys as approved search candidates. Keep terminal operation manuals short with photos, and observe whether operators can confidently perform four exceptional operations: retaking incorrect photos, handling no candidates, fixing broken corrective action links, and emergency isolation.
In effect measurement, averaging only successful searches gives an overly positive view. Use all search sessions as the denominator, and classify cases where candidates were opened but not used, re-searched with different terms, quality engineers were called, or records could not be found. Examine not only median search time but also causes of long-duration cases. From a quality perspective, finding cases quickly by search does not constitute improvement if isolation or approval is omitted. Record the comparison period before and after introduction, target processes, target shifts, and defect composition; do not promote simple time differences as effects when conditions have changed. Align the purpose and retention period of search logs with internal regulations, and define limits to prevent their use as indicators for individual monitoring.
Introduction Sequence and Role Allocation for Starting Small
In the initial phase, the person responsible for the target process selects “cases that may be referenced in searches,” while the quality personnel verify the effectiveness of the disposition records. If the IT staff uploads folders in bulk without this filtering, there is a risk that cases where dispositions were overturned midway or special approvals requiring customer consent appear as standard routine dispositions. For example, existing defect reports are individually assigned states such as detection, isolation, judgment, cause, temporary disposition, permanent countermeasure, and effectiveness confirmation. It is critical not to mix multiple states in a single field, as this clarity supports later explanation of search results. If photos and reports have separate management numbers, the ordering party also verifies the correspondence table linking them. Photos that cannot be matched should not be forcibly published as known cases but placed separately as “unmatched.”
Next, the tasks of registering images and approving content are separated for trial. Field input personnel receive a trial version limited to about three mandatory operations, and quality personnel are provided with a pending approval list. Forcing both parties to input all items on the same screen can halt work and lead to decisions being made via email or verbally. A deadline and responsible person for adding decisions made outside the system later are also established. However, retrospective input should not become routine; the minimum necessary verification before reflecting in search candidates must be clearly defined. Administrators should monitor not only the number of indexed cases but also the duration of pending approvals and fluctuations in unmatched photos.
During the PoC, failure cases are reviewed weekly and causes categorized as “photo quality,” “insufficient cases,” “incorrect classification,” “metadata mismatch,” “disposition link break,” “permissions,” and “operation understanding.” Attempting to fix everything by retraining the model can obscure defects in data registration. If photo orientations vary, change the shooting jig; if case approval status is ambiguous, modify screen displays and operational procedures. To verify which changes affect search ranking, versions of the evaluation set, index, model, and filter settings are saved and compared under identical conditions before and after changes. Images adjusted by the test personnel while viewing correct answers are excluded from subsequent independent evaluation sets.
Easily Overlooked Cases of “Similar but Unusable” in Evaluation
In quality control environments, cases that appear visually similar often carry a higher risk of misuse. Even discoloration of the same color requires different containment scopes depending on whether it is caused by material contamination or detergent residue. Similarly, even the same type of chipping demands different investigation targets if it originates from in-process machining versus damage during transportation. Therefore, evaluation datasets intentionally include negative examples where “the images are similar, but one or more of the part, process, revision, customer specification, or cause differ.” Using merely random unrelated images as negative examples does not adequately simulate the real confusion encountered on the shop floor. When displaying candidate reasons on the search interface, visual similarity and operational applicability should be presented in separate fields.
Additionally, even identical defects may have past dispositions that are no longer applicable. A customer might have previously approved rework, but current specifications may require scrapping. This cannot be determined by image search performance alone. Before referencing past dispositions, a check must confirm the current product specifications and approval routes. If the search results link directly to older documents, these should be clearly labeled as “historical documents,” and any current standard documents should be displayed alongside them. Candidates judged inapplicable by quality engineers should be logged in the search history, and the model’s training data labels should not be changed immediately. This cautious approach is necessary because the reasons for inapplicability often lie outside the image data.
Zero candidate results can also be a valuable output. When no suitable matches are found, forcibly displaying low-similarity cases risks operators assuming “top-ranked means identical,” which may be worse than returning to standard defect handling procedures. However, setting the “no candidate” threshold too strictly can prevent even known cases from being found. Thresholds should be determined by defect type and part family, and the search criteria should remain visible on the results screen. Input images that yield zero results should be accumulated and reviewed to determine whether they represent new unregistered defects, photography errors, or missing metadata in existing cases. Operations such as re-searching or filter removal should also be logged to assess the overall investigation burden, not just the success rate of individual searches.
Retain Responsibility Boundaries After Acceptance in the Contract
The contract and operational procedures must clearly specify the responsible parties for photo registration, case approval, model and index updates, user permissions, data deletion, incident communication, and backup restoration. Even if the vendor maintains the search engine, they are not necessarily responsible for confirming defects or approving dispositions. If the factory side does not register new parts or drawing revisions, updating the model alone will not yield correct candidate results. To ensure continuity of operations despite personnel changes, specific roles should be assigned for daily checks, weekly reviews of unapproved cases, monthly analysis of search failures, and retesting after changes. The decision-maker authorized to suspend the search function and revert to conventional procedures in the event of a critical defect must also be designated.
For cost and contract renewal decisions, metrics such as the number of cases actually used for investigation, the rate of cases reaching disposition documentation, the rate of excluding incorrect candidates, and the registration burden on the shop floor should be used rather than simply the number of searches performed. If low usage is due to the system being “unnecessary on the shop floor,” or because “logging into terminals is difficult” or “the approval status of candidates is not trusted,” the next countermeasures will differ. Improving only the search interface will not increase value if disposition record input is delayed. In post-implementation evaluation meetings, representatives responsible for the model, quality, manufacturing, IT, and information management review the same failure cases together to decide which aspects of data, screens, or operational procedures need correction.
Frequently Asked Questions: Considering AI for Defect Case Search in Manufacturing
Can cause and disposition be determined solely by AI similarity search of defect photos?
No, they cannot. Visual similarity helps narrow down investigation candidates, but causes and allowable dispositions vary depending on materials, equipment, process conditions, part revisions, lot, and customer specifications. Pass/fail decisions, quarantines, special approvals, and rework for new cases are made by authorized personnel based on existing case records. The interface explicitly distinguishes between “similar candidates,” “confirmed causes,” and “approved dispositions.”
How many defect photos are needed to start a quality defect photo database?
There is no universal minimum number. The required volume depends on product variety, defect types, photo variability, and how the search scope is narrowed. Initially, count existing cases and analyze the ratio of photos linked to dispositions, bias by part and process, and the number of cases that can be reserved for evaluation. A proof of concept integrating the search interface with operations can be done with a small dataset, but performance on unobserved defects cannot be guaranteed. If cases are insufficient, prioritize organizing rules and classification schemes before relying on index-based search.
How should costs be compared in an RFP for defect photo search?
Separate initial costs such as migration, data cleansing, terminal setup, integration, and evaluation from ongoing monthly costs like storage, search, model operation, and maintenance. Require estimates under consistent assumptions for case count, image volume, addition rate, search frequency, concurrent users, and reindexing frequency. Even low-cost models incur higher operational costs if links to disposition records are maintained manually. Calculate cost-effectiveness internally by measuring current investigation time, re-investigation frequency, and risk of incorrect dispositions.
What aspects of image search are separately verified in FAT and SAT?
FAT verifies data import, permissions, search and filtering, version control, logs, abnormal inputs, and results of reserved evaluation sets. SAT verifies factory terminals, shooting conditions, network, shift users, and actual escalation and disposition records. Both test conditions and acceptance criteria are agreed upon before contract signing, with evidence and outstanding issues documented.
Summary
AI-based defect photo similarity search in manufacturing is not complete by simply enabling the function to find visually similar past images. It becomes useful for quality operations only when photos are linked to case records including case ID, part number, lot, drawing revision, approved disposition, approval status, and access rights, and when a workflow is established for human verification of candidate results. In the PoC phase, measure on-site search behavior and the risk of false positives. During RFP, FAT, and SAT, verify record-keeping, authorization, and exception handling with equal importance as model ranking.
TOMAS TECH can help Thai factories inventory existing defect photos and quality records, define a manageable search scope, and design acceptance tests. Even at the concept stage, describe the target process and search problem through our contact page.
