How Aerospace Systems Engineers Use AI to Keep Flowdown True

Every program has a requirement that was correct on the day it was allocated and wrong by the time it was verified. Nobody lied. A bracket got thicker, a radiator panel moved four inches aft, a mass budget was renegotiated in a hallway, and the allocation sitting in the requirements tool kept saying what it said in March.

That gap is where most flowdown pain lives, and it is where AI earns its place on an aerospace program. It doesn't author requirements. It reads tirelessly: it drafts, cross-checks and notices drift while engineers decide what is true.

This post covers how aerospace systems engineers use AI in that workflow, task by task. It covers drafting child requirements, checking parent coverage and verifiability, tying flowdown to CAD so a geometry change flags the requirements it touches, and keeping verification evidence attached when allocations move. It also draws a hard line around what AI should never do: baselines, waivers and sign-off stay with named engineers. If you want the mechanics of flowdown itself, they are covered elsewhere. This is the AI-assisted workflow layered on top.

Where flowdown breaks in practice: allocation is true on the day it is written

A flowdown is a set of claims. The vehicle must survive 12 g axial. The structure subsystem gets a stiffness and strength allocation. The bracket gets a margin of safety. Each claim is tied to a parent and, in the best case, to a verification method. The links are the product.

The links decay. They decay through ordinary work: a design change in CAD, a supplier substitution, a trade study that moves a mass allocation, a test result that forces a derived requirement. None of these events edits the requirements tool. The engineer who moved the panel is thinking about packaging, not about requirement 4.3.2.7 two levels down.

So the failure mode is not missing requirements. It is stale ones. A stale requirement passes review because it reads fine. It fails at the Functional Configuration Audit, or worse, after delivery, when someone compares what was verified against what was built. The FCA and PCA evidence guide describes how auditors walk that gap.

AI can help in three places, and they map to three ways flowdown goes stale: the allocation was never well drafted, the allocation was never checked, or the design moved underneath it. Everything below is organized around those. The constant in every task is the same. The AI proposes, flags and drafts. An engineer accepts, edits or rejects, and every baseline change carries a human name.

Task 1: AI drafts child requirements and proposes allocations for engineer review

Drafting is the least controversial use and the easiest to get wrong. The right framing: AI produces a first pass that an engineer would otherwise spend a day typing, and the engineer's judgment goes into the content instead of the clerical work.

Take a parent requirement at the system level: the launch vehicle adapter shall transmit payload loads without exceeding a deflection limit at the separation plane. A systems engineer asks the AI to propose child requirements for the structure, the separation mechanism and the fasteners. A good draft comes back with candidate children, a proposed allocation of the deflection budget across them, the units, and a stated rationale for each split. The engineer reads it the way they would read a junior engineer's draft: with suspicion, and with a pen.

Three habits make this work.

First, always require the rationale. An allocation without a stated reason is just a number. Capture why the split is 60/40, because the reason is what lets you re-allocate intelligently later. See derived requirements for why the parent link and the reason have to travel together.

Second, mark every AI-drafted item as proposed. Nothing enters a baseline in a proposed state. Tandem's requirements module keeps a redlined change history and approvals, so a draft is visibly a draft until someone with authority approves it. AI agents in Tandem can search, create and update requirements, and the approval step stays human.

Third, give the AI the program's context: the parent, the architecture node, the interfaces, the existing siblings. A draft written without sibling requirements will duplicate or contradict them. Context is the difference between a useful draft and plausible filler.

Task 2: AI checks parent coverage, consistency, ambiguity and verifiability at every level

Checking is where AI beats a tired human reviewer on volume. A reviewer reading 600 requirements on a Thursday afternoon will miss things. A model reading the same 600 will not get tired, though it will get some things wrong, which is why its output is a list of findings, not a verdict.

Four checks pay off on nearly every program.

Coverage: does every parent have children that, taken together, satisfy it? And does every child trace to a parent, or is it an orphan someone added for reasons nobody wrote down? Orphans are either derived requirements missing their rationale or scope creep. Both deserve a human look.

Consistency: do sibling requirements contradict each other? A thermal child that caps a radiator panel at a temperature the structural child's material cannot survive is a contradiction no single author sees, because the two requirements live in different disciplines' heads.

Ambiguity: words like adequate, minimal, sufficient and as required are unverifiable by construction. An AI flags them in seconds and proposes a quantified rewrite. The engineer picks the number, because the number is an engineering decision.

Verifiability: can this requirement actually be closed by test, analysis, inspection or demonstration? A requirement with no feasible method is a defect. The verification methods guide lays out the four methods and what each demands.

Run the checks at every level, not only at the top. Flowdown errors compound downward, and a lower-level requirement that reads cleanly on its own can still fail to cover its parent. Treat the output as a review queue. Measure it by how many findings an engineer accepts, not how many the AI produces.

Task 3: Connecting flowdown to CAD so a geometry change flags the requirements it touches

This task most separates an AI-assisted workflow from a spreadsheet with a chatbot attached. Requirements live in one system, geometry lives in CAD, and the two only meet when a person remembers to compare them. The expensive failures happen in that gap.

Tandem connects the two. Its CAD integration (with direct plugins for SolidWorks, CATIA, NX, and Fusion, and planned support for Onshape) records changes and surfaces a before/after 3D diff with a plain-language summary and the affected requirements and annotations. Requirements are verified continuously against live attributes pulled from CAD, spreadsheets and telemetry. The practical effect: a geometry change flags the requirements it touches, and an engineer decides what happens next.

Structural example. A designer thickens a rib to clear a harness and, without meaning to, adds 340 grams to a primary structure with a 5.2 kg mass allocation. The mass attribute changes in CAD. The requirement on structure mass, and the parent budget it rolls into, are flagged. The stress analyst is pulled in because the load path changed too. See structural requirements traceability when CAD changes for the full pattern.

Thermal example. A bracket is relocated to free up a connector, and it now shadows part of a radiator's view factor. No thermal requirement was edited. The geometry diff still reaches the thermal requirement on radiator rejection and flags it for the thermal lead. The companion piece on thermal requirements traceability covers it.

Note what the AI does not do here. It does not rewrite the requirement or declare the design noncompliant. It says: this change touches these requirements, here is the diff, someone needs to own this. Late changes after freeze work the same way, as in tooling change after design freeze.

Task 4: Keeping verification methods and evidence attached when allocations change

Re-allocation is routine. A mass budget gets moved from the avionics box to the structure after a trade. A stiffness requirement gets split differently after a modal survey. The requirement text changes, and the part nobody tracks is what happens to the verification that was already planned or already performed.

Without discipline, one of two bad outcomes follows. Either the old evidence stays attached to a requirement it no longer proves, and a test report quietly claims closure for a threshold that has moved. Or the evidence is orphaned and someone rebuilds the verification matrix by hand before the review.

AI helps by treating verification as part of the requirement, not a sibling record. When an allocation changes, the workflow should answer three questions automatically. Which verification method was assigned to this requirement? Which evidence (test report, analysis, inspection record) is linked to it? Is that evidence still valid for the new value? The AI drafts the answers. The verification lead confirms them.

A concrete case: a deflection limit tightens from 1.2 mm to 0.9 mm. The linked static test measured 1.0 mm. Under the old limit it closed the requirement. Under the new one it does not, and the system should say so before the review does. In Tandem, validation evidence and test management live in the same system as the requirements, so test cases linked to a requirement stay linked, and the requirement's status reflects the live data.

Watch for the opposite error too: an AI that happily re-attaches old evidence to a changed requirement because the text looks similar. Similar is not the same. Make re-attachment an explicit human action, logged with a name and a date. The test anomaly report workflow shows the reverse trace, from a failure back to the requirement it violated.

What AI should not do: baselines, waivers and sign-off stay with engineers

Here is the position, stated without hedging: an AI should never change a baseline, grant a waiver or sign a verification closure. Not with a confidence score, and not with a human-in-the-loop checkbox that nobody reads.

The reason is accountability, not capability. A baseline is a commitment made by named people to a customer, a safety board or a regulator. When something goes wrong, the question is who approved it and on what basis. An AI cannot be that answer. The requirements baseline freeze guide explains why a freeze only means something if changes after it pass through a controlled gate.

The same goes for deviations. A deviation or waiver request is a risk acceptance. AI can assemble the context: which requirement, which parent it protects, what the analysis says, what the change impact is. The decision to accept the risk belongs to the engineer with the authority and the exposure.

The change control board is the right model. An AI can prepare the board package, summarize the diff, list the affected requirements and propose a disposition. The board decides. See how to run a CCB for the structure.

A practical rule for directors who sign baselines: every change in the redlined history must show a human approver, and every AI-generated item must be visibly labeled as such. If you cannot tell from the record which requirements an AI drafted, you cannot audit the process. Make provenance a requirement of the workflow, not a feature request.

A starting workflow for one subsystem and what to measure

Do not roll this across the whole vehicle. Pick one subsystem with active CAD churn, such as primary structure or a thermal radiator assembly, and run it for one build cycle.

Week one: load the subsystem's requirements, parent links and verification methods into one place. Connect the CAD source so geometry and mass attributes are live. If your team uses Tandem, this is the integration setup phase, done with Tandem engineers, and teams can start with a single module such as requirements before adopting more.

Week two: run the coverage, consistency, ambiguity and verifiability checks across the subsystem. Triage the findings with the subsystem lead. Fix real defects, reject false positives, and write down which kinds of finding the AI gets wrong. That list is your calibration.

Weeks three and four: let ordinary design work happen. Every CAD change that touches a flowed-down requirement should produce a flag with an owner. Track what happens to each flag.

Measure five things, and ignore vanity counts.

1. Stale-requirement catches: flags raised on real impacts before a review, versus defects found at the review.

2. Finding acceptance rate: the share of AI check findings engineers accepted.

3. False-flag rate: flags that touched nothing real. Too high and engineers will stop reading.

4. Time from CAD change to a named owner acknowledging the impacted requirements.

5. Evidence mismatches caught: linked verification that no longer proved its requirement after an allocation change.

If the acceptance rate sits under half after two weeks, the problem is usually missing context, not a weak model. Add siblings, interfaces and architecture links and rerun.

Conclusion

The pattern is consistent across all four tasks. AI drafts, checks and flags. Engineers decide, approve and own. The value is not that AI writes better requirements than your leads. It is that a CAD change on Tuesday reaches the right requirement owner on Tuesday instead of an audit finding in November.

Pick one subsystem this month, connect its requirements to live CAD, and count how many stale allocations surface in the first build cycle. If the number is zero, you have a clean program and a useful baseline for comparison. If it is not, you have found your next review's first action item. To see this workflow on your own requirements and CAD, book a Tandem demo and bring your messiest structural or thermal flowdown.