Configuration & Traceability AI

One design. Forty serial numbers. Three decades of changes. Prove they match — that is the contract.

Every defence system exists in three truths at once. As-Designed: what the drawings and the Teamcenter BOM define, at exact revisions and baselines. As-Built: what was actually manufactured and delivered, per serial number, per vessel, per customer nation. As-Maintained: what stands in the field today, after refits, retrofits and modification programmes. STANAG 4427 and its ACMP framework — and behind them, your customers’ acceptance authorities — demand that these three truths stay reconcilable for the entire service life. Thirty to fifty years. Per unit.

The industry knows how hard that is: when a fleet gets consolidated onto a “new reference configuration” — the Leopard 2 A8 pattern — it is precisely because decades of divergence made the old baseline unmanageable. In daily practice the reconciliation runs on the most fragile tooling imaginable: experienced people, spreadsheets, and weeks of cross-checking between PLM, ERP build records and change paperwork whenever an audit or a customer question lands.

We automate the accounting layer underneath: AI and rules continuously compare As-Designed against As-Built and the change history, flag every gap and conflict with the evidence attached, assemble configuration status reports on demand — and answer “which serials does this change affect?” as a query instead of a research project. Inside your perimeter, on the sovereign stack. Your CM boards keep deciding; the machine keeps the books.

// Configuration reality, in numbers

0 truths

As-Designed, As-Built, As-Maintained — contractually required to stay reconcilable for decades

0k+

engineering changes over a platform's life — each one a chance for the truths to drift apart

wks per audit

of manual cross-checking between PLM, build records and change paperwork before every FCA/PCA

0 outbound

records leaving your perimeter — the accounting runs on the sovereign air-gapped stack

Configuration drift is silent — until the audit, or the incident

Nobody decides to let configurations drift. It happens one exception at a time: an approved change incorporated on serials 12 onwards but never back-annotated for the retrofit batch; a build deviation documented in a PDF that never reached the PLM; a country variant whose delta to the baseline lives in one programme manager’s head. Each is small. Compounded over ten thousand changes and forty serials, they become the state every CM manager knows and no one admits: the official records and the physical fleet disagree, and nobody can say exactly where.

The costs arrive in three forms. Audit findings — an FCA/PCA that surfaces inconsistencies you could have found first, with your acceptance authority watching. Operational risk — a refit planned against As-Designed data that doesn’t match the vessel that actually arrives in the yard. And pure effort: Configuration Status Accounting done by hand, weeks per audit, spreadsheets per fleet, and the constant background tax of answering “which configuration is unit X in?” from memory and folders.

The absurdity is that the evidence mostly exists — in Teamcenter revisions and effectivities, in ERP build records, in change documents, in acceptance protocols. It is scattered across systems that were never reconciled by machine. That reconciliation is exactly the kind of tireless, rule-governed cross-checking AI is built for — and exactly the kind humans are worst at sustaining for thirty years.

// Consistency check — S/N 0043, cooling system · run before the refit, not during it

1,842 record pairs compared · Teamcenter BOM ⟷ build records ⟷ change history · full report attached to the item

MATCH

CHK-0801 · Pump assembly: BOM rev E = build record rev E — effectivity consistent, 1,791 further characteristics in agreement

GAP

CHK-0834 · Piping section: build deviation noted in acceptance protocol (2011, PDF) — never captured as a change record in the PLM

CONFLICT

CHK-0847 · Valve block: As-Designed requires rev C — build record shows rev B installed

In plain language: The rev C change was approved and incorporated in the BOM, but S/N 0043 was in the retrofit batch and the incorporation was never confirmed. The vessel most likely still carries rev B. Prepared action: verification task for the next yard period, drafted with the evidence chain attached — for your CM board to release.

How the accounting layer works

The system does one thing relentlessly: connect the records that describe the same physical reality, and report where they disagree. It sits on top of your existing systems — it does not replace your PLM, your ERP or your CM process:

01 — CONNECT

The three truths, sourced

Teamcenter BOMs, revisions, effectivity
ERP / build records per serial
Change docs — digital and mined paper
Acceptance & maintenance protocols

02 — LINK

Same reality, one model

Parts ↔ changes ↔ serials ↔ platforms
Country variants as deltas to baseline
LLM extracts from unstructured docs
Every link keeps its source

03 — CHECK

Disagreements, found by machine

As-Designed ⟷ As-Built per serial
Approved-but-not-incorporated ECPs
Deviations missing from the PLM
MATCH / GAP / CONFLICT with evidence

04 — REPORT

CSA on demand — humans release

Config status reports, drafted
Audit evidence packs (FCA/PCA)
Fleet & ECP-impact queries
Your CM board decides — always

Four jobs the accounting layer does

Once the records are linked and continuously checked, four chronic pains become routine operations:

Audit preparation that finds findings first

Before every FCA/PCA, the consistency check runs fleet-wide: gaps and conflicts surface with evidence attached, verification tasks are drafted, and you walk into the audit with your own findings list — resolved or explained — instead of discovering it live.

Fleet configuration, queryable

"Which configuration is unit X actually in?" — answered from linked records, per serial, with the delta to baseline and every unincorporated change visible. Refits get planned against reality, not against hope.

ECP impact in minutes

A change is proposed: which serials, variants and platforms does it touch, what does it collide with, which prior changes does it depend on? The impact half of change management becomes a query — your board spends its time on the decision, not the research.

Legacy change history, recovered

Decades of paper ECRs, deviation sheets and acceptance protocols are mined into the structured history — the same pipeline as our drawing mining. The changes that only exist as scanned signatures finally enter the accounting.

Who this is for

You are a candidate if most of these apply:

You deliver or support systems under STANAG 4427 / ACMP-grade configuration management — with FCA/PCA audits and official acceptance.
Your fleet spans serial-number-level configurations — vessels built as individuals, vehicle batches, country variants.
Configuration Status Accounting runs on spreadsheets and veterans — and audit prep costs weeks, every time.
Part of the change history exists only as paper and scanned PDFs from earlier decades.
You run Teamcenter (or a comparable PLM) beside an ERP — and the two have never been reconciled by machine.
Your records are VS-NfD or export-controlled — the accounting must run inside your perimeter.

What the accounting layer is built on

Your systems stay the systems of record — the layer connects and checks, on infrastructure you control.

Teamcenter BOM / revision / effectivity ERP build records per serial LLM extraction from change docs Part–change–serial–platform linking Rule-based consistency checks CSA report generation Evidence packs with source links Legacy paper mining pipeline In-perimeter · sovereign stack

Before and after: six weeks to the PCA

The physical configuration audit for a vessel class is scheduled. Here is how the six weeks before it run, on each side of the change:

Before — the spreadsheet campaign

Task force assembled, programme work parked — 6 wks
PLM, ERP and binders reconciled by hand, serial by serial
Known problem areas quietly hoped past
The auditor finds the unincorporated ECP anyway — finding, action plan, follow-up audit
Next audit: same campaign, from zero

After — continuous accounting

Consistency state is known on day one — checks ran all year
Open GAPs and CONFLICTs carry drafted verification tasks — worked, not feared
Evidence packs generate per audit scope — hours
You present your own findings list, with resolutions — the audit becomes a review
The task force goes back to being engineers

Why inteliScience — and what the AI deliberately does not do

Configuration management is, at its data core, a Teamcenter discipline — revisions, effectivity, baselines, change objects — married to an ERP and buried under decades of documents. That combination is precisely our home ground: we build Teamcenter customizations on supported interfaces every day, and our document AI reads the unstructured half of your change history. No generic AI consultancy brings both; no CM tool vendor reads your 1994 deviation sheets.

The boundaries, stated plainly. The AI does not do configuration management. Your CM plan, your boards, your approvals remain process and people — the machine is the accounting layer underneath: it finds disagreements, drafts reports and verification tasks, and assembles evidence; it approves nothing and incorporates nothing. It does not paper over gaps. Where the As-Built documentation simply has holes, the system makes them visible and lists them — which, before an official audit, is exactly what you want: a known gap with a verification plan beats an unknown gap with an auditor’s flashlight on it. And because these records describe defence systems, the whole layer runs inside your perimeter, on the sovereign air-gapped stack, with markings honoured per user.

Fixed price — no day rates, no surprises

Configuration Accounting Pilot

€35,500 fixed

One system or platform family — As-Designed / As-Built sources connected inside your perimeter
Consistency check run across the available records — measured findings list (MATCH/GAP/CONFLICT)
Sample of legacy change documents mined into the structured history
CSA report and audit evidence-pack demo, reviewed with your CM team
Rollout blueprint: more platforms, continuous checking, audit calendar alignment

Start the pilot conversation

8–10 weeks · runs entirely on your infrastructure · findings and reports are yours, whatever you decide afterwards.

For comparison

The spreadsheet status quo

Weeks of task-force reconciliation before every audit, fleet-wide, by hand
Findings, action plans and follow-up audits for conflicts a machine finds in seconds
And the operational risk: refits planned against records the vessel doesn't match

Frequently asked questions

Does this replace our CM process or tools?

No — deliberately. Your CM plan, your change boards, your Teamcenter change objects and your approvals remain exactly what STANAG 4427 expects them to be: your process, run by your people. The AI is the accounting layer underneath — it cross-checks records that your process already produces, drafts reports your process already owes, and hands findings to the humans who decide. Nothing is approved, incorporated or closed by a machine.

Our As-Built documentation has real gaps. What happens then?

The gap becomes a listed, evidenced finding — never a silently interpolated record. That is a design principle: for systems that go to sea or to the field, a known gap with a drafted verification task (check on the next yard period, inspect at the next maintenance) is operationally and audit-wise far better than a confident guess. The first fleet-wide check can be worth the pilot alone, simply as an honest map of where your records actually stand.

How does the AI handle decades of paper change documents?

With the same mining pipeline as our legacy drawing offer: scanned ECRs, deviation sheets and acceptance protocols are extracted — change ID, affected parts, serials, approval signatures, dates — confidence-scored, human-reviewed where uncertain, and linked into the structured history. The changes that today exist only as filed signatures finally participate in the accounting. Where the paper itself is missing, see the previous answer: visible gap, not invented history.

Where does all this run? These records describe weapon systems.

Entirely inside your security perimeter, on the sovereign air-gapped stack — the same architecture as our defence engineering AI: no outbound routes, full audit logging, export-control and classification markings honoured per document and per user. Your security officer is welcome in the first meeting; the architecture is built to answer their questions.

Our fleet has drifted for 20 years. Isn't it too late for this?

The opposite — accumulated drift is where the accounting pays fastest, because the first check produces the honest map nobody has had for years: what matches, what gapped, what conflicts, ranked by operational relevance. That map is precisely what a re-baselining effort (the "new reference configuration" pattern the industry increasingly follows) needs as its day-one input. You don't clean twenty years by hand and then automate; you automate to make the twenty years cleanable.

Can we start with one system instead of the whole platform?

That is exactly what the pilot does: one system or platform family, the available As-Designed and As-Built sources connected, the consistency check run, and a measured findings list with your CM team reviewing the results. Scaling to further systems is then a decision based on your own numbers — and the audit calendar usually dictates the order.

Your next configuration audit is already on the calendar. Find your findings before the auditor does.

Pick one system whose records you trust least — we'll run the first consistency check on it, inside your perimeter, and review the map together.

Talk to a Configuration 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