NewDefence Engineering Assistant

Your team doubles every year. Your documentation doesn’t. Ask anyway — and get an answer with sources.

NewDefence companies have the opposite knowledge problem of the primes they compete with. No forty-year archives, no retirement wave — instead: speed debt. Three hardware iterations a year, decisions made in Slack threads and design reviews, knowledge scattered across Notion, Git, the PLM, test-campaign folders and the heads of the first twenty engineers. It works brilliantly at twenty people. At eighty, every new hire dilutes the context, the same questions get answered for the fifth time, and nobody can quickly say why the wing spar layup changed in v4 — even though the answer decided a flight test.

The standard startup fix — “just use ChatGPT on our docs” — is off the table the moment you work with defence customers: export control, classification, customer NDAs. Which is exactly why we build the assistant the sovereign way: it runs on your infrastructure or in an EU cloud under your control, indexes your scattered sources with permissions intact, and answers engineering questions with the source attached — the design review, the test report, the commit, the page.

Think of it as institutional memory for a company too young to have one — installed before the chaos compounds, not after.

// Hypergrowth knowledge debt, in numbers

0× / yr

team growth at scaling defence-tech companies — every cohort knows less context than the last

0+ tools

where engineering knowledge lives — CAD/PLM, Git, Notion, chat, test-campaign folders

of an engineer's day lost to searching and re-asking what the company already knows

0 outbound

documents or prompts leaving your control — sovereign by design, because defence customers check

Speed creates knowledge. Speed also loses it.

The strength of a NewDefence company is iteration velocity: design, build, fly, learn, repeat — in months, not years. But every iteration produces decisions, and decisions produce the questions that matter later. Why this layup? What did the v3 vibration campaign actually show? Which fastener standard did we settle on, and was that before or after the thermal issue? At prototype scale, the answers live in the room. At series scale — with a second product line, a military customer’s quality gates, and forty engineers who joined after the decision — the room is gone.

The symptoms are always the same: senior engineers spending hours a week re-answering onboarding questions; decisions re-litigated because their rationale is buried in a chat thread from two years ago; test knowledge locked in campaign folders nobody revisits; and the first military customer audit revealing that “we move fast” and “we can show why” are different capabilities.

The fix is not to slow down and write documentation like a prime — that would kill the advantage. The fix is to make the knowledge you already produce, in the tools you already use, answerable: index it where it lives, keep permissions intact, and let every engineer ask the company instead of the corridor.

// Illustrative example: assistant on the company's own scattered knowledge

Why did we change the wing spar layup between v3 and v4 — and is the rationale documented anywhere a customer auditor could see?

The layup changed after the v3 vibration campaign (TC-2025-09) showed resonance in the 40–45 Hz band at the outboard section; design review DR-141 approved the revised stack with two added ±45° plies, traded against 210 g of mass. The rationale exists in DR-141 and the campaign report — but note: the PLM change record references neither. For an audit-ready trail, that link should be added; a drafted cross-reference is prepared. Test campaign TC-2025-09 · §4Design review DR-141PLM change record: link missing

New here — which fastener standard do we use on the fuselage, and where's the torque table?

Fuselage primary structure uses works standard WS-007 rev B (settled in 2025 after the thermal-cycling issue — the history is in the linked thread, worth reading once). The torque table is §3 of WS-007; the shop-floor quick card lives in the assembly wiki. Heads-up for your first build: WS-007 explicitly does not apply to the payload bay — that's WS-011. WS-007 rev B · §3Decision thread 2025-03Assembly wiki · quick card

Built for the stack you actually have — not the one a prime has

No document migration project, no “first clean up your wiki” precondition. The assistant meets your knowledge where it already lives, and sovereignty is the default, not an upgrade:

01 — CONNECT

Your tools, as they are

CAD / PLM (NX, Teamcenter & co.)
Git repos & engineering docs
Notion / Confluence / wikis
Test-campaign folders & reports

02 — INDEX

Understood, permissions intact

Docs, threads, commits, reports
Decisions linked to their evidence
Access mirrored per user & marking
Updates flow in continuously

03 — ASK

Where your engineers live

Browser, IDE, chat — your choice
Plain language, your terminology
German & English
Answers in seconds

04 — ANSWER

Sourced, or not at all

Every claim cites its source
One click to the original
"Not found" instead of invention
Gaps flagged — audit debt visible

Four jobs the assistant does from day one

For a scaling defence-tech company, the assistant earns its keep in four recurring situations:

Onboarding at hiring speed

Every new engineer asks the assistant the hundred context questions — standards, conventions, "why do we do it this way" — instead of taxing the founding engineers. The cohort that joins at 80 people gets the context the cohort at 20 absorbed by osmosis.

Iteration history, preserved

"What changed between v3 and v4, and why?" — answered from design reviews, change records and campaign reports, with sources. Decisions stop being re-litigated, and lessons from flown hardware stay learned.

Test knowledge, unlocked

Campaign reports and telemetry summaries become queryable: which configurations showed the resonance, what did the environmental tests clear, which failures repeat. The most expensive knowledge you produce stops retiring into folders.

Audit-readiness as a side effect

Military customers will ask for the trail behind decisions. The assistant not only finds it — it flags where links are missing while they're still cheap to fix. Traceability debt becomes visible years before it becomes a finding.

Who this is for

You are a candidate if most of these apply:

You build drones, munitions, space or defence-tech hardware — and iterate in months, not years.
The team has doubled (or will) — and onboarding runs on the founding engineers’ calendars.
Engineering knowledge is spread across five-plus tools: CAD/PLM, Git, wikis, chat, test folders.
Decision rationale lives in threads and heads — and gets re-litigated when the author is unavailable.
Defence customers bring export control, classification and audit expectations — public cloud AI is not an option.
You want this running in weeks, not as a six-month documentation programme.

What the assistant connects to

The real stack of a scaling defence-tech company — permissions mirrored, sovereignty default.

NX / Teamcenter / your PLM Git repos & design docs Notion / Confluence / wikis Test campaigns & reports Decision threads (curated) Works standards as they form SSO & permission mirroring Export-control markings respected On-prem / EU cloud under your control

Before and after: engineer #85 joins

Your newest hire starts on a Monday — mechanical engineer, sharp, zero context. Here is their first month, on each side of the change:

Before — osmosis at scale

Every question interrupts a senior — or waits for one
Standards found by asking three people and getting two answers
Old decisions look arbitrary — so they get "improved" and old failures return
Productive after months — multiplied by every hire in the cohort

After — the company answers

Context questions answered in seconds — sources attached, seniors uninterrupted
Standards come with their history and their exceptions
The "why" behind v4 is one question away — lessons stay learned
Productive in weeks — and the seniors build product instead of repeating context

Why inteliScience

Two things distinguish this from “RAG startup number forty”. First, we come from the engineering side: we build on the Siemens NX and Teamcenter stack daily, we understand what a design review, a change record and a test campaign actually are — so the assistant treats them as linked engineering objects, not as generic documents. Second, we come from the defence side of AI: sovereign, air-gapped deployments are our default architecture, not a roadmap item — which matters the day your customer’s security questionnaire arrives, and that day always arrives.

The honest boundary: the assistant makes scattered knowledge answerable — it does not write the knowledge for you. If a decision was never captured anywhere, no AI can retrieve it; what the assistant does instead is flag the gap while the people who remember are still in the building, which for a young company is the cheapest documentation programme there is. And answers are grounded or absent: every claim cites its source, and “not found in the connected sources” is an answer we consider a feature.

Fixed price — no day rates, no surprises

NewDefence Assistant as NX Sprint Plus

€16,900 fixed

2–3 knowledge sources connected (e.g. wiki + PLM area + test-campaign folder)
Deployed on your infrastructure or EU cloud under your control — sovereign from day one
Evaluation on 100 real questions from your engineers — grounded-answer rate measured
Gap report: where decision rationale is missing — while it's still cheap to capture
Rollout blueprint: more sources, permissions at scale, air-gap path if customers require it

Start the pilot conversation

4 weeks · startup pace, fixed scope · you decide afterwards, without obligation.

For comparison

The cost of osmosis

Founding engineers spending days per week as human onboarding manuals
Months-long ramp per hire, multiplied by a doubling headcount
And the expensive one: flown lessons re-learned on the next iteration

Frequently asked questions

Why not just ChatGPT Enterprise or Copilot on our docs?

Three reasons, in ascending order of severity. Generic tools treat your engineering knowledge as flat documents — they don't understand that a design review, a change record and a test campaign are linked objects, which is where the useful answers live. They don't mirror your permissions and export-control markings per user. And most decisively: the day your defence customer's security questionnaire asks where prompts and documents are processed, "a US cloud service" ends the conversation. Sovereign deployment is not a nice-to-have in this market — it's the ticket to play.

Our documentation is honestly a mess. Doesn't that break RAG?

A mess with substance beats a clean void — and scaling startups have substance: design reviews, test reports, commits, threads. The assistant works on that reality, and its gap report shows you precisely where rationale was never captured, ranked by how often people ask about it. That turns "we should document more" from guilt into a shortlist — and captures it while the people who remember are still there. You don't clean up to deploy the assistant; you deploy the assistant to know what's worth cleaning up.

What stops it from inventing answers?

The assistant answers only from retrieved passages in your connected sources; every claim carries a citation your engineer can open; and when nothing solid is found, it says "not found" and lists the closest matches. In the pilot we measure the grounded-answer rate on 100 real questions — including deliberately unanswerable ones, because for hardware that flies, "knows when it doesn't know" is the property that matters most.

Do we need on-prem GPUs, or does EU cloud work?

Both paths work, and the honest answer depends on your customer mix. An EU cloud environment under your control is where most defence-tech companies start — fast, no hardware procurement, contractually clean for most current programmes. Fully air-gapped on-prem is the endgame once classified work arrives, and the architecture is built so that migration is a move, not a rebuild. The pilot's rollout blueprint maps that path against your actual customer requirements.

Can it read our Git repos and test data, not just wiki pages?

Yes — that's the point for an engineering company. Git READMEs, design docs in repos and commit context; test-campaign reports and structured summaries of results; PLM items and change records; wikis and curated decision threads. What we deliberately don't index is raw noise (full chat history, raw telemetry) — the pilot's source selection is a curation decision we make with you, because answer quality follows source quality.

We're 40 people. Is this overkill?

Forty is arguably the best moment: enough knowledge to be worth indexing, few enough sources that setup is quick, and the doubling that makes it indispensable is still ahead of you. Installed now, every future hire onboards against it and every decision gets captured into it — installed at 150, you'll be reconstructing two years of context instead. The four-week NX Sprint Plus is deliberately sized so a company your size can just do it.

You're hiring twenty engineers this year. Give them the context of the first twenty.

Bring the ten questions your founding engineers answer every week — we'll show you the assistant answering them from your own tools, with sources, in a four-week NX Sprint Plus.

Talk to a Knowledge AI Engineer

Always here to support you – reach out to us with your questions, and we’ll guide you every step of the way.

Phone: +40 774 463 429
Our Location: Str. Ploiești 9, 400157
Cluj-Napoca, Romania
Email: info@inteliscience.net
LinkedIn: inteliScience on LinkedIn
YouTube: inteliScience on YouTube