Engineering Change Notifications for Deployed Devices: Identify Who Must Decide Before Work Starts
Before work starts on a deployed-device change, identify each affected control and the person or role authorized to decide about it. A firmware team may own the code while another party owns network policy, operating procedures, physical access or integration software. A useful engineering change notice asks for the specific decisions needed to proceed.
This article is drafting guidance only. It sends no notification, changes no device and creates no contractual commitment. The examples are fictional. Actual recipients, authority, communication approvals and commercial terms must be verified through the project’s agreed process.
1. Describe the proposed change and its current status
State the existing baseline, proposed behavior, reason for the change and affected configurations. Label the proposal as under assessment, approved for implementation, verified in a named scope or ready for a separately authorized deployment, as applicable.
Do not describe planned tests as completed evidence. If the affected population is uncertain, identify the inventory gap and the action needed to resolve it. A broadly worded notice cannot compensate for an unknown technical scope.
NASA’s change-control guidance, section 6.5.1.2.3, connects evaluation, approval and implementation verification. The routing method below makes the required decision authority explicit before implementation or field work is assumed.
2. Map impacts to controls and owners
| Potential impact | Controlled item or activity | Decision role to identify |
|---|---|---|
| New communication destination | Site network and endpoint policy | Authorized network/service owner |
| Changed operator workflow | Operating procedure and training | Responsible operations owner |
| Interface behavior change | Downstream consumer integration | Integration authority for affected consumers |
| Physical maintenance step | Site access, equipment and safe work procedure | Authorized site/maintenance owner |
| Changed release claim | Requirement and supported configuration scope | Designated product/change authority |
These are example roles, not assignments to real organizations. One person can own multiple controls, but an available contact is not automatically authorized to approve them.
Document who supplies information, who evaluates impact, who decides and who performs the action. This avoids treating a technical review comment as permission to modify a customer-controlled setting.
3. Distinguish information from a requested decision
A notice can inform a recipient, request confirmation of a fact, ask for an engineering decision or request scheduling of authorized work. State which purpose applies to each section.
“Please review” is insufficient when the project needs a yes/no decision about a prerequisite. Name the decision, options, affected scope, evidence and consequence of leaving it unresolved. Do not invent a response deadline or assume silence means agreement.
Where the decision depends on another party’s approval, show that dependency. The firmware team cannot resolve a network-policy question merely by confirming that its new client code compiles.
4. Attach evidence appropriate to the decision
Provide the change comparison, identified affected versions, relevant test scope, unresolved limitations and proposed operating sequence. Give reviewers access to the controlled evidence they are authorized to see, rather than a link that only the developer can open.
Keep sensitive implementation and site details out of unnecessary distribution. The minimum useful packet should let each recipient decide within their responsibility, without copying credentials, private logs or unrelated customer data.
NASA’s transition guidance, section 5.5.1.2, includes receiving-site and enabling needs. In this method, those needs become named prerequisites rather than last-minute assumptions.
5. Use a fictional endpoint-change proposal
Suppose a noncritical telemetry device is proposed to use service endpoint B instead of endpoint A. The firmware team has not yet completed verification. The change may require site policy review, service readiness and confirmation that the receiving application accepts the intended data.
The draft notice asks the service owner to confirm B’s readiness, the network owner to assess the required permitted route and the integration owner to review the application contract. It identifies planned tests and leaves their results unknown.
It does not tell anyone to disable certificate checks, open unrestricted network access or apply an unreviewed setting. If a required owner cannot be identified, that dependency remains unresolved and the affected work is held under the project’s process.
6. Record decisions at the scope they actually cover
| Response | What to record | What not to infer |
|---|---|---|
| Information received | Receipt of the named notice revision | Technical or deployment approval |
| Fact confirmed | Specific fact and confirming role | Approval of unrelated changes |
| Approved with conditions | Conditions, scope and authorized decision | Permission before conditions are met |
| Rejected or unanswered | Reason or unresolved dependency | Implicit agreement |
Bind approvals to the proposed change revision. If the implementation or affected population changes materially, review whether earlier decisions still apply. Do not attach old approval to new scope because the project title stayed the same.
7. Close the routing loop before execution
Check that required decisions are recorded, conditions have evidence, action owners understand their tasks and the tested release scope matches the proposed work. Record any remaining hold separately from the implementation’s technical readiness.
A final notice should make the next authorized step clear without presenting a draft schedule as a delivery promise. After actual work, use separate execution and verification receipts to record what happened.
The result is a decision-ready communication packet: defined change, affected controls, verified roles, specific questions and traceable responses. It coordinates engineering work without turning an informational email, an informal comment or an untested plan into authority that was never granted.
