Ask any systems engineer what eats the week before a milestone review and a lot of them will say the same thing: chasing down which requirement traces to which model element, and which one doesn't trace to anything at all. That gap between "we wrote a requirement" and "we can prove it's satisfied and verified" is where programs lose schedule, and it's the part of MBSE that resists automation the longest, right up until an NLP model gets good enough to read requirements the way a reviewer does.
What the NLP layer actually checks
The first wave of automation here isn't about traceability at all. It's about requirement quality, and it's already shipping in production tools. Jama Connect Advisor runs each requirement against roughly three dozen INCOSE guide rules and six EARS syntax patterns, flagging vague terms, passive voice, escape clauses like "as appropriate," and missing units before a human ever reviews the line. QRA's QVscribe does something similar, templating requirements into EARS form ("While <precondition>, when <trigger>, the <system> shall <response>") and scoring them against INCOSE compliance criteria. Visure Solutions offers comparable checks aimed at unambiguity and testability.
None of this is generative in the risky sense. It's pattern matching against a known rulebook, which is exactly why it works well enough to trust. A requirement that says "the system should handle high load appropriately" gets flagged for "should" (not a mandate), "handle" (not measurable), and "appropriately" (not defined), and the tool suggests an EARS-shaped rewrite. That's a real time save, and it catches the kind of ambiguity that used to slip through peer review because a tired engineer skimmed past it.
The harder problem: generating the trace links
Quality-checking a single requirement is a bounded problem. Tracing hundreds or thousands of requirements to the right architecture elements, test cases, and hazard analyses is not, and that's where large language models are now being pointed. Researchers at NASA Goddard and the Systems Engineering Research Center presented work in late 2025 on using LLMs to generate and validate MBSE trace links automatically, treating the model's structured elements and the requirement text as inputs the model can reason over jointly rather than as two documents a human has to cross-reference by hand. Academic efforts like TraceLLM take a similar approach, using prompt engineering to surface candidate trace links between requirements and code or design artifacts.
The pattern across this research is consistent: the model proposes, a human disposes. Nobody serious is shipping trace links straight from an LLM into a certification package without review, because the failure mode isn't "no trace link," it's "a confident, plausible-looking trace link that's wrong." In a regulated program that's worse than a gap, because a gap gets caught in audit and a wrong link doesn't.
Why unconstrained natural language is still the wall
Here's the honest limit, and it shows up in the research literature more than in vendor marketing: no current system achieves both full automation and formally verifiable traceability when the input is unconstrained natural language. You can get close to full automation if you constrain the input format (EARS-templated requirements written against a controlled vocabulary), or you can get formal rigor if you accept heavy human involvement, but nobody has both at once for requirements written the way engineers actually write them on a Tuesday afternoon under deadline pressure.
That's not a knock on the tooling, it's a description of the actual problem. Natural language is ambiguous by construction, and MBSE's whole value proposition is replacing ambiguous prose with typed, checkable model elements. Asking an LLM to bridge the two means asking it to disambiguate exactly the kind of text SysML was invented to get away from. The tools that work best right now are the ones that push requirements toward EARS and INCOSE-compliant structure early, which shrinks the ambiguity the LLM has to resolve later.
Where this connects to the model, not the document
The traceability problem gets easier when requirements live inside the same structured environment as the architecture they're tracing to, instead of in a separate document that has to be synced by hand. This is one of the areas where SysML v2's typed requirement definitions and satisfy/verify relationships matter more than they look like they should on paper. Teams building architecture in Dassault's Cameo Systems Modeler or Eclipse Capella typically still bridge to a dedicated requirements tool for the NLP quality layer, since that's where the EARS and INCOSE rule checking has matured. Newer SysML v2-native platforms such as Dalus build requirements, architecture, and trace links into one model from the start, which changes where the LLM's job starts and ends: it's suggesting links between elements that already share an identifier scheme, rather than reconciling two systems that don't know about each other.
What it won't solve
A few honest caveats worth sitting with before you budget for this:
- Review burden shifts, it doesn't vanish. Someone still has to check every AI-suggested trace link, and reviewing a plausible-looking wrong answer takes real cognitive effort, sometimes more than writing the link from scratch would have.
- Garbage in, garbage out still applies. If your requirements are written as loose prose with no structure, the LLM is disambiguating on your behalf, and it will get some of that wrong in ways that are hard to catch without independently re-deriving the requirement.
- These tools need a body of correct trace links to evaluate against, and most programs don't have a clean, curated dataset of verified trace links lying around to use as ground truth.
- Regulated domains will move slowly here on purpose. A DO-178C or ISO 26262 auditor is going to want to know exactly how a trace link was generated and validated, and "the LLM suggested it and someone clicked approve" needs a documented process behind it, not just a UI feature.
Bottom line
The requirement-quality layer, checking prose against EARS and INCOSE rules, is mature enough to trust today and there's little reason not to run it. The trace-link-generation layer is real, actively researched, and useful as a first-pass suggestion engine, but it's not close to replacing the human judgment call on whether a link is actually correct. The programs getting the most out of this right now are the ones treating AI as a drafting and triage assistant for traceability, not an oracle, and putting the structural work into requirements that are unambiguous enough for the model to reason about in the first place.