The same SPREAD architecture is already running in production at a peer European land-systems prime: on-premise, four national jurisdictions, audit-grade need-to-know access controls layered into the data model itself. The engagement at the merged French-German prime is the second instance of that working pattern, applied to a multi-variant armored-vehicle platform (command, ambulance, infantry, heavy weapons) deployed across Germany, the Netherlands, the UK, Australia, Lithuania, and Algeria.
The customer's IT architect framed the entry test in one sentence:
"Jetzt kommt die Killerfrage: Wie ist Ihre Berechtigungsverwaltung? Bauen Sie Datalegs? Sie zapfen ja diverse Program an. Ich möchte verstehen, was Sie wie anzapfen. Ich möchte verstehen, was wer überhaupt sehen darf."
(Now comes the killer question: How is your authorization management? Are you building data lakes? You're tapping into various programs. I want to understand what you're accessing and how. I want to understand who is even allowed to see what.)IT architect · European Land-Systems Prime
That answer is not a roadmap promise. It is the architecture already in production at the peer prime.
Why this is the second instance, not a first-of-its-kind pilot
The peer European land-systems prime already runs the SPREAD architecture in production. On-premise, behind the customer's firewall, across four national defense procurement authorities, with audit-grade need-to-know access controls layered into the data model itself rather than bolted on at the application surface. That deployment is the existence proof: the structural answer to the killer question already exists and is being audited day-to-day.
The customer in this engagement is a merged French-German defense prime at roughly EUR 3.4B revenue and 11,000 employees, sitting behind the multi-variant armored-vehicle program, an additional main battle tank program, and a portfolio of land-systems variants serving NATO and allied procurement. Each new variant or international customer triggers a program-specific RFQ (request for quotation) where requirements have to be evaluated against the existing platform portfolio: which prior validations apply, which variants need delta engineering, which historical configurations the new customer can inherit.
That bid-side workflow is exactly what Requirements Manager addresses, and exactly the workflow already running at the peer prime. The customer's engineering lead framed the local pain:
"Der Vorgang selbst ist sehr personal- und zeitintensiv und tatsächlich auch anfällig für Fehler. Die Datenlage ist verteilt, abgelegt, ich hab hier Excel-Listen, ich hab Datenbanken, manche Sachen sind in Doors. Anderes Wissen steckt tatsächlich nur in den Köpfen von gewissen Personen."
(The process is personnel- and time-intensive, and actually error-prone. The data is distributed, Excel lists, databases, some things in DOORS (IBM Rational DOORS, a requirements tool). Other knowledge exists only in people's heads.)Engineering lead · European Land-Systems Prime
The standard defense-engineering pattern: documented data fragmented across heterogeneous tools, plus tribal knowledge that lives in individual engineers' memory. The same pattern, the same four-source shape, is what the peer-prime production deployment already collapses into a single auditable graph.
The dashed-border tribal knowledge box is the structurally hard one. The other three are documented; the fourth lives in heads. The graph's job is to consolidate all four, and the Requirements Manager pilot delivers when the fourth source becomes queryable alongside the first three.
Why the killer question already has an answer
The IT-architect quote above is the entry test for any platform that touches defense engineering data. Berechtigungsverwaltung (need-to-know access management) is not a per-account ask. It is the structural precondition for any defense-vertical deployment.
The peer European land-systems prime is the existence proof. On-premise. Four national jurisdictions. Audit-grade access controls layered into the data model itself, not the application surface. In production today. The merged French-German prime runs the same architecture against its own compartmentalization, the architecture already proven at the peer prime.
What the bid query looks like in practice
For an international-customer evaluation, the bid engineer's question takes shape something like:
"Which variants in the active portfolio have CBRN protection at this threat level? What was the implementation, and what validation history exists?"
Today, the answer requires a senior engineer to walk Excel program trackers, DOORS requirement records, validation databases, and the head of whoever happens to know the historical platform variants. The graph answers across all four sources without the engineer seeing the silos, and respects the access controls the IT architect raised as the killer question.
The shape of regulated bid-side analytical platforms
The category most analytical platforms operate in assumes that more data, more visible to more people, is better. Defense engineering inverts that assumption. More data, more visible to more people, is a compliance failure.
Those two postures don't actually conflict. A graph that represents the cross-variant validation matrix abstractly, without revealing the substantive content of any classified field to any user not cleared to see it, is still answering the bid engineer's question. The matrix exists; the engineer queries it; the graph returns the candidate variants visible at the engineer's clearance level, with the access state attached.
That shape, on-premise topology, jurisdiction-aware audit, role-based and need-to-know access controls layered into the data model itself, is a different category of analytical platform than the cloud-native, share-everything default of the broader B2B software market. It is also the shape every regulated industry will eventually need.
What this engagement turns on
Two things, structurally:
- The existence proof, in production, at a peer prime. On-premise. Four national jurisdictions. Audit-grade access controls layered into the data model itself, not the application surface. That deployment is being audited and operated day-to-day; the customer in this engagement runs the same shape against its own compartmentalization.
- A verifiable result inside a defensible scope. The deployment is scoped tight on purpose: a graph-query result on the platform's requirements that a senior engineer can audit end-to-end inside the customer's perimeter is the proof point that generalizes.
Program shape
| Engagement shape | Second instance · bid-side Requirements Manager on a multi-variant armored-vehicle platform |
|---|---|
| Platform footprint | Six national customers (DE · NL · UK · AU · LT · DZ) |
| Variants in scope | Command · ambulance · infantry · heavy weapons |
| Fragmented data sources | Excel · databases · DOORS · tribal knowledge in engineers' heads |
| Deployment model | On-premise, behind the customer's firewall |
| Structural gating concern | Need-to-know access management (Berechtigungsverwaltung) |
| First instance (in production) | Peer European land-systems prime · on-premise · 4 national jurisdictions · audit-grade need-to-know access in the data model |
| Customer voices | Engineering lead · IT architect |