Perspective
~10 min read 

Requirements management is a software category built around storing, versioning, and tracing requirement documents. Lifecycle intelligence is the category replacing it. It is a governed, computable layer that runs from requirements through design, test, verification, and certification, where a requirement is the first commit in a continuous engineering chain rather than a record to be filed.

Requirements still matter. The work outgrew the category name.

Horizontal AI changed what was visible, not what was broken. Requirements now take seconds to write. The constraint has moved to everything that happens after they exist. Storage-era tools assumed creation was expensive and governance was manual. Both assumptions are gone. This changes the unit of value from storing engineering artifacts to governing their validity over time.

Key takeaways

• The first generation of engineering software managed artifacts. The next generation governs the relationships between them, shifting the unit of value from documents to system-wide integrity.
• Horizontal AI can generate requirements, but cannot govern them. Generation in AI systems is probabilistic, while governance must be deterministic, requiring architectural separation between creation and evaluation.
• Lifecycle intelligence reframes engineering software from recording intent to continuously maintaining the integrity of that intent as it moves through design, test, and certification.
• Shadow AI is already present in engineering workflows, where consumer AI tools operate outside governed processes, creating downstream audit debt during verification and certification.
• A retiring expert workforce is accelerating the loss of institutional knowledge, making structured requirements a critical mechanism for continuity.
• In regulated industries, data sovereignty constraints determine where lifecycle intelligence can operate and how it is deployed.

Why the requirements management category is dying

Requirements management answers a question nobody is asking anymore. The category was named when the hard problem was where requirements lived and how they were controlled across teams, and the dominant tools solved it well. Requirements moved out of binders and into databases, under version control, baselines, and trace links. Those capabilities became table stakes. The bottleneck moved. The category never did.

A systems engineering consultant who advises energy and infrastructure firms put it plainly. “We don’t really rewrite requirements anymore. It’s more about managing the data and the relationships.” The unit of work has become the network of relationships around the requirement, from source and rationale through children, verification, and certification evidence.

Meanwhile, governance initiatives built on the old category keep failing to stick. A digital engineering leader at a major defense prime described the experience directly. “We tried for the last three years to work with some experts in the field to bring some of this technology and more rigorous digital engineering to our programs, and it’s just not getting traction.” The pattern repeats across defense, medical, and industrial programs. Storage-era tooling gives governance nothing to act on. You cannot govern what you can only store.

What is lifecycle intelligence?

Lifecycle intelligence is the governed, computable layer that spans the engineering lifecycle from requirements through design, test, verification, and certification. Every artifact in this layer carries provenance, quality state, rationale, and explicit relationships that humans, deterministic rule engines, and AI systems can all reason over. Requirements gain status in this model as the first commit in a continuous engineering chain.

This shifts engineering software from a system that stores artifacts to one that evaluates them as they move through transformation. A database preserves outputs. A governed intelligence layer determines whether those outputs remain valid under the conditions the system imposes on them.

Customers are describing this architecture unprompted. A defense prime described its target state as extending “this governance layer all the way from the requirements down through the design, and into the test frameworks, and artifact generation we need for certification.” In a recent discovery session, a precision engineering manufacturer interrupted a capability walkthrough to name the concept themselves. “What you’re describing here is, to coin a current phrase, the digital thread.”

Isn’t this just the digital thread?

A fair objection is that lifecycle intelligence sounds like the digital thread, or digital engineering, or requirements governance wearing a new badge. The digital thread is the connective tissue. It carries artifacts and their links across tools and phases. Lifecycle intelligence is what reasons over that thread. It measures quality, enforces rules, surfaces gaps, and preserves judgment, and it does so deterministically. A thread can tell you that a requirement is linked to a test. It cannot tell you whether the requirement is any good, whether the link is valid, or what is missing entirely. That gap is the difference between the two generations of engineering software. The first managed artifacts. The next governs the relationships between them.

Why AI raises the stakes instead of lowering them

Horizontal AI can write requirements. It cannot verify that they are good, complete, or traceable, and that verification is the intelligence in lifecycle intelligence. A general-purpose model produces a syntactically plausible requirement in seconds, then floods the lifecycle with artifacts that still have to be checked, traced, and certified by something other than the model that wrote them.

This is not only about consumer chatbots. The incumbent requirements tools are racing to add AI of their own, and some now position themselves as AI-native rather than AI-assisted. Adding a model to the same platform that stores the requirement does not resolve the problem, because in most cases, a probabilistic model both drafts the requirement and scores its quality. That is the arrangement the architecture must explicitly prevent. Whether the model is a public chatbot or a feature built into the tool, a system that generates and judges with the same probabilistic engine is still grading its own homework.

Customers are ahead of vendors on the architecture this demands. A senior quality architect at a global medical device manufacturer drew the line precisely. “You have the generative aspect to generate requirements, but then you also have the judge to actually measure the quality. Those two should be two different things. You shouldn’t have the LLM both generate it and measure it.” A systems engineering consultant serving the energy sector explained why the judge cannot be another LLM. “You don’t want it to be random. You don’t want it to be probabilistic. You want to be able to give that as a measure of quality and make it more deterministic.” Engineers at a leading space research laboratory went further and called requirements quality assessment essential, and not replaceable by LLMs.

The principle is worth stating once. Generation is probabilistic. Governance must be deterministic. An architecture that uses the same model to write and to judge has a model grading its own homework.

Ungoverned AI creates audit debt

Audit debt is the re-verification burden created when AI-generated artifacts enter the engineering lifecycle outside governed processes. The speed is borrowed against a future audit, with interest. Like technical debt, it is invisible at creation and expensive at discovery.

It is already accumulating, and the cause deserves its own name: shadow AI. Engineers adopt consumer AI tools individually, outside any process, because no governance exists for how AI enters the lifecycle in the first place.

At a semiconductor equipment leader, engineers use consumer ChatGPT with no process governance attached to the output. At a medical diagnostics company, requirements are exported to Excel, assessed with Copilot, and manually re-entered; none of it is embedded in governance artifacts. At a medical technology company, a Copilot refinement session expanded the requirement set by roughly 30 items with no structured record of what changed or why.

Audit debt is the consequence. Shadow AI is the cause.

As one engineering leader at a defense electronics company put it: “We don’t want people to just push the button and let AI be smarter than us.” That instinct is sound. In a regulated lifecycle, an artifact that cannot show its provenance relocates time into the audit, where it costs more.

The hidden urgency: institutional knowledge is leaving

Continuity is the strongest argument for lifecycle intelligence, stronger than any productivity gain. In oil and gas, an estimated 71 percent of the energy workforce is 50 or older, and the American Petroleum Institute has projected that as many as half of skilled energy workers could retire within five to seven years. In aerospace and defense, roughly 29 percent of employees are over 55, and industry attrition ran near 15 percent in 2024, more than double the U.S. average. A standards leader at a global oil and gas organization described what the numbers mean in practice. “There’s a lot of knowledge leaving the industry. There are a lot of people leaving now in their fifties and sixties, and that knowledge is up here.”

The concern is not new. What is new is the uncertainty AI has layered on top of it. Optimists assume AI will absorb the knowledge gap, and most leave the “somehow” undefined. Skeptics doubt AI can close it, and most have no alternative for capturing decades of tacit engineering judgment. Both camps miss the same point: AI has no structure to work over.

A horizontal model cannot absorb what was never made explicit. When a senior engineer reads a requirement and immediately knows which interfaces it touches and which edge cases it ignores, she is drawing on a model of the program that exists only in her head. The LLM has correlations. She has a model.

The way forward is to make that model explicit and layer AI on top of it. Requirements, with their rationale, justification, and verification logic, are the last structured artifact in which that judgment can be recorded before the people who hold it leave. One global standards organization is doing exactly this at scale, encoding retiring engineers’ reasoning into structured justifications across more than 180,000 requirements.

Requirements management was sold on efficiency. Lifecycle intelligence is bought on continuity.

Where the intelligence lives

In the industries that need lifecycle intelligence most, data is not allowed to leave. A global semiconductor manufacturer permits only restricted, InfoSec-approved LLM touchpoints. Defense primes and critical-infrastructure firms operate under strict rules about data leaving the environment.

Sovereignty is a structural constraint on architecture, not a preference. A lifecycle intelligence layer must run where the data is allowed to live — on-premises, in sovereign clouds, or inside restricted enclaves. A cloud-only horizontal AI play fails this test before the first capability demo. Deterministic quality engines pass it by construction, because they never need to ship requirement text to a third-party model.

What lifecycle intelligence requires: five non-negotiables

Lifecycle intelligence requires five capabilities. A framing note before the list: these are written for the current timeline, in which requirements are the first structured artifact in the engineering chain. That foundation may look different in the future. The entry point could become a model, a simulation, or an artifact class that does not exist yet. The principles underneath will not change: whatever generates cannot also judge, whatever is produced must carry its governance forward, and whatever the lifecycle holds must stay measurable, traceable, and preserved. The five below apply those principles to where engineering lives today, and the absence of any one of them collapses the model back into requirements management with extra steps.

1. A computable substrate. Requirements exist as governed artifacts with provenance, rationale, quality state, and typed relationships. The rationale is where otherwise tacit engineering knowledge becomes a recorded asset. You can only govern what you can clearly define.
2. Deterministic quality measurement, separated from generation. The judge and the generator are architecturally distinct, and the same requirement evaluated twice must score the same.
3. Governance that travels with the artifact from authoring through design, test, and certification, so the evidence exists before the auditor asks.
4. Gap visibility. The system surfaces what is missing, from unlinked verifications to requirements without rationale. Across engineering conversations in 2025 and 2026, this was the most consistently unprompted request.
5. Sovereignty-compatible deployment, including environments where no external LLM call is permitted.

The name is the last thing to change

Categories die quietly, and occasionally on the record. In 2017, Gartner declared enterprise content management dead and renamed the category content services, because the label described storage, while the value had moved to what organizations could do with the content. 

Requirements management is at the same juncture. The label describes where requirements are kept and how they move between people. The value has moved to what the lifecycle can know about them.

The old questions were where requirements live, how they are traced through each phase of development, and how they are managed across multiple stakeholders. The new question is whether your requirements can participate in a governed, intelligent lifecycle, one that measures quality deterministically, preserves the knowledge of the people writing them, survives an audit without improvisation, and runs where your data is allowed to live. 

Step one itself may change. The first structured artifact a program produces a decade from now may be a model or a simulation rather than a requirement. The question will survive the change: is the knowledge governed, is the measurement deterministic, is the judgment preserved, and does the intelligence hold through every phase that follows?

If your tooling answers the old questions and not the new one, you have a lifecycle intelligence gap, and the era of generative AI is widening it every quarter. The diagnosis is simple. Map your lifecycle against the five non-negotiables above, and treat every miss as a line item of audit debt.

Frequently asked questions

Is requirements management dead? 

As a category, yes. As a discipline, no. Requirements writing, traceability, and verification remain essential, but the idea that managing documents is the primary function has been overtaken by lifecycle-wide governance.

Isn’t requirements management just evolving? 

Evolution implies the same unit of work with better tooling. What has changed is the unit of work itself, from managing requirement documents to governing relationships and system-wide integrity across the lifecycle. Incumbents will call it evolution, as ECM vendors did right up until Gartner renamed the category, because nobody can afford the funeral of the name they sell licenses under.

What is lifecycle intelligence? 

Lifecycle intelligence is the governed, computable layer spanning requirements, design, test, verification, and certification, where artifacts are continuously evaluated for provenance, quality, and traceability. It captures the rationale behind engineering decisions, turning otherwise tacit knowledge into a structured, auditable asset. It shifts engineering software from storage systems to systems of continuous judgment that determine everything downstream.

Can ChatGPT or Copilot write requirements? 

Yes, and that is the problem. Horizontal AI tools generate plausible requirement text quickly, but they cannot deterministically verify quality, completeness, or traceability. Without a separate governance layer, this creates audit debt in downstream verification and certification.

What is the difference between lifecycle intelligence and the digital thread? 

The digital thread connects artifacts and their relationships across systems. Lifecycle intelligence reasons over that thread, evaluating quality, enforcing rules, and identifying gaps. The thread provides connectivity; the intelligence provides judgment.

What is audit debt? 

Audit debt is the accumulated re-verification burden created when AI-generated artifacts enter the engineering lifecycle without governance. It is the engineering-lifecycle analogue of technical debt; it comes due at audit or certification, and shadow AI is its cause.

QRA builds the lifecycle intelligence layer that governs requirements from authoring through certification, keeping the system that generates them separate from the one that judges their quality. If your organization is evaluating how to govern AI-generated requirements without inheriting audit debt, we are happy to walk through the architecture directly.