Standards search in mechanical engineering: the 2026 guide

Anyone designing machinery works against standards all day: safety requirements, tolerances, materials, test procedures. Yet standards search is the slowest step in many design departments. The standard is licensed and stored somewhere, but the one requirement that matters right now only surfaces after long scrolling. This guide explains why that is, where design engineers search today, and what actually changes with AI-assisted search.

Why does standards search take so much time in mechanical engineering?

The time is rarely lost acquiring a standard. It is lost finding the relevant passage. Three factors combine:

The content is scattered. The valid edition sits in the subscription database, older versions as PDFs in project folders, the interpretation in the head of an experienced colleague or in an internal design guideline. Anyone with a question searches three worlds with three different tools.

Standards reference each other. A question about safety distances starts in a type-C standard, leads through a type-B standard to the basic standards and back. Every hop means opening a document, reading the table of contents, scrolling. The reference chain is intentional, but it makes searching expensive.

The effort is invisible. Search time never appears in a post-project costing. Studies on knowledge work, for instance by the McKinsey Global Institute, put the share of information search at roughly one fifth of working time. In mechanical engineering there is an extra edge: a missed requirement does not just cost time, it gets expensive in the risk assessment or the CE process.

On top of that, the rulebook itself is in motion: with EU Machinery Regulation 2023/1230 replacing the Machinery Directive from January 2027, harmonised standards are being reassigned. The need to search is rising, not falling.

Where do design engineers search for standards today?

The typical tool chain in most companies looks like this:

• DIN Media webshop (formerly Beuth): research by title and number, purchase of individual standards. Good for acquiring, hardly suited to searching content.
• Standards databases such as Nautos (formerly Perinorm): subscription access with full-text search and currency checks. Strong on "which standard applies and is it current?", weaker on "what exactly does it say and where?".
• The standards department: in larger companies a central function channels procurement and currency. It is rarely sized for the daily stream of detailed content questions from design.
• Reading points and free sources: DIN information points allow inspection, committee pages and lists of harmonised standards help with orientation. For the daily routine of a design team they are too slow.
• The internal file share: project folders, drives, old calculations. This is often where the most valuable information lives, namely how a requirement was already implemented in-house. Almost none of it is searchable.

Each tool solves part of the problem. None answers the question a design engineer actually sits with: "Which minimum distance applies in my case, and where does it say so?"

Standards research vs. everyday standards search: what is the difference?

The two terms are often mixed up but describe different jobs:

Standards research clarifies which standards apply to a product in the first place: mapping directives and regulations, identifying harmonised standards, assessing applicability. It happens at the start of a project, is owned by CE coordination or the standards department, and is well documentable.

Everyday standards search is the daily detail question in ongoing design work: a specific requirement, a limit value, a test condition, across standards that are already identified and licensed. It happens dozens of times a week and is the part that costs the most time in total.

The classic tools were built for research. Today the bottleneck is almost always the everyday search, and that is exactly where AI comes in.

How is AI changing standards search?

That AI-assisted search is no longer a niche topic is demonstrated by the standards world itself: the DIN Group has introduced NormChat, its own AI assistant that identifies relevant standards and extracts key passages. The direction is officially confirmed: instead of scrolling documents, you ask questions.

For use inside a company, one distinction is decisive and often lost in the discussion:

Public AI tools are the wrong place for licensed standards. Standards texts are protected by copyright. Uploading them to a public chat tool is usually not covered by the licence, and the answer does not reveal whether it comes from the uploaded document or from the model's training data. For standards questions that is doubly risky, because the edition decides.

AI standards search becomes usable in your own controlled repository. The licensed standards and the internal documents stay in an environment the company controls, with EU hosting and role-based access. The AI answers questions exclusively from this repository and backs every statement with document, edition and page. Why that citation decides whether the answer is usable at all is covered in depth in Searching standards with AI: why the citation decides usability.

The second lever is at least as big as the first: such a system searches not only standards but the internal engineering knowledge next to them, meaning guidelines, calculations, project documentation. The question "how did we solve this on the last project?" gets answered in the same step as the standards question.

What matters in AI-assisted standards search?

An honest comparison of the three approaches:

Criterion	Manual search	Full-text database	AI search with citations
Time per detail question	Minutes to hours	Minutes, hits per document	Seconds, direct answer
Answers questions	No, returns documents	No, returns hits	Yes, with a citation per statement
Reference chains across standards	Followed manually	Per document, one by one	Summarised, every step cited
Internal documents included	Separate search	Usually no	Yes, same repository
Edition visible	Yes, with discipline	Yes	Yes, per answer
Licence compliance	Given	Given	Given, if documents stay in the controlled repository

Three test questions separate usable systems from unusable ones: Does it back every statement with document and page? Does it say "not found" instead of improvising? And do the documents stay where the licence says they must? How KoAssist handles these points technically is shown on How it works, details on hosting and access control are under Security.

What does this look like in practice?

An example from special-purpose machinery: at GISCON we made years of project knowledge from special machinery projects searchable. Design engineers ask in natural language and get answers with file and page citations instead of digging through folder structures. At Roschiwal + Partner, drawing archives are part of the searchable knowledge, exactly the document type where classic full-text search fails.

The pattern transfers to standards collections: start small with one frequently used set of standards and the internal guidelines that belong to it, verify answer quality and citations in daily use, then extend.

Conclusion: the bottleneck is the search, not the collection

Most machinery companies own the standards they need. What is missing is fast, verifiable access to their content and to the internal knowledge next to them. AI-assisted standards search resolves exactly this bottleneck, provided it works licence-compliantly in your own repository and backs every answer with a citation.

If you want to see this with your own standards and documents: book a demo and we will show it on a collection from your daily work.