In this guide, ECR means engineering change request and records a proposal for assessment; ECO means engineering change order and authorises a defined implementation; ECN means engineering change notice and communicates the release and its effectivity. These meanings are a useful working convention, not universal definitions. A programme should publish its own glossary and authority model, then connect request, decision, release, implementation and re-verification in one auditable thread.
What do ECR, ECO and ECN mean?
The three labels are most useful when they describe distinct control points. The table below is Arc’s recommended operating model; it is guidance rather than a claim that every organisation or standard uses the terms this way.
| Record | Question it answers | Minimum contents | Control outcome |
|---|---|---|---|
| ECR: Engineering Change Request | Should this proposed change be evaluated and approved? | Problem or opportunity, affected baseline and configuration, rationale, initiator, urgency and initial impact | Reject, return for evidence, approve for implementation planning or escalate |
| ECO: Engineering Change Order | What exactly is authorised to change, by whom and for which units? | Approved technical delta, affected records, implementation tasks, authority, effectivity, verification impact and release conditions | Controlled authority to implement the defined change |
| ECN: Engineering Change Notice | What approved change has been released and who must act on it? | Released revisions, effective units or dates, superseded material, implementation instructions and acknowledgement route | Communicated release with a traceable effective point |
Do not infer authority from the record’s name. An “approved request” might authorise analysis but not hardware modification; an “order” might be an internal work instruction rather than a contractual direction. Record the named decision authority and the exact effect of its decision.
Why do engineering-change terms vary between organisations?
Authoritative frameworks use different nouns. NASA’s configuration-management guidance refers to engineering change proposals as inputs to controlled baselines and describes systematic proposal, justification, evaluation, incorporation and implementation verification. ECSS-M-ST-40C Rev.1 distinguishes change requests from change proposals and specifies proposal information including affected items, effectivity, rationale, interfaces, safety, cost and schedule.
Neither source establishes ECR, ECO and ECN as one universal three-document sequence. A supplier, customer or PLM environment may use the same acronym for a different approval point. Before importing historical records, map each local status to the authority it represents instead of matching labels by name.
How does a closed-loop engineering change process work?
A closed loop begins before approval and ends after implementation evidence is reconciled. NASA describes configuration change management as proposal, justification and evaluation followed by incorporation of approved changes and verification of implementation. Its requirements-management guidance also calls for impact assessment across the system before a baseline change is approved. See the relevant sections in NASA Configuration Management and NASA Requirements Management.
- Initiate: state the problem, desired outcome, originator and urgency without presenting the preferred solution as a settled fact.
- Identify scope: name the controlled baseline, product configuration, affected units and intended effectivity.
- Assess impact: inspect requirements, interfaces, architecture, hazards, verification, suppliers, cost and schedule; record missing context rather than treating it as “no impact”.
- Decide: capture the authorised disposition, conditions, rationale, dissent and accountable decision-maker.
- Release: issue the approved technical delta and identify every superseded or newly applicable controlled record.
- Implement: complete the physical, software, procedural and documentation tasks for the stated effectivity.
- Re-verify: perform or disposition affected verification against the applicable requirement and configuration.
- Close: reconcile planned and actual implementation, remaining departures, evidence and configuration status.
Approval is therefore a midpoint, not closure. A change can be correctly approved yet incorrectly released, only partly incorporated or verified against the wrong configuration.
What should the change-impact assessment contain?
NASA’s requirements-management guidance advises assessing a requirement change’s effect on the rest of the system and comparing approval with the consequence of rejection. The change-proposal content in ECSS-M-ST-40C Rev.1 spans performance, interfaces, qualification, safety, materials, testing, ground support, cost and schedule. Those official sources support a broad impact sweep; the exact mandatory fields remain programme-specific.
- Intent and requirements: source obligation, rationale, parent and derived requirements, acceptance criteria and open assumptions.
- Product definition: affected functions, interfaces, architecture elements, drawings, software, procedures and controlled data.
- Applicability: model, variant, serial or lot range, mission, location and introduction point.
- Assurance: hazards, risks, nonconformances, qualification basis, verification activities, evidence and regression scope.
- Delivery: supplier commitments, tooling, inventory, rework, cost, schedule, operations, training and customer approvals.
“No impact identified” should mean the named domains were checked. “Not assessed” should remain visible until a competent owner supplies the missing disposition.
How do deviations, waivers and nonconformances relate to a change?
A nonconformance is the non-fulfilment of a requirement in the ECSS glossary. The ECSS nonconformance-control standard governs control of deliverable products that fail to conform to project requirements. NASA’s configuration-management guidance describes a waiver as documented authorisation not to meet a requirement and states that an authorised waiver does not itself change the baseline.
The terms deviation and waiver are not used consistently across every authority. Treat each as a controlled departure under the governing contract or programme procedure. A departure may be limited to identified units or a period; a permanent design change should follow the approved baseline-change route. As an Arc editorial control, do not hide a nonconformance by silently revising the requirement after the product has failed it.
What does a closed-loop spacecraft change look like?
During avionics integration, the Northstar-1 team proposes replacing a telemetry interface component whose lead time threatens the integration schedule. ECR-042 identifies the current avionics baseline, affected interface requirement IF-TM-018, two flight units and the proposed introduction point. The impact review finds a changed electrical load, a software-driver dependency and three verification activities whose evidence would become stale.
The configuration control board approves the change with conditions: update the interface definition, repeat electrical compatibility testing and retain the original component for the already assembled qualification unit. ECO-042A authorises those tasks and identifies effectivity by unit. After revised product data is released, ECN-042A informs manufacturing, software, test and the customer of the effective configuration.
The change remains open until the two flight units match the released definition, the affected test results are attached to the correct unit configurations and one installation discrepancy is dispositioned. The example shows why approval, notification and verified incorporation are separate facts.
Where does Arc fit without replacing PLM, PDM or QMS?
Arc can hold a connected programme record for a proposed change, its requirement and interface relationships, reviewers, decisions, baseline delta and verification impact. The exact product evidence is documented in Arc’s canonical records for controlled engineering change, traceability and impact analysis, formal reviews and verification and test management.
Arc does not become the drawing, CAD, PDM, PLM, BOM, MES or QMS authority merely because those records are linked to a change. The customer defines which system releases product definition, controls manufacturing records, owns nonconformance disposition and supplies objective evidence. Arc should preserve identifiers, relationships, status and approved references without inventing authority it has not been assigned.
What should you read next?
Use the requirements change-impact analysis guide before approval, record the technical choice with the engineering decision record template, and reconcile released intent with the as-designed, as-built and as-tested guide.
What are the frequently asked questions?
How do ECR, ECO and ECN differ?
In the working convention used here, an ECR records and assesses a proposed change, an ECO authorises its controlled implementation, and an ECN communicates the released change and its effectivity. Organisations use these labels differently, so the programme glossary and configuration-management plan control.
Does approving an ECR mean the hardware can be changed?
Not necessarily. Approval to investigate or accept a proposal is different from authority to update released product data or modify hardware. The programme must identify the implementation authority, affected baseline, effectivity and release instruction explicitly.
Is a waiver the same as an engineering change?
No. NASA describes an authorised waiver as a release from meeting a requirement that does not itself change the baseline. The governing programme may distinguish deviations and waivers differently, so use its approved definitions.
When is an engineering change closed?
Close the change only when authorised updates are released, affected units and records are reconciled, required implementation is confirmed, affected verification is completed or dispositioned, and remaining actions have accountable owners.