KomAInu Individual
Drop in a spec and start on your own requirements today. No demo, no setup.
See KomAInu IndividualWrite requirements that hold up.
KomAInu checks every requirement for the three flaws that sink a spec, and asks the question that settles each one before anyone builds on it.
- REQ-112
Warning alerts shall be shown in redQ1.
REQ-109 says amber. Which one?
- REQ-118
The system shall respond fastQ2.
How fast? 50 ms? 200 ms?
- REQ-140
Trim shall correct itself automatically, after pilot approvalQ3.
Automatic, or approved?
- REQ-151
Alerts shall follow the standard policyQ4.
Which standard?
- REQ-163
The pilot shall be able to reset the alertQ5.
What if the fault returns mid-reset?
One sentence, two readings, six months of rework.
Your designer, your tester and your supplier all read the same sentence. Each one understands something different, and each one is sure they read it right.
Nobody notices, because everyone agrees on the words. The design follows one reading, the tests another, the supplier a third.
The gap only shows in qualification, when fixing it means rework across every team, a slipped milestone and a certification file to reopen.
Settle it now, not in qualification.
Ambiguities flagged as you write.
Vague terms, missing units, untestable wording: every ambiguity pointed out in the sentence where it sits.
Inconsistencies and gaps surfaced.
Requirements that contradict each other, and the cases nobody specified: inconsistencies and incompleteness found across the whole document.
Questions, not a rewrite.
KomAInu asks the question that settles each issue, then proposes a reworded version, clear enough for every team to read the same way. Your requirement stays yours.
A spec your test team can test.
Every requirement leaves with clear acceptance criteria, so verification starts from what you meant.
Start alone, or bring the whole team.
KomAInu Enterprise
Connected to your tools, in our EU cloud or on your premises, air-gapped if needed.
See KomAInu EnterpriseForward Deployed Engineering
We install the models on your infrastructure and build the workflow you need.
See Forward Deployed Engineering
Where systems engineers start.
- Review a specification before baseline.
- Check a change request against existing requirements.
- Align supplier and customer requirements.
- Prepare a requirements review.
What makes it different.
Deterministic
The same results on every run, so every output can be reviewed and audited.
Human in the loop
Nothing is approved without an engineer. KomAInu proposes, you decide.
Fits your workflow
DOORS, Polarion, Jira, Xray, GitHub: it plugs into the tools you already use.
Your data stays in Europe
European company, hosted in the EU, or on your premises and air-gapped.
Built by critical-software engineers
Made by software engineers who shipped critical software under DO-178C.
Questions from systems engineers.
What is AI requirements review?
It is an automated first pass over a specification: each requirement is checked for ambiguity, testability, completeness and conflicts with the others, and every finding comes with the question that settles it. An engineer still decides what to change.
Does KomAInu rewrite my requirements?
No. KomAInu never changes your requirement. It proposes a reworded version, built from your answers, that every team reads the same way. You decide whether to adopt it, so the wording and the responsibility stay with you.
Does it follow INCOSE requirement-writing rules?
The checks cover the issues the INCOSE Guide for Writing Requirements targets, such as vague terms, missing conditions, combined requirements and untestable wording.
Does it work with DOORS or Polarion?
Yes. Requirements can stay in IBM DOORS, DOORS Next, Polarion, Jira or Linear. KomAInu Enterprise connects to them, so there is no migration.
How is it different from a manual peer review?
A peer review depends on who reads and how much time they have. KomAInu reads every requirement with the same checks, every time, so reviewers can spend their time on the decisions instead of the hunt.
Is my specification kept confidential?
Yes. KomAInu Individual runs in our EU cloud. KomAInu Enterprise can run in the EU, on your premises or fully air-gapped.
Why requirements traceability pays off
One spec, one reading. Try it on yours.
Drop in a real specification and see the ambiguities, conflicts and missing cases KomAInu finds in minutes.
Lumen Rail › Door control
Dashboard
78%
covered
Covered115
Partial21
Uncovered12
Tests linked
212
Tests missing
33
Requirements 148
- DCU-SYS-014The door control unit shall prevent door opening while train speed is above 3 km/h.4 tests
- DCU-SYS-022The doors shall reopen when an obstacle is detected during closing.1 tests