AI can generate requirements. Can it make them decision-ready?
Hi r/systems_engineering,
I would like to ask for feedback on a problem that I suspect many systems engineering teams will face more often as AI tools become normal in engineering workflows.
AI can generate engineering artifacts much faster than organizations can make those artifacts trustworthy, accountable, and usable for decisions.
By “artifacts,” I mean things like:
- draft requirements
- interface assumptions
- architecture options
- verification plans
- test ideas
- risk lists
- change impact notes
- summaries of stakeholder discussions
These outputs can look polished. They can even be directionally useful. But in a systems engineering context, that is not enough.
Before an artifact can support a real engineering decision, we still need to know things like:
- What exactly is being claimed?
- Which operational scenario or context does it apply to?
- What evidence supports it?
- What assumptions are embedded in it?
- What trade-off or value criterion is being used?
- Who is responsible for approving, rejecting, executing, or reopening the decision?
- How does it connect to requirements, verification, and validation?
- What would cause us to hold, rollback, or escalate?
This seems to be where a lot of AI discussion becomes too shallow.
The hard part is not only generating more text, models, plans, or code. The hard part is turning those outputs into something that can survive engineering review, organizational accountability, and domain validation.
In other words, AI makes generation cheaper, but it does not remove the cost of judgment.
I do not think this is just a prompt engineering problem. It feels closer to a systems engineering problem:
How do we manage the state of knowledge around a system so that generated outputs, human claims, evidence, decisions, validation results, and operational feedback can be inspected together?
For example, suppose an AI assistant drafts a requirement or proposes a change. In a software-only workflow, we might ask:
“Does the diff pass the tests?”
But in a systems engineering workflow, that is not enough. We may also need to ask:
- Was the stakeholder need understood correctly?
- Is the operational scenario clear?
- Is this requirement actually approved?
- Is the verification method defined?
- Is the validation scenario defined?
- Is the AI agent or human implementer acting within an approved scope?
- Is there a rollback or reopen condition?
- Has the impact on neighboring requirements or interfaces been checked?
I am trying to understand whether this is a real gap in current systems engineering practice, or whether existing SE / MBSE / V&V methods already cover it well when applied properly.
One way I have been framing the issue is as “knowledge convergence”:
the process of turning generated outputs, human claims, documents, evidence, decisions, and operational feedback into a decision-ready knowledge state.
I have written an early draft/spec of this framing here, mainly to make the idea concrete enough to criticize:
https://github.com/sawadari/knowledge-convergence
Disclosure: this is my own early public work. It is not a mature standard, not a finished tool, and I am not selling anything. I am posting it here because I would especially like criticism from people who work with requirements, MBSE, verification/validation, safety, architecture decisions, or AI-assisted engineering workflows.
A few questions for this community:
Does “decision-ready knowledge state” describe a real problem you see in systems engineering work, or is there a better existing term for it?
Are existing SE / MBSE / V&V practices already enough to handle AI-generated artifacts, if applied properly?
Where would this framing break down in real engineering organizations?
What would be the smallest practical artifact that would make this useful: a decision ledger, a requirement-validation graph, an AI delegation envelope, lint rules for missing evidence, or something else?
I would appreciate blunt feedback. I am less interested in whether the terminology is perfect, and more interested in whether the underlying problem is real.
If the link makes this feel too self-promotional, I am happy to remove it and keep the discussion focused on the question.