The Supplier Qualification Crisis: How OEM Requirements Flow (or Fail to Flow) Down the Supply Chain

A prime contractor finishes a detailed system requirements specification. It is reviewed, baselined, and stored in a requirements management tool. Then it gets sent to a Tier 1 supplier as a 400-page PDF.

The Tier 1 reads the PDF, extracts what it believes are the applicable requirements, copies them into its own internal document, adds some derived requirements of its own, and sends a subset to its Tier 2 machining shop as a drawing package and a statement of work. The Tier 2 builds to the drawing. Nobody at the prime ever sees whether the original requirement — say, a specific vibration load envelope for an avionics chassis — survived the journey intact.

This is not an edge case. It is the dominant pattern in aerospace, automotive, and defense supply chains today, and it is the proximate cause of a dispiriting fraction of field failures, cost overruns, and program delays that get attributed to “supplier quality issues” in post-mortems.

The problem is not that suppliers are careless. It is that the mechanisms for transmitting requirements across organizational boundaries are structurally inadequate for the complexity of modern hardware programs. Understanding why requires looking at what the regulatory frameworks actually demand, what tools suppliers actually run, and where the communication breaks down at each tier.

What the Regulations Actually Require

Three regulatory frameworks govern requirements flow-down for the majority of complex hardware programs in Western supply chains: AS9100 for aerospace and defense quality management, IATF 16949 for automotive, and CMMC for defense cybersecurity. Each mandates flow-down. None specifies how.

AS9100 Rev D requires organizations to communicate customer requirements to relevant internal functions and to ensure that externally provided processes, products, and services conform to specified requirements. Clause 8.4 on external provider control explicitly requires that the organization communicate requirements to external providers and retain documented information demonstrating that those requirements have been met. What it does not specify is the format, the tool, the level of fidelity, or the mechanism for detecting when a requirement has been mistranslated or dropped.

IATF 16949:2016 goes further in automotive, requiring a formal process for customer-specific requirements — CSRs — to be evaluated and included in the scope of the quality management system. It requires a product approval process, typically PPAP in practice, that traces production output back to engineering specifications. But PPAP documentation is retrospective. It confirms that a part was built to a spec. It does not prevent a requirement from being lost before the spec was written.

CMMC 2.0 addresses a different dimension of flow-down: cybersecurity requirements on defense contracts. Under DFARS 252.204-7021, primes must flow CMMC requirements to subcontractors who handle Controlled Unclassified Information. The challenge here is that many Tier 2 and Tier 3 suppliers have no idea what CUI they are processing, because the prime never told them explicitly. The requirement exists in a contract; it was never operationalized into something the supplier could act on.

In each framework, the regulatory obligation exists. The operationalization gap between “you must flow requirements down” and “here is how to do it so they survive intact” is left entirely to industry practice. And industry practice, even in 2026, lags badly.

What Tools Suppliers Actually Use

Survey data from supplier quality organizations and anecdotal evidence from program managers tells a consistent story: requirements management tooling sophistication drops sharply at each tier boundary.

At the prime contractor or OEM level, most large programs run some form of dedicated requirements management tooling. IBM DOORS and DOORS Next remain dominant in aerospace and defense. Jama Connect has made significant inroads in automotive and medical device programs. Polarion and Codebeamer are common in automotive Tier 1s with strong software content. These tools have genuine strengths — mature traceability models, change management workflows, and integration with downstream verification tooling.

At Tier 1, the picture fragments. Large Tier 1 suppliers — a Collins Aerospace, a Bosch, a Moog — often maintain their own DOORS or Jama environments. But the interface between the prime’s environment and the Tier 1’s environment is almost never automated. The standard mechanism is export to Word or PDF at the prime, import (meaning manual re-entry) at the Tier 1. Unique identifiers assigned by the prime’s tool often don’t survive this transition. When the prime updates a requirement, the Tier 1 finds out when someone reads their email.

At Tier 2 and below, dedicated requirements management tools are rare. A typical Tier 2 precision machining or electronics assembly shop manages requirements through a combination of engineering drawings, purchase order terms, and quality plans — all document-based, none of it connected. The concept of a requirement having a unique ID that traces back to a parent requirement at the prime is foreign to most Tier 2 operations. This is not negligence; it reflects rational economics. A fifty-person machining shop cannot justify a DOORS license to fulfill a $2M subcontract.

The result is a progressive lossy compression of requirements as they move down the supply chain. Each tier boundary strips away context, rationale, and traceability. By the time a requirement reaches the hands building the physical hardware, it has often been reduced to a dimension on a drawing or a single line in a work instruction — stripped of the engineering reasoning that would allow a supplier to recognize when a deviation matters.

Where the Communication Actually Breaks Down

The failure modes cluster around four distinct points.

Translation at the tier boundary. When a Tier 1 receives a prime’s requirements document, someone must decide which requirements apply to which suppliers and how to re-express them in the Tier 1’s own documentation system. This is a knowledge-intensive, error-prone task performed by engineers under schedule pressure. Requirements get dropped because an engineer judged them not applicable. Requirements get mistranslated because the Tier 1 engineer did not understand the original technical rationale. Derived requirements — things the Tier 1 needs to add to make the prime’s requirement buildable — sometimes crowd out or contradict the parent requirement without anyone noticing.

Change propagation failure. A prime updates a load requirement late in design. The update is captured in their DOORS database. It is communicated to the Tier 1 in a contract modification or an engineering change notice. The Tier 1’s internal document gets updated. The Tier 2 gets a revised drawing — maybe. Whether the Tier 2 production team actually updates their work instructions depends on the Tier 2’s internal change management rigor. This chain has no automated enforcement mechanism. Each link relies on human diligence.

Requirement-rationale separation. Requirements management tools at the prime level typically store both the requirement and its rationale — why it exists, what failure mode it prevents, what margin it carries. When the requirement is exported to a PDF and sent downstream, the rationale rarely travels with it. A Tier 1 engineer looking at a requirement that seems overly conservative has no visibility into whether the margin was deliberately set to cover an uncharacterized failure mode or whether it was a legacy holdover that could reasonably be challenged. In the absence of rationale, suppliers either over-interpret (building in unnecessary cost) or under-interpret (filing a deviation that should never have been necessary).

Verification traceability gaps. Even when requirements survive the flow-down intact, verification evidence generated at lower tiers often doesn’t flow back up in a way that closes the loop. A Tier 2 test report confirming compliance with a specific requirement may exist in a file cabinet at the Tier 2 facility and never be linked to the prime’s requirements database in any structured way. From the prime’s perspective, the requirement is “verified” because the Tier 1 signed off on PPAP or delivered a Certificate of Conformance. Whether that CoC is grounded in actual test evidence against the specific requirement is often unverifiable.

What a Modern Digital Flow-Down Process Would Look Like

The gap between current practice and what is technically achievable is significant. The components of a modern digital flow-down process are understood; the challenge is adoption across a fragmented supply chain.

Structured requirement objects, not documents. The foundational change is treating requirements as structured data objects — each with a unique identifier, a type, a verification method, a rationale field, and explicit parent-child relationships — rather than as paragraphs in a document. This is what tools like DOORS and Jama already do internally. The problem is that structured data gets flattened to documents at the tier boundary. A modern process requires the structured objects to cross that boundary intact.

Standardized exchange formats. ReqIF (Requirements Interchange Format) exists precisely for this purpose — it is an ISO standard for exchanging requirements data between tools while preserving structure, identifiers, and attributes. ReqIF support is present in DOORS, DOORS Next, Jama, and Polarion. Actual use of ReqIF across tier boundaries remains limited, largely because it requires both organizations to have compatible tooling and the organizational will to implement the exchange. But where it is implemented — in some automotive and aircraft programs — it demonstrably preserves requirement fidelity across boundaries.

Bidirectional change notification. A connected flow-down process does not just push requirements downstream once. It propagates changes in near real-time and notifies downstream stakeholders of the specific requirements that changed, what changed, and what re-verification may be required. This is a workflow problem as much as a tooling problem, but it requires the tooling infrastructure to be connectable.

Verification evidence linkage. Verification results generated at lower tiers need to be linked back to specific requirement identifiers in the prime’s system, not summarized in narrative form. This closes the traceability loop and gives the prime actual visibility into compliance status rather than a stack of signed certificates.

Tools designed around graph-based data models — where requirements, design elements, tests, and verification evidence are all nodes in a connected structure — are architecturally better suited to this problem than document-centric tools. Flow Engineering, for instance, represents requirements and their relationships as graph structures that can propagate changes and surface broken traceability links automatically. For OEMs managing complex multi-tier supply relationships, this model makes it possible to see, at a glance, which supplier-facing requirements have unresolved changes and which verification gaps exist — something that is practically impossible to do in a document-based system.

The supplier-facing challenge remains: getting structured data into and out of small Tier 2 and Tier 3 suppliers who lack requirements management tooling. One practical approach gaining traction is lightweight supplier portals — web-based interfaces that allow suppliers to view applicable requirements, acknowledge them, and submit verification evidence without needing to license or operate a full requirements management platform. Flow Engineering has moved in this direction with supplier-facing views that don’t require the Tier 2 to run the full platform internally.

The Honest Assessment

The regulatory frameworks are not the problem. AS9100, IATF 16949, and CMMC all create genuine pressure to flow requirements down and to verify compliance. The problem is that the regulations set the destination without specifying the road, and most of the supply chain has taken the shortest path: document sharing.

The tooling to do this properly exists. ReqIF, graph-based requirements platforms, bidirectional change propagation, and supplier portals are all real and available. The barrier is not technology; it is the combination of legacy investment in document-centric processes at prime and Tier 1 level, the economic infeasibility of full tooling adoption at Tier 2 and below, and organizational inertia that treats requirements flow-down as a compliance checkbox rather than a system reliability mechanism.

Programs that have connected their requirements chains — typically high-consequence aerospace or defense programs where the cost of field failure vastly exceeds the cost of tooling — have demonstrated that digital flow-down meaningfully reduces late-stage defect discovery, supplier deviation rates, and re-verification cycles.

For the broader supply chain, the question is not whether digital requirements flow-down is worth doing. The question is whether the industry will get there before the next significant program failure makes the case more starkly than any article can.