Engineering change orders: what AI learns from design changes

What does an engineering change order record?#

An engineering change order records a decision to alter a released design and everything the company did to carry it out. In many companies the chain runs from an engineering change request, through the change order and its review, to an engineering change notice that tells production, purchasing and suppliers what changed. Naming varies, so map your own forms to these stages before an inventory.

The records live in PLM systems such as Arena, PTC Windchill, Siemens Teamcenter or Propel, in PDM vaults such as SOLIDWORKS PDM, and in ERP BOM revision history. Older changes are often scanned forms or PDFs on a shared drive, with the real debate held in email.

• 1Change request with the problem statement and the role that raised it
• 2Reason category: field failure, cost reduction, obsolescence, manufacturability or regulatory
• 3Affected items, BOM levels and where-used lists
• 4Redlines and before and after revisions
• 5Impact assessment covering inventory, tooling, suppliers, cost and documentation
• 6Change board comments, conditions and approvals
• 7Effectivity by date, serial number, lot or use-up of existing stock
• 8Disposition of stock and work in process, plus verification and closure

Which ECO fields teach which AI task?#

The ECO fields that teach the most are the reason for change, the where-used impact and the reviewer comments. Approval timestamps alone say little, while a reviewer's comment explaining why a change needed a second supplier qualification shows reasoning a model cannot get from finished drawings.

The fields that carry the most value are usually the least structured. Reason codes and effectivity dates export easily, while the reviewer's objection, the purchasing note about stock on hand and the quality engineer's condition for release often sit in comment fields or attachments that a basic export leaves behind. Ask IT to include comment and attachment text in any trial export.

Why design changes are hard for AI without real records#

Design changes are hard for AI because the reasoning lives between documents. A finished drawing shows the new wall thickness; the ECO shows that the old one cracked in cold climates, that several assemblies used the part, that purchasing had stock to burn off and that quality wanted a first article before release.

Public sources rarely contain that chain. Patents and catalogs show outcomes, and textbooks describe change control in the abstract. Developers building engineering assistants, and agents that draft impact analyses, check where-used lists or prepare change board packets, need examples of real changes, including ones where a missed assembly caused rework.

For a CTO, the comparison with software helps. An ECO history plays the role a pull request history plays for code: a proposal, a review, a decision and evidence of the result.

Which ECOs are excluded: customer designs and controlled work#

ECOs are licensable only when the company controls the design being changed. A manufacturer of its own catalog products usually does; a contract manufacturer building to customer drawings usually does not, even though its engineers wrote the change paperwork.

Mixed ECOs are the hard case, such as a change to your own product that also touches a customer's private-label variant. Tagging customer-owned and controlled items in PLM before an inventory starts saves a great deal of sorting later.

Export classification deserves its own pass. ITAR defines technical data to include information required to design, produce, repair or modify defense articles, in forms such as drawings, plans, instructions and documentation, so an ECO's text can be controlled even without the drawing. Teams that hold any ITAR or EAR-controlled material should have the classification owner review the ECO list before any change text is prepared.

What makes an ECO history stronger or weaker#

An ECO history is stronger when each change links to the event that triggered it and the evidence that closed it. A change tied to a nonconformance report, a CAPA or a customer complaint shows cause and effect; a change with a one-line description and a note to see the attachment shows little.

Continuity matters too. ECO numbering that restarts after a PLM migration, attachments lost when an old vault was retired, and reason codes added only recently all reduce what can be linked. None of these rule a company out, but each belongs in the inventory as a known limit.

Language quality is a quieter factor. Reviewers who wrote full sentences about why they objected leave a far richer record than boards that approved by signature alone.

Illustrative: a pump maker separates its own designs from private-label work#

Illustrative: a fictional industrial pump manufacturer sells its own catalog line and also builds private-label pumps to a distributor's drawings. Recent ECOs live in a cloud PLM, older ones are scanned forms on a file server, and BOM revisions sit in the ERP.

The CTO wanted to know whether the change history could be licensed without exposing product designs. The inventory tagged every ECO by product family, and the rights review excluded all private-label changes plus a small set of items flagged during an export classification check. The CTO also chose to leave CAD geometry out entirely.

The resulting package covered catalog-line ECOs as structured fields and text: reasons, where-used snapshots, reviewer comments with names replaced by roles, effectivity and links to the nonconformances that triggered them. Supplier drawings were removed, and scanned forms were included only where the text could be read reliably.

How SourceX approaches ECO records#

SourceX handles ECO histories through the SourceX five-step transaction. Supply confirms the systems and record families from metadata only; Rights separates owned designs from customer, supplier and controlled material; Preparation removes names and supplier content; Approval puts the supplier in control of what is released; Delivery hands over only the approved package.

Each package comes with a SourceX Evidence Packet that sets out provenance, licensing rights, permitted use, the privacy record and release authorization. For engineering records, the permitted-use terms and the reasons each excluded item was left out are often what a CTO reviews most closely.