Temporary Engineering Deviations: State the Units, Conditions and Expiry That Make Approval Bounded
A temporary engineering deviation needs a precise applicability envelope and an explicit end state. Name the requirement, affected units, operating conditions, permitted difference, approving authority, expiry trigger and closure evidence. A ticket marked “accepted” is too ambiguous when another team must decide whether it applies to a different unit or later release.
This is a proposed engineering governance method. It is not legal advice, permission to ship an unsafe product or a substitute for required regulatory or safety review. The fictional example concerns a noncritical display limitation. No deviation has been approved and no device has been tested.
1. Preserve the requirement being departed from
Identify the exact requirement revision and describe the observed or anticipated departure. Keep those two statements separate. Otherwise, a note explaining a failure can quietly become a rewritten specification.
In NASA’s configuration-management discussion, section 6.5.1.2.3, an authorized waiver does not itself change the baseline. NASA also notes variation in deviation/waiver terminology. Apply your project’s definitions rather than assuming every organization uses these words identically.
If the intended change is permanent, route it through the applicable requirement-change process. Repeatedly extending a temporary record should not be an informal way to make permanent behavior disappear from the baseline.
2. Define the affected set without relying on memory
| Dimension | Useful definition | Ambiguous substitute to avoid |
|---|---|---|
| Units | Explicit serial list or controlled selection rule | The pilot batch |
| Hardware | Board revision and relevant populated option | Current hardware |
| Software | Release identifier and relevant configuration | Latest firmware |
| Operation | Named mode, workload and environment limits | Normal use |
| Duration | Date/time zone or a defined lifecycle event | Until fixed |
State how the receiving team checks membership. If a replacement board changes the hardware identity or a unit’s software version cannot be established, the original record should not be assumed applicable. Refer the uncertain case to its decision owner.
Choose identifiers that the authorized receiver can actually obtain. A factory-only database key is not a useful field applicability gate unless the handover includes a reliable way to resolve it.
3. State the permitted difference and what remains required
Describe the limited relief precisely. A deviation for a slow diagnostic page must not imply relief from communication timing, watchdog behavior or measurement accuracy.
List unaffected requirements that could otherwise be confused with the exception. Include the evidence supporting the bounded scope and any uncertainty that remains. A restriction on use is only useful if an operator can recognize and maintain it.
Keep an engineering recommendation separate from authorization. The analysis owner may describe a risk; only the project’s designated authority can decide within its remit. A signature from someone outside that remit cannot cure a missing approval.
4. Make expiry observable and enforceable
Use one or more clear end triggers: a calendar deadline, completion of a named event, consumption of a defined count, installation of a specified release or a change in relevant operating conditions. State whether the earliest trigger ends the exception.
For a calendar deadline, include the time zone and the action required before and after it. For an event trigger, identify the evidence that establishes the event. Avoid a dependency such as “until the fix is ready” when nobody owns the readiness decision.
Expiry of a document does not automatically alter firmware or make equipment safe. The record must assign the practical response: suspend the affected activity, obtain a new authorized disposition or complete the approved corrective action. Select that response through the product’s actual risk process.
5. Separate expiry, suspension and extension
| State change | Reason | Required evidence |
|---|---|---|
| Expires | Defined end trigger occurs | Trigger record and responsible follow-up |
| Suspends | Assumption fails or new adverse evidence appears | Observed condition and affected-unit scope |
| Extends | Authorized party approves a new bounded period | Fresh review, new limit and retained prior decision |
| Closes | Required resolution and verification are complete | Configuration-specific closure evidence |
An extension is a new decision, not a date edit hidden in the old record. Preserve the former expiry and explain why the new evidence supports the additional period. Open-ended renewal defeats the purpose of making the exception temporary.
6. Walk through a fictional display limitation
Suppose a laboratory terminal’s optional diagnostics page takes longer to refresh than its agreed usability target. An engineering proposal covers three named evaluation units, one firmware release and a bench-only mode. It does not cover production operation or any control function.
The proposed exception ends at the earliest of a named review date, a firmware change or use outside the bench mode. The receiving engineer must confirm unit identity and the operating restriction before relying on it. This example does not supply real authority or a safe-use determination.
If a new firmware build is installed, the old proposal cannot simply follow the unit by serial number. Its evidence was configuration-specific. Review the new build, determine whether the original departure still exists and record the resulting decision.
7. Close with evidence, not an optimistic status label
The closure packet should show which affected units received the resolution, which requirement revision was checked, the actual verification result and any remaining exception. If a unit was withdrawn instead of corrected, record that disposition explicitly.
NASA’s status-accounting guidance in section 6.5.1.2.4 includes the lifecycle status of deviations and waivers. The practical benefit is a traceable answer when a maintainer asks whether yesterday’s exception still applies today.
Before handover, give the receiver a few fictional applicability cases: an included unit, an excluded revision and an expired date. Ask for the decision and its controlling field. If the answers depend on contacting the original author, the record is not yet sufficiently bounded.
