In our [last post →] we wrote about the productivity tax engineers pay on reference work — the hours each week spent looking things up across documents.
When firms set out to use AI to fix that tax, the instinct is reasonable: focus on the documents engineers consult most. That instinct produces real productivity gains. It also misses the bigger prize.
The bigger prize, almost without exception, is internal. This post is about the documents that turn an engineering AI knowledge base from a useful tool into something a firm can't imagine working without.
The wrong starting question
Most firms ask: which references do our engineers consult most often?
It's a reasonable question. It's also the wrong starting point. Those references are external, mostly stable, and (for most firms) come with their own search tools, their own publisher portals, or licence terms that explicitly restrict uploading them to third-party AI services. They're not where the productivity dial moves first.
The better question — the one that actually exposes where engineers lose time — is: which documents do our engineers waste the most time looking up that don't have a public answer?
The answers look completely different. They look like:
- "How does our firm handle [thing X]?"
- "What did we do on [project Y two years ago]?"
- "What's the load case our principals always use for retail fit-outs?"
- "Where's the design template Sarah built that everyone copies?"
- "What's our standard approach for heritage façade detailing?"
None of those questions has a public answer. They live in the firm's collective memory — partly written down, partly in senior engineers' heads, partly buried in shared drives nobody can navigate. That's the real reference problem. It's also the one nobody else can solve for you.
What belongs in an engineering knowledge base
The documents that pay back fastest, in roughly the order most firms find useful:
Your firm's design manual or guidelines. Almost every established engineering firm has one — preferred load combinations, default factors, naming conventions, design philosophies, "how we do things here." It's the single highest-leverage document in the firm. Every junior engineer absorbs it eventually. A knowledge base lets them absorb it on demand.
Project archives. Past calculations, design reports, structural narratives, RFI logs, peer review correspondence. The most common engineering question in any firm is "have we done this before, and how did we solve it?" A queryable archive answers it instantly. Today, that question gets answered by interrupting whoever's been at the firm longest.
Lessons-learned documents. Most firms have them. Most firms don't read them. An AI knowledge base reads them for you and surfaces the relevant lesson at the moment you actually need it.
Standard checklists, SOPs, and design templates. These exist to encode best practice but get used inconsistently — usually because finding the right one mid-project is harder than just doing the work fresh. Surface them via natural-language search and they actually get used.
Internal training and onboarding material. Discipline-specific tutorials, "how we explain this to graduates" decks, mentoring docs. Almost always written, almost always opened during week one of a new hire's tenure and never again.
Manufacturer technical literature. Datasheets, span tables, product design guides — the ones manufacturers distribute publicly for engineers to use. Legitimate, often a pain to navigate by hand, perfect for AI.
Your firm's published work. Conference papers, technical articles, white papers your principals have authored. Already public; you have the rights; surprisingly often forgotten as a knowledge resource.
Why internal content pays back fastest
Three things make internal content the better starting point.
1. It's where the time loss actually is. Engineers don't spend much time genuinely lost in published references — those are well-indexed, navigable, and often searchable in their own right. Engineers spend a lot of time hunting for the firm-specific way of doing things, the precedent project, the right template. That's where AI saves real hours.
2. It's irreplaceable. A junior engineer can buy a textbook. They can't buy the institutional judgement of your firm. Every senior engineer who retires or moves on takes knowledge with them that's hard to reconstruct. An AI knowledge base built on internal content turns that judgement into something durable and queryable.
3. It's legally clean. Your firm owns this content. There are no licence questions, no third-party rights, no concerns about uploading to a third-party platform. You can build a serious internal knowledge base without ever touching a document you don't have full rights to.
(That third point matters more than it sounds. Most engineering standards and many technical publications come with licences that explicitly restrict redistribution and upload to third-party AI services. The legitimate path for that content is publishers licensing it directly into software platforms — a model that's emerging quickly. In the meantime, the internal corpus is where firms can move at speed without legal complication.)
A practical starting set
For most firms, a useful first knowledge base is just five things:
- The current design manual.
- The last 18 months of project files for the most active discipline.
- The internal SOPs and checklists.
- The new-hire onboarding pack.
- The technical datasheets the firm references most.
That's it. Not a multi-year content programme. A single afternoon's gathering of files, mostly already sitting in folders nobody opens.
The firms getting the most from AI knowledge bases today are the ones who recognised early that the internal corpus was the prize. They started where they could move fast and where the IP was already theirs. Everything else — including external references that become legitimately available through publisher partnerships — gets layered in later.
In our [next post →] we walk through what an end-to-end engineering AI workflow actually looks like, with this kind of internal content as the foundation.
