A drawing can be new while the problem inside it is familiar. A plate is too thin for its intended use. A hole sits too close to an edge. A material designation differs from the one the team agreed to use. Someone may remember a similar failure, but that knowledge must reach the person reviewing the next drawing.
Scuti AI explored this connection through a small drawing review application: compare an engineering drawing with explicit checks and past defect records, then show the reviewer where to look and why. The aim is to bring relevant experience into the review process with evidence that an engineer can inspect.
Our previous manufacturing vision video illustrated information becoming connected knowledge. This experiment gives that idea a concrete workflow. All drawings, conditions, and defect histories used here are synthetic; no customer drawings or actual factory records were used.
Bringing Past Defects into the Next Review
Manufacturing teams can hold valuable lessons across corrective action reports, inspection records, meeting notes, and experienced staff. Finding a record is only part of the task. A reviewer also needs to understand whether its conditions apply to the current part and which drawing details require attention.
For this experiment, we made that relationship explicit. Each check has an instruction and, where relevant, a link to a synthetic defect history. A thickness check points to a record about plate deflection. A material check points to a record about ordering the wrong material. A general tolerance check stands on its own without an associated defect record.
This structure separates the lesson from the case that motivated it. The history explains why a team might care; the check states what to examine now. In a real project, engineers would need to approve those conditions and their scope before using them in reviews.
A record saying that a part cracked is not enough to define a reusable check. The team needs to identify the relevant dimension, the circumstances of the failure, and the agreed preventive action. Organizing that knowledge is part of the engineering work behind this approach, and gives a new reviewer something more useful than a search result alone.
The Application and Demonstration
The application places a simple mounting plate drawing beside five review items. A user selects a sample or opens a supported PDF, chooses a review method, and starts the comparison. The interface is Japanese, while the sample drawing annotations are in English.
The results begin as a compact list. Opening an item reveals its explanation, drawing evidence, related history, and a field for human review. Clicking an evidence quotation highlights the corresponding text location on the drawing. This lets the reviewer move from a result to the source without searching the whole page again.
Three statuses guide that review: flag means a readable detail conflicts with the stated condition; pass means the available evidence satisfies that particular check; and unknown means the information is insufficient. A pass applies to one check. It does not establish that the part is ready for manufacture.
The intended handover is specific: read the finding, inspect the highlighted annotation, consult the related record, and decide whether to confirm it, reject it as a false positive, or hold it for clarification. An unknown result can be useful when it identifies a question that must be answered before the review can proceed.
Three Conflicts Found in the Sample Drawing
The deliberately defective sample contains three readable conflicts. Both the fixed checker and the actual Codex review identified them. The numbers below belong to this synthetic mounting plate experiment and are not general engineering design limits.
Plate Thickness: 2 mm Against a 4 mm Condition
The drawing states “THICKNESS: 2 mm,” while check R001 requires at least 4 mm. The associated history, H001, describes a fictional plate deflecting and allowing its fixing position to shift. The result connects the dimension, the comparison, and the reason for checking it. An engineer can then assess whether that condition is appropriate for the actual application.
Hole Center to Edge: 5 mm Against a Calculated 9 mm
R002 compares the hole center’s distance from the nearest plate edge with 1.5 times the hole diameter. The sample specifies a 6 mm diameter and a 5 mm center-to-edge distance. Under the experiment’s condition, the required distance is 6 × 1.5 = 9 mm, so the item is flagged.
The drawing explicitly defines the measurement as center to edge. This matters because measuring from the hole’s circumference would describe a different distance. The linked history, H002, concerns fictional cracking near an edge.
Material: SS400 Against a SUS304 Specification
The material annotation reads “MATERIAL: SS400,” while R004 specifies SUS304. The comparison flags that difference and links to H004, a synthetic record of material confusion leading to reordering. The useful output is the visible disagreement between the drawing and the supplied requirement, which the reviewer can resolve with the responsible team.
The remaining checks show why review needs more than a warning list. The deburring instruction could not be confirmed, so R003 returned unknown. The general tolerance annotation, “GENERAL TOLERANCE: +/-0.2 mm,” satisfied R005’s requirement that a tolerance value or applicable standard be stated.
Checking Normal and Incomplete Drawings
A demonstration containing only planted problems would leave two questions unanswered: does the application flag acceptable information, and does it treat missing information as acceptable? We therefore included normal and incomplete samples alongside the defective drawing.
| Synthetic sample | Pass | Flag | Unknown |
|---|---|---|---|
| Normal | 5 | 0 | 0 |
| Defective | 1 | 3 | 1 |
| Incomplete | 3 | 0 | 2 |
The normal sample passed all five checks. In the incomplete sample, material and general tolerance were unknown, while the other three items passed. Missing information therefore remained visible as work for the reviewer.
Across three drawings and five checks, both methods matched all 15 expected statuses defined separately for the experiment. Those expected answers were not supplied to Codex. This is a small functional validation, not a measurement of accuracy on real drawings. The fixed checker achieved the same results, so these samples also do not demonstrate an advantage from AI.
How the Experiment Works
The local application uses a Python and FastAPI backend with a plain HTML, CSS, and JavaScript interface. PyMuPDF extracts embedded PDF text and the coordinates of its text lines, and renders each page as a PNG. The coordinates connect quoted evidence with the highlights displayed in the viewer.
The fixed method reads a small set of explicit labels, such as thickness and hole diameter, and applies deterministic comparisons. For these clearly labeled samples, that is a straightforward baseline. It also makes the rules and calculations easy to inspect.
Its limits are equally specific. A different label, a more complex tolerance expression, or a drawing containing several parts can require a different extraction approach. The existing fixed checker is tailored to the sample’s vocabulary; it is not a general drawing interpretation system.
The Codex method sends the rendered drawing images, extracted text, and the entire small checklist and history collection to Codex CLI in each request. It asks for one structured JSON result per check, including the status, reason, exact quotations, and relevant history IDs. There is no model training or vector database retrieval pipeline in this implementation.
The application validates the response structure and checks whether quotations occur in the extracted text and whether history IDs are permitted for the relevant rule. Unverifiable evidence or references cause the result to become unknown. These checks establish traceable references; they do not prove that the model’s interpretation or arithmetic is correct.
The app runs locally, but selecting Codex and pressing the review button sends the supplied drawing data and knowledge to OpenAI. A separate Ollama text-only option is present, but its review results were not evaluated in this experiment. The current PDF workflow requires selectable text and has no dedicated OCR stage, so image-only scanned drawings are unsupported.
Where This Could Support Manufacturing Teams
For design teams, a possible starting point is a narrow checklist for one recurring part family. An approved corrective action could become a review question with a clear condition and a link to the original record. The engineer would see both the current drawing detail and the earlier lesson before deciding what action to take.
Production engineering could use the same structure to discuss concerns before process planning or supplier handover. A missing finishing instruction, for example, could become a visible request for clarification. The team would still determine whether the instruction belongs on the drawing, in a process document, or elsewhere in the agreed workflow.
Quality teams could help maintain the connection between defect records and review conditions. A useful rule needs an owner, an applicable scope, and a way to change when the process or specification changes. Simply adding more historical documents would not establish which lessons should apply to a new design.
For manufacturing DX teams, the experiment suggests a manageable pilot: one document type, a small approved checklist, and reviewers who can explain the expected decisions. The application includes human review fields and JSON export, providing a basis for recording confirmed findings, false positives, and items held for further investigation. Any reduction in review effort or recurring defects would need to be measured in that pilot.
The Next Step: Validation with Real Work
The next evaluation should use permitted real drawings and carefully selected defect records, with expected outcomes agreed by qualified reviewers. It should include different layouts and wording, missing or conflicting annotations, and cases where a historical lesson does not apply. Measuring false alarms and missed issues would be as important as counting correct findings.
Keeping some drawings separate from checklist development would help test whether the approach carries over to unfamiliar cases. Reviewers should also record disagreements about the expected answer, because an ambiguous requirement needs resolution before it can become a dependable automated check.
The comparison with fixed rules should continue. Deterministic checks may remain the clearest choice for explicit numerical conditions. AI’s potential value lies in handling more varied expressions and helping connect evidence with review instructions, but that remains an open question for a broader evaluation. Review time, corrections to AI explanations, and the usefulness of evidence links would help answer it.
Scuti AI would also work with the team to define document handling requirements, responsibility for checklist updates, and the human approval step. The goal is a review process in which manufacturing knowledge reaches the right drawing and the engineer can verify the recommendation.
Does your team have recurring drawing issues or defect records that are difficult to reuse? Contact Scuti AI to discuss a focused pilot: select one drawing category, identify a small set of approved lessons, and define how to evaluate their usefulness in the next review.