What Should a Systems Engineer Do When a Supplier’s Delivered Component Does Not Meet an Interface Requirement?

A supplier delivers hardware. Your incoming inspection or integration test finds it does not conform to one or more interface requirements. What happens next is one of the most consequential process sequences in systems engineering — and one of the most commonly mishandled.

Getting it wrong has predictable failure modes: undisclosed nonconformances propagating into system-level tests, verification records that claim compliance against a requirement the hardware never actually met, or waivers signed without understanding what verification events they invalidate downstream. None of these outcomes are hypothetical. They appear in accident investigation reports and program audit findings with regularity.

This walkthrough covers the full sequence: how to assess impact using interface requirements, how to initiate the correct formal process (deviation vs. waiver), how to update your model and baseline, and how to trace the consequences through to downstream verification.

Step 1: Understand What You Actually Have — Deviation vs. Waiver

Before anything else, get the classification right. These two terms have specific, non-interchangeable meanings in aerospace and defense programs under standards like MIL-STD-973, AS9100, and FAR/DFARS clauses.

Deviation: A departure from a specified requirement that is approved before delivery or use of the item. The supplier requests a deviation because they know — before they ship — that what they are building will not conform to one or more requirements. The acquirer reviews and approves (or rejects) the deviation in advance.

Waiver: An authorization to accept an item that, after production, already fails to meet a specified requirement. The hardware exists. It is nonconforming. The question is whether the nonconformance can be accepted as-is (use-as-is), reworked, repaired, or scrapped.

If the supplier delivered hardware and you are discovering the nonconformance now, you are in waiver territory. If the supplier flagged it before shipping and you agreed to accept it, that should have been handled as a deviation — and if it was not, your records have a gap worth closing.

Why does this matter? Because deviations are captured prospectively in the contract and requirements baseline. Waivers are disposition decisions against existing hardware. Each has different documentation trails, different review board authorities (MRB — Material Review Board — for waivers on most defense programs), and different implications for your verification records.

Step 2: Assess Impact Starting at the Interface Requirement

The instinct when a component fails to conform is to immediately escalate to the program manager or fire off a nonconformance report and wait. Resist this. Before you escalate, you need to know what you are escalating — specifically, what does this nonconformance actually affect at the system level?

Start at the interface requirement that is violated. Interface requirements define the boundary conditions between subsystems: signal levels, connector pin assignments, mechanical envelope, power draw, thermal output, timing, protocol version, and so on. They are the contractual surface between your system and the supplier.

Work the impact in three directions:

Upstream: Which system-level requirements drove this interface requirement? If a connector is delivering 2.9V nominal instead of 3.3V, which system-level performance requirements depend on that signal level? Which safety requirements, if any, are in the chain? This tells you the severity of the nonconformance in system terms, not just component terms.

Lateral: Which other components or subsystems consume this interface? An interface requirement violation in a shared bus or a common mechanical datum can affect multiple downstream subsystems simultaneously. A pin-out error on a standard connector may propagate to every board that uses it.

Downstream: Which verification events are linked to this interface requirement? These are the events most immediately at risk. Any test, inspection, or analysis that validates compliance against the nonconforming requirement is now either invalid (if already executed) or needs re-evaluation (if planned).

Document this analysis. It is the factual basis for the waiver or deviation request, and it will determine the review board’s authority level. A nonconformance that touches a safety-critical requirement requires different authority than one affecting a non-safety performance margin.

Step 3: Initiate the Nonconformance Report and MRB Process

With impact documented, open a formal Nonconformance Report (NCR). On most aerospace and defense programs, this is not optional — it is contractually required, typically within a defined window after detection (24–72 hours is common).

The NCR captures:

  • The specific requirement(s) violated, with requirement identifiers
  • The measured or observed actual value vs. the specified value
  • The detection method (incoming inspection, integration test, analysis)
  • Your preliminary impact assessment
  • The hardware disposition recommendation (use-as-is, rework, repair, return to supplier, scrap)

The Material Review Board reviews the NCR. MRB composition varies by program, but typically includes the systems engineer, quality engineer, design engineer for the affected subsystem, and often a customer or government representative for critical items. The MRB’s job is to make a disposition decision and determine whether a waiver request needs to go to the customer (many minor nonconformances can be dispositioned use-as-is by the contractor’s own MRB under delegated authority; others require Government MRB concurrence).

If the disposition is use-as-is, the waiver request documents the specific requirement being waived, the technical rationale for accepting the nonconformance, the impact assessment, and any compensating measures or monitoring conditions.

A well-written waiver request does not argue that the requirement was wrong or unnecessary. It demonstrates that, despite the nonconformance, the system will still meet its operational requirements — and it shows the analysis supporting that conclusion.

Step 4: Update the Requirements Baseline and Systems Model

Accepting a waiver does not make the nonconformance disappear from your requirements baseline. It means you have formally acknowledged that a specific unit of hardware does not meet a specific requirement, and you have documented the basis for accepting it.

Your systems model and requirements baseline must reflect this. Concretely:

  • The waived requirement should be marked with a disposition status (accepted nonconformance, waiver reference number, approval date and authority)
  • The affected hardware configuration item should be flagged in your configuration management system with the associated waiver
  • If the waiver changes the as-built configuration versus the as-designed configuration, your Configuration Item Data List (CIDL) or equivalent must be updated

If the nonconformance reveals that the interface requirement itself was incorrect — perhaps the supplier built to a superseded version of the ICD, or there was an error in the original requirement — then you may also need to initiate a requirements change through your formal change control process. This is a different action from the waiver; the waiver covers the existing hardware, the requirements change addresses the baseline going forward.

Failure to update the baseline is how programs accumulate what some engineers call “legacy debt” — nonconformances that were verbally accepted, never formally closed, and eventually surface during a customer audit or, worse, a mishap investigation.

Step 5: Trace the Impact to Downstream Verification Events

Every verification event linked to the affected interface requirement must be explicitly re-evaluated. This is the step most frequently skipped, and it is where programs create the most serious long-term risk.

Ask the following for each linked verification event:

  1. Has this test already been executed? If yes, the test results may be invalid — the hardware under test did not conform to the interface requirement, so the test was not actually demonstrating compliance. The verification record must be annotated, and you may need to re-run the test after rework or after documenting that the accepted nonconformance does not affect the test’s validity.

  2. Is this test planned but not yet executed? If yes, evaluate whether the test procedure, acceptance criteria, or test configuration need to be updated to reflect the nonconformance.

  3. Does the waiver change what “compliant” means for this verification event? A use-as-is waiver on a voltage level may require updating the acceptance criteria in the test procedure to match the actual delivered characteristic — with explicit customer concurrence if the test is a contractually mandatory verification event.

These re-evaluations should be documented, not kept in engineering notebooks. The verification traceability matrix (or its equivalent in your systems model) should reflect the current status of every verification, including any affected by accepted nonconformances.

How Modern Tools Make This Process Faster

The process described above is correct regardless of what tool you use. But the manual version — searching requirements databases for links, tracing through spreadsheet RTMs, hunting through document-based ICDs for all the requirements that reference a given interface — is slow and error-prone. It is the kind of work where experienced engineers miss connections simply because the dataset is too large to traverse reliably by hand.

This is where graph-based requirements tools make a genuine difference. Flow Engineering models requirements and their relationships as a live graph, not as rows in a document. When a specific interface is affected by a nonconformance, Flow Engineering lets you navigate directly to that interface node and surface every requirement, verification event, test case, and design artifact linked to it — in both directions across the trace chain.

In practice, this means the impact assessment that might take a senior systems engineer two days of spreadsheet work can be done in a fraction of that time. You are not searching; you are traversing a model that already contains the connections. Flow Engineering also makes it easier to annotate the graph with nonconformance and waiver status, so the baseline reflects the current disposition rather than the original intent.

The tool is focused on requirements and traceability, which means it is not a full PLM or configuration management system. But for the specific problem of understanding what an interface nonconformance touches — and ensuring downstream verification events are identified and re-evaluated — that focused scope is an advantage, not a limitation. The impact assessment is faster and more complete, which means the MRB package is better documented and the program’s risk posture is clearer.

Honest Summary

When a supplier delivers hardware that does not meet an interface requirement, the correct sequence is: classify the situation accurately (waiver, not deviation), assess impact from the interface requirement in all three directions, open the NCR and drive the MRB disposition, update the requirements baseline and configuration records to reflect the accepted nonconformance, and explicitly re-evaluate every verification event linked to the affected requirement.

None of these steps are optional on a formal aerospace or defense program. Skipping the baseline update or the verification re-evaluation does not make the problem go away — it defers it to a customer audit, a system-level test failure, or something worse.

The process is mature and well-defined in the standards. The failure mode is almost always execution discipline: the right steps get skipped under schedule pressure, or the impact assessment is less thorough than it should be because tracing through a large requirements dataset manually is genuinely hard work. Tools that make the tracing faster reduce the temptation to cut corners on the analysis — which is a real and underappreciated form of program risk reduction.