Making Design Knowledge Centrally Available: Why Designers Are Searching Instead of Designing

Making design knowledge centrally available means that standards, guidelines, and company standards are available as verified, interconnected knowledge pages, rather than scattered across network drives and people’s minds. Designers ask questions in plain language and receive an answer drawn from the company’s approved knowledge base. Each answer is saved after human approval and is immediately available to the next person.

Where does engineering knowledge actually stand today, and what does that mean in everyday life?

In most design departments, the knowledge is there - just not where the work is actually being done. Standards and company guidelines are stored as PDFs on a network drive; the design rules for components and assemblies are buried in older drawings; and the rest is based on the experiential knowledge of individual employees. Anyone with a question has to leave the CAD window: search through folders, find an old drawing, and, if in doubt, ask a colleague. This costs time spent searching, time to get back into the interrupted design task, and the colleague’s time as well. The second effect is the more costly one: if the search takes too long, a decision is made based on the best available knowledge. This leads to different interpretations of the same standard within the same company, which are only noticed during inspection, in production, or at the customer’s site. File permissions on the network drive determine who is allowed to view which folders - we’ve described why access rights are better managed at the knowledge level in our introductory article on the AI knowledge database.

For your project, this means that your problem is rarely a lack of knowledge, but rather the path to finding it. Shortening this path not only saves time spent searching, but also reduces deviations that can become costly later on during testing and production.

What happens if the person with that knowledge is absent due to vacation, illness, or resignation?

For the design management team, this is the real issue. As long as the experienced colleague is on staff, asking her for advice works reliably. If she’s unavailable, it becomes clear just how much of the company’s binding standards was never put in writing: why a component is designed exactly that way, which exceptions apply to which customers, and which version of a standard is considered binding internally. During vacation or sick leave, this is a temporary problem; when she leaves the company, it’s a permanent loss. In some departments, there’s the added challenge that the retirement of several experienced knowledge holders is concentrated within a short timeframe - the age structure can be planned for, but the outflow of knowledge cannot. New employees face the same gap from the other side: It takes them longer to become familiar with company standards, and to do so, they turn to precisely those people whose time is already in short supply.

For your project, this means: Documented design knowledge isn't just a nice-to-have - it's what ensures you can provide information even on the day that person isn't in the office.

How can design knowledge be made centrally available without interrupting the workflow?

The approach we take with Quellwerk flips the direction: Instead of the person going to the knowledge, the knowledge comes to the question. This is how we’ve designed the cycle - in six straightforward steps:

1. A department asks a question in plain language.
2. The AI assistant searches the department’s verified knowledge base: standards, guidelines, components and assemblies, design knowledge, and approved answers.
3. Based on this, it formulates a draft answer.
4. An expert from the department reviews and approves it.
5. The approved answer is sent back to the requesting department.
6. The same answer is saved as a new knowledge page.

Two points are crucial. Step 4 is firmly anchored in the process and cannot be bypassed: What is sent back is not a model proposal, but a verified company standard. And because Step 6 follows directly from Step 5, documentation is created as a byproduct of answering the question.

From the question about human approval back to the department and to the same knowledge base.

For your project, this means you won’t be creating a second documentation requirement; instead, the body of knowledge will emerge from the work that is being done anyway.

Where does the designer work - in the browser or in the CAD window?

First, some context: Quellwerk is not CAD-specific. The knowledge cycle operates independently of the design tool and across departments - access is via the application itself and does not require a CAD installation. However, since switching windows always causes a brief interruption, we’ve also designed an optional integration with AutoCAD: ask a question in plain text without leaving the drawing, and get object-specific help for a selected element. The approval workflow and role-based permissions remain unchanged. Important: This integration is a concept, not an available product - there is neither a commitment to availability nor a release date, and Quellwerk functions fully without it. There’s a simple reason we’re even considering it: We’ve been developing AutoCAD plugins and CAD automation since 1995 and are an authorized Autodesk developer.

For your project, this means: Evaluate the current knowledge cycle. The AutoCAD integration is an additional option and is neither a prerequisite nor part of the decision.

What happens if there isn't an answer to a question yet?

At the outset, this is the norm, not the exception. If the assistant cannot find a satisfactory answer in the database, the process does not end with a shrug: With the click of a button, the question is forwarded to the appropriate specialist, along with a draft response that the specialist can correct, supplement, or reject. The real value lies less in the wording than in the assignment - the question goes to the person who can answer it, rather than being posted in an open forum or sent to a departmental distribution list. Once approved, the answer is returned and is then available to everyone who is authorized to access it. The escalation path is thus not a failure path, but rather the route through which unwritten design knowledge is put into writing for the first time. Any escalation that has been completed once is skipped the next time.

For your project, this means: The benefit doesn’t materialize on the first day, but rather to the extent that your department’s open questions have gone through this process.

How can recurring standard questions be turned into reusable building blocks?

Some of the questions that come up in a design department are almost identical: layer conventions, dimensioning rules, numbering systems for standard parts, and the internal interpretation of a guideline. For such cases, the system is designed to turn recurring requirements into so-called “skills” - capabilities created once that anyone on the team can then access without having to explain them again on a case-by-case basis. You can also set up queries that come up regularly as a scheduled process: daily, weekly, or monthly, with the results delivered right to your desk without anyone having to remember to do it. Both features are included in both editions - Basic and Enterprise - and are not reserved for the higher-tier edition. The result is less of a search aid and more of a step-by-step codification of your company’s design standards.

For your project, this means: The more frequently your questions recur, the more the maintenance effort is offset by recurring benefits - the questions that take the most time today are the first ones that can be clarified once and for all.

What are the realistic limitations of this approach?

Three points we cannot argue away. First, approval takes time, and this is most true at the beginning: As long as the knowledge base is sparse, many questions end up with the subject matter expert, and every draft needs to be reviewed. If you don’t factor this time into your planning, you’ll either end up with no verified answers or a backlog before approval. Second, the value depends on maintenance discipline: If answers aren’t approved and standards aren’t updated, even an AI-powered knowledge base will become outdated. That’s why we always deliver Quellwerk only as part of an accompanying workshop, in which we first analyze your existing knowledge maintenance process - we’ve described this process in our introductory article. Third: Since we have not yet completed a customer project, we cannot provide empirical data from live operations. What is described here is the process as we have designed it - not a result that we have already measured.

For your project, this means: Plan for review time in the initial phase and designate one person per department to be responsible for this task. Without these two commitments, the approach will not work.

At what point does this become worthwhile for your design department?

We consider the effort justified when several factors align: The same technical questions recur across multiple people or locations. A significant portion of the essential knowledge exists only in oral form. Staff turnover or the age structure of the workforce makes the departure of key knowledge holders foreseeable. And your collection of norms, guidelines, and standards is large enough that searching through it already regularly takes up time. Conversely: A small, well-coordinated team with well-maintained standards and no personnel changes does not need this. Regarding scalability: The entry-level “Basic” plan is designed for up to 15 workstations in a department - a typical design department thus fits into the smaller tier; “Enterprise” is unlimited and can be supplemented with individual modules. As long as no project has been completed, we deliberately keep this criterion qualitative.

For your project, this means: Don’t ask whether AI can help, but rather whether your department exhibits these four characteristics. If three of them apply, it’s worth having a conversation - you can find details about the product on our Quellwerk product page.

FAQ

Do we have to organize our knowledge first before we can get started? No, and that’s exactly the point: The content grows along with the questions that are answered. Requiring a fully organized wiki as a prerequisite would cause the project to fail in the same way that traditional wiki implementations fail. It makes sense to start with what people are already asking for.

Can designers ask questions without leaving CAD? Quellwerk itself is not tied to any CAD system and is used independently of it. In addition, we have designed an optional integration with AutoCAD that allows access directly from within the drawing. This integration is a future development direction, not a currently available product - there is no availability commitment or release date for it.

Who decides whether a response becomes an official company standard? An expert from your department. The AI creates the draft, but approval rests with a human and is built into the process. Without approval, no response is sent out and no knowledge page is created.

What is the cost to get started, and how many workstations does the Basic tier support? Basic starts at 10,000 EUR plus applicable VAT and is designed for up to 15 workstations in a single department. Enterprise is priced on a custom basis, has no limit on the number of users, and includes additional custom modules. This offer is intended exclusively for business customers.

Does this only work in engineering? No, on the contrary: Quellwerk is designed from the outset to be cross-departmental and is not tailored to engineering or CAD - sales, customer service, manufacturing, and assembly all follow the same workflow. Engineering is simply the area where the costs of searching are most evident, because that’s where questions about standards and specifications arise in the middle of an ongoing drawing task.