Company Brain for engineering design consultancies

Why did we reject that layout?

Suppose a consultancy is working on the layout of mechanical rooms. An engineer recalls a similar option from an earlier job. An approved meeting note records why that option was rejected: it required relocating a room that the owner had excluded from the renovation scope. The project folder also contains a later draft drawing showing the rejected layout again. The drawing has no approval. On the current project, the team has yet to establish whether the corresponding room can be relocated.

Asked about the earlier decision, a useful assistant would find the approved note and explain the owner's restriction. It should also provide a link so the engineer can open the document and read the full decision. The later drawing may be worth reviewing, but its date alone does not establish that the team reversed its decision.

The engineer now knows what to look for in the current project requirements: whether the renovation scope allows that room to be relocated. The earlier rejection does not determine the outcome of a new assessment. The assistant retrieves the recorded reasoning; the project team judges its relevance and makes the decision. This use of AI covers finding knowledge. Engineers remain responsible for calculations, design choices, and project approval.

What to retain from past projects

In this example, the useful knowledge is the constraint that drove the decision. The drawing alone would not explain why the option was dropped. A firm's project knowledge library should therefore include the reasons for decisions, linked to the documents they concern.

Someone reading that record needs to understand the original assignment and the conditions that applied when the decision was made. That context helps them distinguish a lesson they can use again from a requirement specific to one owner. If a note says only “option rejected,” AI has no basis for supplying the reason. Someone will need to find another record or speak with a participant in the original discussion.

The library also needs an owner. When a later meeting changes a decision, the new record should be linked to the earlier one. The old document still explains how the work developed, but someone looking for the final decision should be able to find what superseded it. The engineering director might assign this responsibility to project leads or designate someone to collect approved lessons. Without clear responsibility for the content, even a capable search tool will keep returning incomplete records.

When your existing search is enough

If engineers know the project and the document name, start by checking the tools they already use. Better descriptions and version labels may make the note easy to find without a separate AI application.

For example, BIM 360 Document Management documentation describes searches using document names and attributes, with filters that include current version and review status. Results exclude documents the user does not have permission to view. Content search has a narrower scope in that documentation: it supports vector PDF files in the Project Files folder. Autodesk describes these features in its BIM 360 document search guide. Before commissioning another tool, check what the specific system your firm uses can do.

A Company Brain is worth considering when people remember the problem but cannot recall which project addressed it, or when they need to connect a note with several later decisions. Assess its usefulness with questions engineers actually ask their colleagues. Can they find the reason behind a decision? Can they open the right record and establish whether it changed later? After reading the answer, do they know what still needs clarification on the current job?

Shared knowledge and an owner's project files

Sharing experience across teams requires deciding which materials those teams may read. If an owner's documents are restricted to the project team, the assistant should preserve that restriction in its answers and quotations. A separately prepared and approved summary can go into the shared library, within boundaries set by the firm. Removing the owner's name alone does not establish that the remaining details can be shared.

The entry should also identify who prepared it and who can explain it. An engineer on another team may not need the entire project archive. A description of the constraint that ruled out an option, together with a contact authorized to discuss the matter, may be enough.

A first project with Syntalith

Syntalith builds Company Brain applications to help teams find answers in their organization's knowledge. For an engineering consultancy, an initial scope could cover one library of approved notes and lessons from completed projects. Syntalith would connect that library to an assistant that answers engineers' questions, links to sources and their versions, and respects the access rules set by the firm. Project staff would review answers against work they know, while a designated owner would maintain the library's content.

Before expanding the library, compare that help with the way people find information today. If they still have to call the author because the answer leaves out the reason for a decision, a correct link alone has not solved the problem. If the reasoning was never written down, the first task is to record and approve it. A trial can therefore reveal a need for an application, for better documentation, or for both.

For an initial conversation, describe one decision whose reasoning your team recently tried to recover and where they looked for it. You do not need to send confidential files or prepare a specification first. See Syntalith's pricing page for commercial information. If a similar problem affects answers to customers, read about Company Brain for industrial proposal knowledge.