From demonstration to decision: six questions about defence validation
Two anonymised MSSG projects show why sensor software and an interceptor need different evidence, partners and market-entry milestones.
- Product validation
- Evidence · conditions · limits
A successful demonstration shows what happened on that occasion. Understanding what it establishes requires context. MSSG uses the following questions when examining defence-technology claims.
Which version was tested? Who operated it? Under what conditions? How many attempts were made, including unsuccessful ones? What changed after the test? How will training, repairs and replacements work?
The answers help separate a repeatable capability from a result that still needs testing. They expose practical dependencies that a specification sheet may not explain.
For technology intended for Ukraine, support matters alongside performance. An operator needs to learn the system, obtain spares and return equipment to service. These are assessment questions, not an assessment of a specific supplier.
1. What problem does the product actually solve?
In MSSG’s published case, one company developed software for identifying unreliable sensor data and another an interceptor. The software project narrowed its focus to platforms heavily dependent on cameras, optics or radar. A proposition for autonomous systems in general did not identify the most credible customer.
This article draws on MSSG’s own work; MSSG publishes the portal. The companies remain anonymous. The account does not mean every product claim was validated or that contracts were secured.
2. What has been shown, and what remains planned?
The team separated demonstrated functions, simulation results and capabilities requiring further integration. Commercial language needed to match the actual stage. Evidence for one module should not become a claim of complete-product validation.
A useful demonstration question is therefore which version is being shown and what result can be assessed. The answer defines the scope without inventing tests that have not occurred.
3. Who needs the function?
For the software project, attention focused on expensive reusable platforms where unreliable data could have significant consequences. The case describes market focus, not a signed contract. Customer selection followed the value of solving a particular problem.
The interceptor required different counterparts and evidence. Its market assessment included the complete system, support, integration and supply scale. Two defence-tech products need not follow the same commercial route.
4. What does integration depend on?
MSSG examined which functions depended on other systems and which partners were needed at each stage. The published account includes manufacturers, integrators, users and institutions. Their identities and detailed configurations are not disclosed.
Responsibility matters: what is supplied by the component vendor and what must come from the host platform? If a result depends on another company’s data or interface, a standalone demonstration does not settle that dependency.
5. What enables a lawful delivery?
The case considered export controls, licences, certification, codification and the legal form of cooperation. These are separate subjects rather than interchangeable terms or a single document. Requirements depend on product and transaction; the public account does not provide a universal regulatory procedure.
Market planning needs ownership and scheduling for those issues. A promising technology may still require work before it can be delivered to a particular customer.
6. Which next result would change the decision?
The work produced credible initial uses, missing-evidence lists, priority partners and milestones. Investor and commercial materials were also revised to remove unsupported statements. This is not described as completed military adoption.
A useful next stage resolves a defined uncertainty about function, integration, users or delivery. That makes a demonstration part of a decision process rather than a repeatedly staged presentation.
Sources & context
Published by Mitchell Strategic Solutions Group. See our editorial standards and corrections policy. Read more →
