The named outcome on the European land-systems program, cited publicly by the customer: 20% faster time-to-market, +5% revenue uplift. The +5% is the part to read carefully. It is not from closing more deals per attempt. It is from being able to attempt more deals.
SPREAD's deployment is Requirements Manager at the air-defense business unit, with a multi-product expansion under way at the electronics business unit. The graph ingests the customer's portfolio of validated solutions from previous European land-systems programs, matches new RFQ (request for quotation) requirements against that portfolio with confidence scoring, and returns evaluable candidates rather than search results.
Why NATO procurement runs on a different logic
The defense procurement environment European primes operate in does not reward speed for its own sake. NATO procurement cycles are set by national governments and multilateral programs, not by the bidder. The volume of RFQs a prime answers in a year does not go up because the prime gets faster.
What does go up, when an engineering ontology lands well, is the fraction of RFQs the prime can answer credibly. Each RFQ runs into thousands of requirements; each requirement triggers the same scope question; each scope question lands at the desk of a senior engineer who has been doing this work for two decades. The senior engineer is the constraint, not the procurement cadence.
What used to land at the senior engineer's desk
A new European land-systems program RFQ, multiple thousand requirements long. The senior engineer's job, pre-Requirements-Manager, was a search-and-synthesize exercise: read the RFQ PDFs, walk the ReqIFs (Requirements Interchange Format files), cross-reference prior program records, re-derive effort estimates from scratch. Days to weeks per RFQ. Per program.
That is the bid-response cost line that does not show up cleanly on financial statements. It shows up as senior-engineer scarcity. It shows up as RFQs the prime declines to bid on because the bid-response capacity is full. It shows up as a +5% revenue uplift, not because the customer closes more deals per attempt, but because the customer attempts more deals.
What changes for the bid engineer
- Read the RFQ PDF (thousands of requirements)
- Walk ReqIFs and prior program records
- Hunt through validated solutions in tribal knowledge
- Re-derive effort estimates from scratch
- Synthesize the bid response under senior-engineer scarcity
- Graph auto-matches new requirements against the portfolio
- Candidates returned with confidence scores attached
- Engineer evaluates the surfaced matches
- Senior judgment routed to genuinely new content
The shift in the question itself is the part that matters and is easy to miss. Pre-Requirements-Manager, the bid engineer's question was: "What do we have that covers this requirement?" The engineer hunted across documentation for the answer. Post-Requirements-Manager, the bid engineer's question is: "Is this graph match the right one?" The engineer evaluates the candidates the graph has surfaced.
These look similar. They are operationally different. The first is a search problem; the second is an evaluation problem. The first scales badly with senior-engineer scarcity; the second scales well, because evaluation is what senior engineers are uniquely good at and what should be reserved for them.
The value math behind the figures
Industry-benchmark cost of a senior German defense systems engineer in 2025–26 sits around €110–150 per hour fully loaded. A typical European land-systems RFQ produces several thousand requirements; senior engineering effort to scope a single bid runs in the order of 200–500 person-hours pre-Requirements-Manager.
The 20% time-to-market improvement and +5% revenue uplift are the rolled-up program-level outcomes; the per-RFQ math is what those numbers compound from.
The customer voice
The customer's Chief Innovation Officer, on the trajectory:
"It's great you can access lots of engineering knowledge instantly. At the customer, we will make product knowledge available to everyone when, where and how they need it with a digital product twin. SPREAD's AI solutions turn siloed data into business value."Chief Innovation Officer · European Defense Land-Systems Prime
The named program is finished and quotable; broader expansion is in flight at the electronics business unit.
The multi-entity footprint
The customer is not one account. Two business units each carry their own engagement profile.
- Air-defense business unit: the live Requirements Manager deployment, processing RFQs that include the publicly named European land-systems program.
- Electronics business unit: a multi-product expansion under way around Product Explorer and E/E Inspector, extending beyond RFQ scoping into the engineering data the electronics team owns.
Why this is a category, not a productivity story
The temptation when describing Requirements Manager is to frame it in productivity terms: engineers work faster, more bids get out the door. That is true. It is not the most useful framing for defense procurement.
What the customer demonstrates is that the bottleneck on credible engagement at NATO scale is senior-engineer time, not procurement-process time. Shifting senior-engineer attention from search to evaluation expands the prime's effective bid capacity without requiring more senior engineers, which is the only way the math works in a market where senior defense systems engineers cannot be hired at the rate the procurement cadence is accelerating.
The 20% / +5% / weeks-to-days numbers are what that shift produces.
Program shape
| Program | European land-systems (cross-customer) |
|---|---|
| Time-to-market improvement | 20% faster |
| Revenue uplift (more bids attempted) | +5% |
| RFQ scoping cycle | Weeks → days |
| Per-RFQ engineering cost recovered | €20–60k |
| Multi-product expansion (electronics business unit) | Product Explorer + E/E Inspector |
| Customer voice | Chief Innovation Officer |