ECR, ECO and ECN: tracing one design change to PDM release

Tue, 03 Nov 2026 · 7 min read · Written with an AI assistant, reviewed by our team

A bracket gets thicker, a bolt gets longer, and nobody can say who approved it. How ISO 10007 change control, ASME Y14.35 revisions and a linked SOLIDWORKS PDM workflow keep one design change traceable.

A drawing is released at revision B, and weeks later the shop asks why the bracket in their hand is thicker than the print and the bolts no longer reach. Nobody can say who approved the change, what else it touched, or whether the stock on the shelf is still usable.

That is a change-control failure, not a CAD failure. The model was edited correctly; the decision around it was never recorded. This article walks one design change through the three documents most companies use, the ECR, ECO and ECN, and shows how they line up with ISO 10007, ASME Y14.35 and a typical SOLIDWORKS PDM workflow.

Change control starts at first release

ISO 10007:2017, Quality management — Guidelines for configuration management, describes configuration management as applying technical and administrative direction over the life cycle of a product and service. Its process has five parts: planning, configuration identification, change control, configuration status accounting and configuration audit. The earlier 2003 edition framed this as supporting a product from concept to disposal.

The rule that matters most in daily work appears in a university summary of the 2003 text: once product configuration information is first released, all changes should be controlled. That released set is the configuration baseline. It typically includes requirements, specifications, drawings, parts lists, test specifications and handbooks.

The practical reading is simple. Before release, iterate as much as you like. After release, the current product is the baseline plus every approved change, and nothing else. An edit that skips the process creates a configuration nobody agreed to.

Aerospace and defence teams will recognise the same shape. SAE EIA-649C-2019 defines five CM functions, and its defence companion names them as planning and management, identification, change management, status accounting, and verification and audit. The aerospace companion, EIA649-2A, was rewritten in March 2024 to align with 649C.

ECR, ECO and ECN: one document per decision

None of these standards defines “ECR”, “ECO” or “ECN”. ISO 10007 just says change control. The three documents are industry convention, and companies merge or rename them. What makes them useful is that each records a different decision.

The 2003 text, per the SUPSI summary, splits change control into initiation, evaluation, disposition, and implementation and verification. The mapping is close:

ECR (engineering change request) is initiation. It identifies the need, the reason and the evidence. It does not decide anything.
Evaluation is the review board’s work. It may produce no document of its own, but its findings belong on the ECR or ECO.
ECO (engineering change order) is disposition. It records the approved change, its category, and how it will be implemented and verified.
ECN (engineering change notice) tells everyone affected that the change is real: purchasing, production, quality, service.

The same summary says the documented process should hold a description of the change, the reason, a record of it, a category by complexity, resources and scheduling, an evaluation of consequences, and the plan for implementation and verification. If your ECR and ECO templates cannot carry those fields between them, fix the templates first.

What the review board should actually check

Most boards check that the geometry is right. That is the easy part. The 2003 evaluation list in the SUPSI summary is broader. Turned into questions:

Interchangeability. Will the changed item replace the old one everywhere it is used? If not, does it need new identification rather than a new revision?
Interfaces. Which mating parts, fasteners or assemblies does it touch?
Manufacturing, test and inspection. Do fixtures, gauges, inspection programmes or test specifications change?
Inventory and purchases. What happens to stock, work in progress and open orders?
Contract, schedule and cost. Who pays, and what slips?
Statutory and regulatory requirements. Does any certification or declaration need revisiting?
Delivery and customer support. Spares, service documents, units already in the field.

Technical merit and risk come first on that list, but questions 1 to 4 are where untracked changes usually hurt.

Worked example: one bracket, from request to release

A steel mounting bracket is released at revision B. A revised load case comes in from the system team. The calculation shows the bracket’s margin is too thin at 5 mm, and 6 mm restores it.

ECR. The engineer raises a request: increase thickness from 5 mm to 6 mm. Reason: revised load case. The calculation is attached.

Evaluation. The board works the list. Interfaces: the extra millimetre of grip means the bolt length must change, so the assembly and its BOM are affected. Interchangeability: a revision-C bracket fits where B did, provided the longer bolt is used. Inventory: what to do with revision-B stock on the shelf. Inspection: the thickness check on the inspection plan changes.

ECO. The board approves. The order lists the affected files (bracket part, bracket drawing, assembly, assembly drawing), the bolt change, the disposition of old stock, and verification: recheck the calculation and inspect first articles against revision C.

PDM. A common pattern, described by GoEngineer, keeps the ECO in its own workflow and adds an “ECO Pending Approval” state to the design workflow. Approving the ECO moves the affected files to “Work in Process”; rejecting it returns them to “Released”. It works because the transitions in both workflows share a name. Hawk Ridge describes the same matching “change approved” transition, plus notifications at each step.

ECO workflow:     Submitted -> Under Review -> [change approved] -> Implementing -> Closed
Design workflow:  Released (rev B) -> ECO Pending Approval -> [change approved] -> Work in Process -> Released (rev C)
                                              \-> [rejected] -> Released (rev B)

These are reseller practices, not official Dassault feature descriptions, but the principle holds: the change record and the file state move on the same transition.

Drawing. ASME Y14.35 defines how drawings and associated documents are revised and how revisions are identified and recorded. The 2014 edition’s contents cover revision letters, revision history block entries, revision of digital data, and drawing-level versus sheet-level control. The bracket drawing gets revision C and a history entry referencing the ECO. Note that the ANSI listing shows the 2014 edition as revised by Y14.35-2025, so check which edition your contracts call up. GlobalSpec notes it is used alongside Y14.24, Y14.34, Y14.41 and Y14.100.

ECN. Production, purchasing and quality are told: revision C is released, use the longer bolt, here is what happens to old stock.

Audit. The 2003 text distinguishes functional and physical audits. Functional: does the 6 mm bracket meet the load requirement? Physical: does the part on the bench match revision C?

What this means for CAD and engineering tooling

Status accounting is what makes all this retrievable. The same summary says records should be protected from corruption and unauthorised change, recoverable after a disaster, and able to report current revision status and change history. TriMech notes that PDM tracks the change documents, related communication and affected files together in the vault. When changes involve steps outside engineering, such as supplier approval or service updates, SOLIDWORKS Manage processes can track those steps and move attached PDM documents through their workflows.

My view: any tool that edits CAD should be an implementer of an approved ECO, never a way around one. A macro, design table or AI agent that changes a released part without a linked change record produces exactly the untraceable configuration ISO 10007 warns about. The faster the edit, the more this matters.

That is the design constraint behind Bluecoderhub’s AI-CAD, a prototype under active development. It aims to carry one change from change request through calculation, CAD, change notice and PDM release, with an engineer approving every decision and the model running self-hosted so CAD files stay inside the customer’s environment. It is not released, and the hard part is precisely the process described above.

Closing

Change control is not paperwork stacked on top of design. It is the record of which configuration you actually agreed to build. Get the baseline, the three decisions and the linked PDM states right, and every later step, from drawings to BOMs to release packages, has something solid to point at. Follow the journal for the next pieces, which build on this one.