Deviation and Waiver Request: How Hardware Teams Disposition Them

Contents
- Step 1: Classify the request as a deviation or a waiver (and check which definitions your contract uses)
- Step 2: Pin down the exact requirement or drawing characteristic being departed from
- Step 3: Pull the design rationale and CAD change history behind that requirement
- Step 4: Assess what the departure affects and what verification evidence supports accepting it
- Step 5: Record the disposition, its scope and conditions, then link it back to the requirement
- Step 6: Decide whether the departure should become a permanent change (ECO) instead
- What Tandem does not do
- Troubleshooting: common ways deviation and waiver dispositions break down
- Conclusion
Hardware review boards reject departures for a simple reason: the paperwork shows what went wrong, but nobody can find the original engineering intent. A machine shop cuts a batch of bracket bolt holes 0.015 inches off center, or a supplier ships titanium fasteners with an uncertified surface finish. The assembly line stalls while engineering digs through old CAD models, buried calculation spreadsheets, and disconnected chat threads to figure out if the part will still survive qualification.
Dispositioning a deviation and waiver request means knowing the difference between what you planned to build and what you actually built. You need the exact drawing characteristic, the baseline requirement it satisfies, and the verification evidence proving the departure won't cause a field failure. This guide steps through how mechanical, systems, manufacturing, and quality engineers evaluate departures systematically, isolate risk, and record defensible decisions.
Step 1: Classify the request as a deviation or a waiver (and check which definitions your contract uses)
Don't process a nonconformance until you know whether the part has been manufactured. A deviation authorizes a temporary departure from specified requirements before an item is manufactured. A waiver authorizes acceptance of an item that is already manufactured and doesn't conform to specified drawing or performance requirements.
Timing dictates the risk profile. In a deviation request, you evaluate planned actions. A supplier might ask to use alternate bar stock for an upcoming machining run because the specified alloy has a twenty-week lead time. In a waiver request, the hardware already exists, the error is baked into the metal, and you decide whether to scrap the lot, rework it, or accept it as-is.
Public standards vary in their terminology, so review your contract definitions before writing up a disposition. Military standard MIL-STD-973 historically defined a deviation as written authorization prior to manufacture, and a waiver as written authorization after nonconformance occurred. The NASA Systems Engineering Handbook appendix takes a different route. It outlines departures under its own configuration and baseline management guidelines. If you apply defense definitions on an aerospace program that defines waivers as life-cycle baseline variances, your disposition will fail configuration audits. Pin down your contract vocabulary first.
Step 2: Pin down the exact requirement or drawing characteristic being departed from
Generalities ruin departure reviews. If a request says a housing "does not meet drawing tolerances," send it back immediately. A valid deviation and waiver request cites the exact drawing number, sheet, zone, characteristic identifier, or system requirement tag.
Isolate the exact parameter. State the nominal drawing specification, the tolerance band, and the measured value across every unit in the lot. For example, if drawing DWG-4022 Sheet 2 Zone C4 calls out an O-ring groove depth of 0.045 plus or minus 0.002 inches, and five units measure 0.049 inches, the departure is 0.002 inches above the high tolerance limit.
Map that drawing characteristic directly to its parent system requirement. A geometric dimension doesn't exist in isolation. That O-ring groove exists to satisfy a system-level fluid sealing requirement of 150 psi across operating temperatures. When a hardware review board evaluates a change control board hardware engineering package, members need to see both the physical drawing dimension and the functional requirement line item. Without that link, engineers evaluate geometry blind, with no idea what downstream function they're degrading.
Step 3: Pull the design rationale and CAD change history behind that requirement
Before approving a departure, find out why the designer chose that tolerance in the first place. Tolerances exist for one of two reasons: functional performance or manufacturing habit. You can't tell which one applies by looking at a PDF print.
Inspect the CAD history and engineering notes. Check the 3D model feature tree, revision descriptions, and associated trade studies. Reviewing CAD revision history best practices shows whether a tight tolerance was applied to prevent interference at maximum material condition, or whether an engineer slapped a default title-block tolerance on an uncritical clearance hole.
When this context lives in scattered personal drives or unrecorded conversations, review boards freeze. Tandem closes that gap by connecting design intent, requirements, and CAD changes directly to the engineering record. When an engineer reviews a deviation and waiver request in Tandem, they see the design rationale and linked SolidWorks, Onshape, Fusion, or NX changes right next to the requirement. You can see whether the original stress analyst specified a wall thickness to satisfy burst pressure margins or simply mirrored an adjacent casting feature. That distinction decides whether you accept the departure or reject it outright.
Step 4: Assess what the departure affects and what verification evidence supports accepting it
Every disposition requires objective evidence. Never accept a deviation or waiver on an engineer's verbal assurance that a part looks fine.
Categorize the departure into one of four standard verification methods test analysis inspection demonstration approaches. If a structural flange is undersized, run finite element analysis on the as-built geometry to calculate revised margins of safety. If an electrical harness uses non-standard shielding, run an electromagnetic compatibility bench test. For assembly clearances, perform a physical fit demonstration on a master fixture.
Trace the departure across life-cycle phases as outlined in NASA program life cycle guidelines. Assess five core operational impacts:
Structural margins and thermal limits.
Interface fit with mating subsystems.
Service life and fatigue limits.
Interchangeability of replacement spare parts.
System reliability and operator safety.
If the departure drops the safety factor below the contractual threshold, you can't approve it. Reject the request or elevate it to customer authorities for a formal system specification amendment.
Step 5: Record the disposition, its scope and conditions, then link it back to the requirement
A disposition is not a blanket authorization. It is a strictly bounded decision. Every approved deviation or waiver must define three boundaries: quantity, serial number, and time period.
Write dispositions with explicit conditional language. State whether the disposition is Accept As-Is, Rework to Specification, Repair per Approved Procedure, or Scrap. If you approve an accept-as-is disposition for twelve battery enclosures with anodization voids, specify the exact serial numbers from SN-0101 to SN-0112. Don't write "valid for current production run." State that any units machined after a fixed date or beyond that serial block remain governed by the baseline drawing.
Link the signed disposition directly to the requirement and part record. When quality engineers inspect downstream assemblies or auditors review configuration baselines years later, they must be able to trace from the physical serial number straight to the waiver rationale. In Tandem, validation evidence and requirement status stay connected in one workspace, so quality records reflect approved departures without losing the baseline requirement definition.
Step 6: Decide whether the departure should become a permanent change (ECO) instead
Repeated departures are an engineering warning sign. If a machine shop submits a third deviation request for the same internal radius, the problem isn't manufacturing competence. The drawing is wrong.
Track departure frequency by characteristic and supplier. When a deviation request points to a drawing requirement that can be relaxed across all future builds without compromising function, move from temporary relief to a permanent Engineering Change Order (ECO). A deviation is an exception. An ECO is a permanent baseline change.
Evaluate the broader system impact before converting a departure to an ECO. Changing a drawing tolerance permanently affects tooling, inspection fixtures, supply chain contracts, and downstream assembly procedures. If the change only affects an isolated batch of material during a supply crunch, keep it as a closed waiver. If the change resolves a chronic design for manufacturability bottleneck that lowers unit production costs, route an ECO through your engineering change board right away.
What Tandem does not do
Tandem has clear boundary lines. It connects design intent, requirements, CAD changes, and validation evidence, but it does not replace core execution tools.
Tandem is not a CAD tool and not a PLM or PDM replacement.
Tandem also does not conduct automated vendor part searches, run engineering calculations, generate CAD geometry, or execute physical test protocols. It stores and connects validation evidence rather than running test benches. Its job is preserving and linking engineering reasoning across the development cycle.
Troubleshooting: common ways deviation and waiver dispositions break down
Departure dispositions usually fail because of procedural erosion. Watch for these breakdown points across your engineering reviews:
The recurring waiver trap. A supplier requests a waiver for an out-of-round tube on unit one, then unit two, then unit ten. The team treats each request as an isolated event instead of recognizing a broken tooling process. Cap waivers: three consecutive identical waivers trigger an automatic hold and a mandatory ECO review.
Vague conditional approvals. Writing "approved subject to fit check" without defining who performs the check, what tool is used, or where the check is signed off creates unverified hardware. Every condition must name an owner, a test standard, and a sign-off requirement.
Lost interface tracking. Approving a mounting hole pattern shift on a mechanical bracket without telling the team building the mating structural frame creates major integration delays. When the components arrive at integration, the bolt holes don't line up. Always require interface control reviews for any geometric departure.
Informal departures. Hardware gets modified on the shop floor through an oral agreement between a manufacturing technician and a design engineer. If it isn't documented in a formal deviation and waiver request, the departure doesn't exist, and the unit will fail its first formal quality audit.
Conclusion
Hardware departures reveal how well an engineering team understands its own designs. When a deviation and waiver request lands on the review board table, success doesn't come from rushing signatures to keep assembly technicians busy. It comes from instant, verifiable access to the original design intent, the underlying requirements, and the physical verification evidence.
Tandem gives engineering teams a connected context layer that ties SolidWorks, Onshape, Fusion, and NX CAD changes directly to requirements and validation proof. Book a demo with Tandem to stop digging through old files and make every hardware disposition fast, traceable, and audit-ready.
Visit Tandem
Tandem is the AI platform for hardware engineering — it connects requirements, CAD design changes, reviews, and engineering decisions in one system so design intent doesn't get lost. It sits inside real workflows (SolidWorks, Onshape, NX, plus PDM, Jira, Slack, Drive), captures CAD activity as Design Sessions that group related edits and explain what changed and why, and links those changes to a live Requirements Workspace and in-context Reviews. Built for hardware teams (Series A-C, 50-500 employees) moving from prototype to production.
Get startedSources
Frequently asked questions
What is the difference between a deviation request and a waiver request?
A deviation request is submitted and evaluated before manufacturing begins, authorizing a temporary planned departure from specifications. A waiver request is submitted after parts have already been produced, asking to accept existing nonconforming hardware as-is or under specific repair conditions.
Can an engineering team approve a waiver that impacts customer interfaces?
No internal engineering board can unilaterally approve a departure that alters external interface control documents or contractual performance specifications without formal customer concession. Any departure affecting form, fit, function, or safety requires customer approval.
How long should an approved deviation or waiver request remain valid?
A departure authorization should strictly cover a defined lot size, serial number range, or calendar duration. Permanent departures must not sit on recurring waivers; they should be converted into an Engineering Change Order (ECO) to update the baseline configuration.
How does Tandem help engineers disposition a deviation and waiver request?
Tandem connects system requirements, CAD changes, and validation evidence in one place. When reviewing a departure, engineers can immediately check the design rationale behind a tolerance, review linked CAD models, and verify whether proposed departures compromise functional margins.
Related reading
Written by
Tandem
Tandem is the AI platform for hardware engineering — it connects requirements, CAD design changes, reviews, and engineering decisions in one system so design intent doesn't get lost. It sits inside real workflows (SolidWorks, Onshape, NX, plus PDM, Jira, Slack, Drive), captures CAD activity as Design Sessions that group related edits and explain what changed and why, and links those changes to a live Requirements Workspace and in-context Reviews. Built for hardware teams (Series A-C, 50-500 employees) moving from prototype to production.