Engineering Knowledge Assistant: the EKA AI assistant on your development knowledge

An engineering organisation's knowledge is scattered across Confluence, DOORS, Jira and SharePoint. We build the EKA assistant, which answers everyday engineering questions directly and cites its sources for every answer – and stays silent when the evidence is too thin.

The situation

Searching happens system by system, finding often not at all: an engineering organisation's documentation landscape has grown over years, and SharePoint does not know what Confluence holds. Existing knowledge is worked out anew, and new colleagues need months to find their way around.

An assistant that answers across all sources is only usable if it guarantees two things: it never shows anyone content they could not see in the source system, and it backs every answer with its source.

Typical data basis

Confluence pages, SharePoint libraries and network drive documents. Requirements from DOORS, tickets from Jira. Requirement and system specifications, FMEA, test reports, CAD metadata.

Only sources with clearance are included – the source system's permissions apply unchanged inside the assistant. In addition, a question catalogue from the engineering departments with verified answers serves as the evaluation basis.

Why such initiatives fail

Permissions as the hard boundary. The know-how is spread across systems and access levels. The assistant must never see more than the individual user – a permission filter that kicks in after the answer is no filter at all.

No source, no trust. In engineering, verifiability counts. A language model keeps writing fluently even when it has found nothing relevant – the assistant has to show what an answer is based on, and to recognise when the sources do not support a reliable answer.

Knowledge keeps moving. Content changes continuously. Without continuous updates to the knowledge base, answers go stale unnoticed.

The LLM is only the tip of the iceberg. The real value is created underneath: clean ingestion, metadata, linking, permissions. That is where most of the work is.

Approach

The foundation is a retrieval architecture. An ingestion pipeline reads the source systems regularly and converts PDFs, Office documents and scanned attachments into structured text using VLM-based document processing – tables, numbering and attachment references are preserved. For every section we store metadata and the source system's permission information.

The search combines keyword search for exact identifiers such as part numbers and ECU abbreviations with semantic search via embeddings; the result lists are merged through reciprocal rank fusion and re-sorted by a cross-encoder. The permission filter applies before the answer, not after.

Three mechanisms work together against fabricated answers: the model answers exclusively from the retrieved passages, with a citation per statement. If retrieval quality falls below a defined threshold, the system declines to answer and names the closest documents instead. And an automated evaluation runs against the departments' question catalogue, measuring grounding in the sources, retrieval coverage and answer relevance – with spot checks continuing in operation, so quality degradation becomes visible.

For questions spanning several linked objects – from a requirement via the associated test case to the defect report – a knowledge graph built from the source systems' relationships complements the retrieval. A coordinator agent decomposes complex queries and delegates to specialised tools connected via MCP. The agent path is reserved for questions that need it, because it multiplies response time and cost.

Depending on IT requirements, the model is an open-weight model on the customer's own infrastructure or an EU-hosted service. The architecture is model-agnostic, so a switch requires no rebuild.

What you get

Search less, use more: knowledge is found and reused faster instead of being worked out again and again. Productive sooner: new colleagues find their way around the documentation landscape more easily.

A gateway, not a substitute: every answer leads back to its source – and when the evidence is too thin, the assistant stays silent. It remains a guide to the original documents, not their replacement.

The departments' question catalogue doubles as the acceptance criterion: we agree what share of questions must be answered correctly and with citations, and what share of unsupported statements is acceptable at most.