Divergent Technologies: Engineering the Machine That Builds the Machine
Divergent Technologies occupies an unusual position in aerospace manufacturing. They are not a parts supplier, not a capital equipment vendor, not a software company, and not a systems integrator — they are all four simultaneously. Their stated goal is to produce complex metal structures for aerospace and defense that cannot be manufactured any other way. The structures they build — primarily using laser powder bed fusion at scale — are optimized for geometries that would be impossible to fabricate conventionally. To make that possible repeatably, they had to build the manufacturing system itself.
That decision — to own the full stack — creates a systems engineering problem that most aerospace organizations never face. Understanding how Divergent has approached it reveals a methodology that differs from standard aerospace SE practice in several instructive ways.
The Vertical Integration Trap and Why They Stepped Into It
The aerospace industry’s relationship with additive manufacturing has been cautious and incremental. Established primes and Tier 1 suppliers have added AM capabilities to existing workflows, qualifying individual processes for specific part families, then treating qualified additive parts as line replacements for machined or cast equivalents. The qualification is scoped to the part, and the manufacturing equipment is somebody else’s responsibility.
Divergent’s approach inverted this. They began with structures that were explicitly designed to take advantage of what additive enables — thin-wall lattice structures, integrated fittings, topology-optimized load paths — then worked backward to the question of what manufacturing system could produce them reliably. That backward derivation meant they could not buy a machine off the shelf and qualify it. They had to build one, which put them in the equipment development business whether they intended to be or not.
The consequence is a requirements architecture that has no clean boundaries. A requirement on a structural node — fatigue life at a given load condition, for example — traces not just to a design choice but to a specific combination of machine configuration, process parameters, material feedstock specification, and post-processing steps. Change any variable in the chain, and you potentially invalidate the structural requirement. That coupling is not a problem to be solved and then moved past. It is a permanent feature of the engineering environment.
How Requirements Flow Across Three Domains at Once
In a conventional aerospace manufacturing program, requirements flow downward through a hierarchy: system-level requirements decompose into subsystem requirements, which drive component design, which drives manufacturing process selection. Manufacturing is typically at the bottom of that chain. It is a constraint on the design, not a peer domain.
Divergent’s architecture breaks that model. Their three primary requirement domains — manufacturing equipment, process control software, and output structures — are mutually constraining in ways that do not resolve to a clean hierarchy.
Consider a specific example: the requirement for geometric consistency in a complex node produced in a build volume at a specific location. That requirement traces simultaneously to:
- The optical system and scanner performance specification of their build machines (equipment domain)
- The thermal model and scan strategy embedded in their process control software (software domain)
- The geometric tolerance stack-up and acceptance criteria for the structural node itself (product domain)
None of these can be defined independently. You cannot write the equipment specification without understanding what geometric accuracy the product requires. You cannot write the process software specification without understanding what the machine can physically deliver. And you cannot finalize the product specification without knowing what the combined system can achieve with acceptable yield.
This is not analysis paralysis — Divergent produces hardware — but it means the requirements management discipline they practice is inherently iterative and cross-domain. The tools and processes that work for a single-domain requirements baseline do not map cleanly onto this problem.
The Qualification Circularity Problem
Qualification under aerospace standards — AS9100, NADCAP, customer-specific process specifications — is designed around an implicit assumption: the manufacturing process is separable from the product. You qualify the process (welding, heat treatment, plating) against a standard, and then you apply the qualified process to produce products. Qualification artifacts are stable because the process is stable.
Divergent’s situation is different in a way that matters structurally. They are qualifying a manufacturing process they are also actively developing, using equipment they designed and built, under standards that were written for conventional manufacturing. The qualification is not a gate at the end of development — it is woven through development. Every iteration on the machine or the process software potentially requires revisiting qualification evidence.
The practical response to this has been to invest heavily in the data architecture around their builds. Every production build is instrumented. Sensor data, process parameter logs, in-situ monitoring outputs, and post-build inspection data are associated with every build event. This is not primarily for traceability in the compliance sense — it is because in a system this tightly coupled, the only way to understand a deviation is to have complete records of what the system was doing when it occurred.
That data orientation shapes how requirements are managed. Rather than a static requirements baseline with periodic change review, the effective requirements architecture has to be live — connected to the evidence that demonstrates compliance. Whether a given set of process parameters continues to meet the requirements on a structural node is not a question you answer once at qualification. It is a question you answer continuously, build over build.
Spanning Disciplines Without Losing Coherence
Divergent’s engineering organization is structured around the vertical integration thesis. Engineers who would sit in entirely separate departments at a prime contractor — mechanical, software, controls, materials, structural analysis, manufacturing process — work in proximity and with explicit shared accountability for the system.
This is a deliberate organizational choice, and it has real engineering benefits. The tight coupling between domains that makes requirements management hard also means that when something goes wrong, the people who can diagnose the root cause are in the same room. A deviation in as-built geometry can be traced from the structural impact through the process parameters to the machine behavior by a team that understands all three layers.
The overhead cost is coordination. When requirements span disciplines, change propagation becomes a distributed problem. A materials feedstock change that looks routine to the supply chain team may have implications for the thermal model in the process software, which has implications for residual stress in the structure, which has implications for fatigue life. Tracking that chain of implications requires both a shared model of how the domains connect and a process for ensuring that everyone whose work is affected by a change is actually aware of it.
Organizations that do this well tend to rely on something more structured than email and meeting minutes. The requirement is visible, its dependencies are explicit, and a proposed change triggers a review of what it touches before it is approved. For organizations operating at Divergent’s level of domain coupling, that kind of structured change impact analysis is not a luxury — it is how you avoid building hardware to requirements that were silently invalidated three changes ago.
Process Qualification Under Novel Standards Conditions
One of the less-discussed challenges in novel manufacturing qualification is that the standards themselves were not written for the situation. NADCAP’s requirements for special processes, customer flow-downs from major primes, FAA or DoD qualification frameworks — these assume the manufacturer is applying an established process to an established product category. The novelty in additive manufacturing is not just geometric; it is epistemic. There is genuine uncertainty about failure modes, about long-term behavior, and about which process variables are actually critical.
Divergent’s response to this has been to work closely with customers and certification bodies to define what the qualification evidence actually needs to demonstrate. This is not unique to them — it is the standard challenge facing the additive manufacturing industry — but the scale at which they operate it, across a system they also designed, makes the problem more acute.
The practical effect is that qualification for Divergent is as much a knowledge management problem as a testing problem. What do you know? How do you know it? Is the knowledge tied to the specific configuration that produced it, or does it generalize? For a company developing their manufacturing system over time, the last question is critical. Evidence generated on a previous machine configuration may or may not transfer to the current one. Knowing which evidence transfers and which must be regenerated requires a level of configuration management that is more demanding than what standard aerospace programs typically require.
What This Looks Like at the Tool Level
Organizations operating across this kind of multi-domain, tightly coupled requirements environment eventually hit the limits of document-based requirements management. The connection between a structural requirement and the process parameter specification that contributes to meeting it is not a relationship that a document stores well. It can be written down, but the relationship is passive — it does not automatically surface when either end of the relationship changes.
Graph-based requirements models handle this better because the relationship is a first-class object. When a process parameter changes, the system can traverse the graph and identify which structural requirements have that parameter in their compliance evidence chain. This is the kind of traceability that tools like Flow Engineering are built around — treating requirements, their derivations, their verification evidence, and their dependencies as connected nodes rather than rows in a spreadsheet or sections in a document. For a company like Divergent, where the requirements graph spans equipment specs, software behavior specs, and structural acceptance criteria simultaneously, that model is not a preference — it is a practical necessity.
The Honest Assessment
Divergent’s engineering challenge is genuinely novel, and their approach to it — vertical integration, cross-disciplinary organization, data-intensive process qualification — is coherent and internally consistent. The risks are also real.
The triple-role problem does not go away. Being simultaneously the equipment vendor, the manufacturer, and the systems integrator means that accountability for failures is never cleanly separable. When a structural node fails acceptance, the failure investigation spans domains in a way that a supplier providing a part to a prime’s drawing never has to deal with. That investigation burden is real engineering overhead.
The qualification-is-ongoing model is also more expensive than qualification-as-a-gate. Continuous evidence generation, continuous configuration management, continuous verification that the process that was qualified last quarter is still the process you are running today — these are significant sustained costs.
What Divergent has demonstrated is that the costs are worth bearing if the alternative is not being able to manufacture the structures at all. For geometries that cannot be made any other way, the overhead of managing a vertically integrated system is the price of admission. Their systems engineering problem is harder than most. The methodology they have built to manage it is, by necessity, more sophisticated than most.