When an obstacle of 10 mm or more is detected during closing, the door shall stop and reopen fully within 0.5 s, then retry closing up to 3 times before alerting the driver.
In Xray: 1 of 4 test procedures (25%). Missing ones are proposed designs.
Tests present
1
Tests missing
3
Test procedures 1/4PresentNot presentP0P1
LR-TC-022-01P0Door reopens within 0.5 s on a 10 mm obstacleXrayPresent
LR-TC-022-NEW-01P0Door keeps closing on a 9 mm obstacleNot present
LR-TC-022-NEW-02P1Door fully reopened at exactly 0.5 sNot present
LR-TC-022-NEW-03P1Driver alerted after the third failed closingNot present
The problem
Development got faster. Requirements didn't.
The bottleneck moved. Writing the feature is no longer the hard part. Knowing it does exactly what you meant is.
Your spec hides inconsistenciesQ1 · inconsistenciesTwo requirements that each make sense, but cannot both be true.Q1, ambiguitiesQ2 · ambiguitiesWording like “fast” or “large” that two teams will build two different ways.Q2, conflicting constraintsQ3 · conflicting constraintsFunctional and non-functional demands that cannot all be met at once.Q3, unstated assumptionsQ4 · unstated assumptionsReferences to a concept or behaviour the spec never defines.Q4 and missing edge casesQ5 · missing edge casesFailures, limits and concurrent use that the happy path leaves out.Q5.
Example: the questions KomAInu raises on a spec page
SRS v4.2 · Flight control5 open questions
REQ-112
Warning alerts shall be shown in redQ1.
Q1 · InconsistencyREQ-109 says amber. Which one?
REQ-118
The system shall respond fastQ2.
Q2 · AmbiguityHow fast? 50 ms? 200 ms?
REQ-140
Trim shall correct itself automatically, after pilot approvalQ3.
Q3 · ConflictAutomatic, or approved?
REQ-151
Alerts shall follow the standard policyQ4.
Q4 · AssumptionWhich standard?
REQ-163
The pilot shall be able to reset the alertQ5.
Q5 · Edge caseWhat if the fault returns mid-reset?
01
Rework after the code
The flaw surfaces once the feature is built. Now it costs a rewrite, not a sentence.
02
Green tests, wrong behaviour
Tests check what someone assumed the requirement meant. The suite passes, the product is wrong.
03
Findings at audit
The auditor finds what the review missed, at the point where fixing it costs the most.
How it works
Between your requirements and your tests.
No migration. Your specs and your tests stay in the tools you already use. KomAInu Enterprise works across all of them at once: it challenges each requirement, defines the test cases it needs and compares them with the tests you already have. An ALM's built-in AI reviews requirements inside that one tool; KomAInu checks that each one is tested.
Use KomAInu on an existing project, or prepare tests for TDDTDD · Test-driven developmentWrite the test first, then the code that makes it pass. The requirement decides what done means., ATDDATDD · Acceptance test-driven developmentAgree on acceptance criteria and turn them into tests before implementation, so everyone shares the same definition of done. or AIDDAIDD · AI-driven developmentAI agents write the code, and the tests decide when it is done. with our MCPMCP · Model Context ProtocolThe open standard that lets AI agents such as Claude or Cursor use outside tools. Ours hands them your requirements and tests. server.
1. Challenge each requirement until it is testable
2. Generate the test cases it needs
3. Compare with the tests you already have, flag false positives and check each test against its acceptance criteria
Engineers keep the final word. Human-in-the-loop by design: every proposed rewording and every test waits for your approval before it enters your project record.
Add missing tests Read existing tests
Your tests & CI
Test archive (.zip)
Xray
GitHub
Jenkins
Audit-ready traceability matrix
Every requirement linked to its tests, every decision logged. Gaps shown as present or missing, never guessed.
Who it is for
Built for the engineers who sign off on the spec.
Each role sees what it has to sign off, from the first draft of the spec to the evidence for the auditor.
Systems engineers01
Requirements engineers · System architects
Write requirements that hold up.
KomAInu checks every requirement for ambiguity, incompleteness and inconsistency, and asks the question that settles each one.
One requirement, or all of them. Start where you are.
Test the method on one requirement today, free, with KomAInu Individual. When your team has to prove coverage across a whole project, move to KomAInu Enterprise.
01 · For one engineer · Free
KomAInu Individual
Find what your requirement is missing before it costs you a rewrite.
What you get
Drop in your specs as they are
Every requirement extracted and numbered for you
Catch the ambiguities before your reviewer does
Same input, same test cases, every time: ready to review
Measured, not claimed. Open benchmarks, documented setups.
A controlled benchmark puts KomAInu against the published reference method and a frontier model. The setup behind each number is documented.
TraceFuse benchmark
Better requirement-to-test links,on a model 15× cheaper.
KomAInu's traceability engine ranks the right requirement-to-test links higher than the ICSE 2024 reference method and Claude Opus (average precision, AP), while running on a model priced about 15× lower.
Two ways to run KomAInu: in our EU cloud, or deployed on your premises, air-gapped if needed. Every output is reviewed by an engineer before it enters your project record.
Security
Your data stays yours
In our cloud, your data is processed in the EU, on Google Cloud servers in Belgium. On your premises, nothing leaves your network.
Deployment
Our cloud or yours
Our cloud, with models hosted on Google Cloud in Belgium, or deployed on your premises by our teams, with your own models, air-gapped if needed.
Integrations
Keep your stack
Requirements stay in DOORS, Jazz, Polarion, Jira or Linear. Tests stay in Xray, GitHub, Jenkins or an archive.
Audit
Auditable by design
Every requirement linked to its tests, every decision approved by an engineer and logged.
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
DCU-SYS-031The train shall not depart until all doors are closed and locked.3 tests
DCU-SYS-047The driver shall be alerted when a door fails to lock.0 tests
DCU-SYS-052Door closing force shall not exceed the limit set in the passenger safety spec.1 tests
FAQ
Questions, answered.
What does KomAInu do?
KomAInu checks that every requirement is clear and tested. It reads your specs, challenges each requirement until it is testable (ambiguities, conflicts, missing edge cases, unstated assumptions), writes the test cases it needs, and compares them with the tests you already have to flag the missing, weak or false-positive ones. The result is a requirements-to-tests traceability matrix where every gap is shown as present or missing, never guessed. Engineers approve every proposed rewording and every test. KomAInu Individual does this for one engineer, free; KomAInu Enterprise does it for a whole team and project, connected to your ALM and test tools.
Where is KomAInu from?
KomAInu is a French company founded in Paris in July 2026. Its registered office is at 173 rue de Courcelles, 75017 Paris, and the team works from STATION F. It was founded by three engineers: Pierre Lammers, Benjamin Chollet and Sven Juge.
How do we get started?
Two ways. Try KomAInu Individual for free, today, on your own specs: no demo, no setup. When your team needs coverage and traceability across a whole project, talk to us about KomAInu Enterprise. For Enterprise, we start with a real verification bottleneck and determine together whether KomAInu fits the workflow, toolchain, deployment constraints, and review process. Pricing is scoped for each engagement rather than published as a fixed package.
What is the difference between KomAInu Individual and KomAInu Enterprise?
KomAInu Individual is free, for one engineer, in its own web interface. You drop in your specs, KomAInu extracts every requirement, challenges each one, and writes the same test cases every time, ready to export as CSV. KomAInu Enterprise includes everything in Individual, for the whole team and the whole project. It connects to your ALM and test tools, flags every missing, weak or false-positive test, keeps a requirements-to-tests traceability matrix ready for the auditor, and runs in our EU cloud or on your premises, air-gapped if needed, with dedicated support.
What happens in the first conversation?
You speak directly with the founders for 30 minutes about one concrete V&V bottleneck, the tools and artifacts involved, and any data or deployment constraints. The goal is to decide whether KomAInu is relevant to your environment. No preparation is required, and if there is a fit, the next step and commercial scope are defined with you.
How is sensitive engineering data handled?
KomAInu runs in two ways. In our cloud, your requirements, tests and documents are processed in the EU, with models hosted on Google Cloud in Belgium. Otherwise, our teams deploy KomAInu on your premises, with the models you already run or a local model, air-gapped if needed, so nothing leaves your network. We check which one fits your project in the first conversation.
Which AI models does KomAInu work with?
KomAInu can work with private or open source models deployed in your own environment, including model families such as Mistral, Qwen, and similar models that you can host yourself. The choice depends on the accuracy, latency, cost, and security profile your project requires. The important point is that the model is not the product boundary. KomAInu provides the traceability workflow, retrieval context, scoring, evidence structure, and review process around the model, so the solution can be tuned to your needs instead of forcing every team into the same hosted AI setup.
Can KomAInu adapt to our workflow and standards?
Yes. KomAInu is designed to adapt to your project rather than replace your whole V&V process. We configure the solution around your standards, your requirements format, your test repositories, your ALM, and the way your team reviews and approves evidence. For example, one team may need traceability from requirements to tests for a certification audit, another may need coverage analysis, and another may need requirement reviews before a baseline. The underlying platform stays the same, but the workflow, connectors, review gates, and outputs are adapted to the certification or compliance problem you actually need to solve.
Does KomAInu integrate with ALM and existing tools?
KomAInu is built to sit on top of existing engineering and ALM workflows. It can read requirements, tests, code, documentation, and traceability artifacts, then suggest corrections, generate missing test material, and keep the traceability view current after human review. The goal is not to make teams rebuild their process from scratch. KomAInu connects the audit, remediation, and prevention loop around the tools already used by the project, so approved changes can flow back into the ALM or repository while the existing system of record remains in place.
Can KomAInu's output be used in a certification file?
KomAInu works human-in-the-loop: every reworded requirement and every test it proposes is reviewed and approved by an engineer before it enters your project record. It supports your verification process; it does not replace it or sign off on its own. KomAInu is not a qualified tool under DO-330, and it does not need to be: like a colleague's work, everything it proposes is reviewed and approved by your engineers.
Does KomAInu replace engineers?
No. KomAInu is built as an engineering assistant for regulated software, not as an automatic certification authority. It detects gaps, proposes tests, suggests corrections, and updates traceability, but engineers remain in control of what is accepted. That human review gate is important because safety-critical verification still depends on engineering judgement. KomAInu reduces the manual search and documentation effort, surfaces the risky inconsistencies earlier, and prepares evidence, while your team validates the output before it becomes part of the official project record.