The 2026 guide to standards search in mechanical engineering.
Design engineers lose hours searching standards content. Where teams search today, what it really costs, and how AI speeds up standards search.

Standards search in mechanical engineering takes so long because the content is scattered across subscription databases, PDF folders and the heads of experienced colleagues. It gets faster with a searchable, licence-compliant repository inside the company: somewhat with full-text search, substantially with an AI assistant that answers questions and backs every answer with document, edition and page.
Contents
- Why does standards search take so much time in mechanical engineering?
- Where do design engineers search for standards today?
- Standards research vs. everyday standards search: what is the difference?
- How is AI changing standards search?
- What matters in AI-assisted standards search?
- What does this look like in practice?
- Conclusion: the bottleneck is the search, not the collection
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.
How KoAssist provides that access is set out on the knowledge assistant page.
Frequently asked questions
More from the blog
Back to overview- 05 November 2026Article4 min
What happens to project knowledge when a quarter of the workforce in machine building retires?
By 2034 about 296,000 employees in German machine building will retire, while only about 118,000 will follow. What gets lost in the project business, and how to keep the knowledge in the project before the experienced people leave.
4 min - 03 November 2026Article7 min
Why does project status in Excel, OneNote and email take so long to pull together?
Open-points list in Excel, meeting notes in OneNote, decisions buried in email threads. Why the project status in plant engineering has to be rebuilt every time, and how it can assemble itself from the sources.
7 min - 26 October 2026Article7 min
How to keep the internal and customer versions of a status report apart
What belongs in a status report for the customer, what never does, and how to produce both versions from the same project status so internal remarks never reach the customer.
7 min
