AI for Engineering Knowledge Management
What an AI assistant can read from engineering documents stored in SharePoint instead of a PDM vault, where a document library stops, and how to configure one.
·
⏱
8 min read
Dr. Maor Farid
Maor Farid is the Co-Founder and CEO of Leo AI, the first AI platform purpose-built for mechanical engineers. He holds a PhD in Mechanical Engineering and completed postdoctoral research at MIT as a Fulbright fellow. A Forbes 30 Under 30 honoree and former AI researcher and Mechanical Engineer in an elite military intelligence, Maor leads Leo AI's mission to transform how engineering teams design better products faster.
BOTTOM LINE
SharePoint is a capable file store with real limits that matter to engineers. It holds the scale, the version history and the custom metadata you need, and it exposes all of it through an API. What it does not hold is the relationship between a model, its drawing and the assemblies that consume it, and it cannot read the inside of a native CAD file at all. Put the facts engineers query on into columns rather than filenames, keep a readable derivative next to every native file, and an assistant pointed at the library can answer most retrieval questions with a citation attached. The structural questions, meaning where-used, release state and duplicate parts, need either a vault or a layer that reconstructs those relationships from the documents themselves.
Plenty of engineering teams never bought a PDM system. The drawings, the specifications, the supplier datasheets and the released revisions all sit in a SharePoint document library, because that is where the rest of the company already keeps its files. The arrangement works well enough to survive an audit and badly enough that nobody can find last year’s bracket drawing without asking the person who made it.
The useful question is not whether SharePoint is the right home for engineering data. For most teams that decision was made years ago, outside the engineering group, and it is not being reopened this quarter. The question worth asking is what an AI assistant can actually do with documents kept there: what it can read, what it cannot, and how much of the gap is a configuration problem rather than a product problem.
What follows is what a document library exposes, where it stops, and how to set one up so that an assistant pointed at it returns something an engineer can act on.
What a SharePoint Library Already Knows About Your Drawings
A document library is a list with files attached to its rows, and that framing explains most of what it can and cannot do. Every file carries the properties you would expect: name, size, who created it, who touched it last, and the folder it sits in. Underneath that, each file is also a list item, which means it can carry columns an administrator defined, such as a revision letter, a project code, a release state, an owner or a material callout.
Microsoft documents the ceilings generously. A single library can hold up to 30 million files and folders, an individual file can reach 250 GB, and version history can run to 50,000 major versions. Nothing about the sheer scale of an engineering archive is going to break it.
Version history is the part teams usually under-use. SharePoint keeps every saved version of a file with the author and timestamp attached, and check-out provides a coarse lock so that two people do not quietly overwrite each other. Combined with an explicit release-state column, that is enough to answer who changed a document and when without anyone’s memory being involved.
All of it is reachable over the Microsoft Graph API. A client with the right permission can read a file’s properties, pull its full version list, and read the custom columns through the associated list item. That matters, because it means an assistant does not need a bespoke connector into SharePoint. The metadata an engineer cares about is already addressable, provided somebody put it there in the first place.
IN PRACTICE
It surfaces the relevant internal material, previous design decisions, past calculations, and backs everything with a cited source I can actually click on and verify.
- Yuval F., Clalit
Where the Document Library Runs Out of Answers
The trouble starts with content rather than metadata. SharePoint parses a file to make it findable, and that parsing has published limits. It stops after 2 million characters, it allows roughly 30 seconds of processing per item, and it declines to download anything over 150 MB for indexing, or 512 MB for PDF and Office formats. A file past those limits is still stored and still listed. Only its metadata is indexed, and its contents stay invisible to search.
Now look at what an engineering library actually contains. A native assembly file is a binary format SharePoint has no parser for, so nothing inside it is indexed at all. A large STEP export can clear the download ceiling on its own. A scanned legacy drawing is an image until somebody runs optical character recognition over it. The files that matter most to an engineer are precisely the ones a document library understands least.
The second gap is structural. A library stores files; it does not know that one file references another. SharePoint has no idea that an assembly points at fourteen parts, that a drawing belongs to a model, or that changing one fastener affects nine products. A PDM vault maintains those references as a first-class relationship. A folder, however carefully named, does not, which is the same wall teams hit when they index a CAD folder on a network drive.
The third gap is agreement. Columns only help if people fill them in. Libraries that grow organically end up with revision encoded in the filename, state encoded in the folder name, and a dozen variations on both. The information exists, but not anywhere a query can reach it, which is the same failure mode that makes document control break down even in teams that do have a written process.
What an AI Assistant Can Read From SharePoint Today
Given that picture, a useful assistant does three things rather than one. It reads the library metadata, so it can filter on project, state and revision without guessing from filenames. It reads the parsed content of the formats that do parse, which covers most specifications, reports, procedures and drawing PDFs. And it falls back on geometry and structure for the files SharePoint cannot open at all.
Leo is built as an intelligence layer on top of wherever engineering data is already filed, rather than as another place to file it. Leo offers integrations with leading PDM and PLM platforms (SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, Arena PLM, and others), and the same retrieval approach applies to a document library or a network share. The value driver is retrieval cost: an engineer who can ask a question in plain language and get a cited document back stops paying the fifteen-minute tax of hunting through folders, and stops redesigning parts that already exist.
The citation matters more than the answer. An assistant that returns a confident paragraph with no provenance is worse than useless in an engineering context, because the engineer has to verify it anyway and now has to find the source as well. Returning the document, the revision and the passage the answer came from is what makes the output checkable, and checkable is the only standard that survives a design review.
The Questions That Still Need Engineering Context
Some questions a library cannot answer no matter how carefully it is configured, because the answer depends on relationships the library never recorded. Four of them come up constantly:
Which revision is actually released. A library can tell you which file is newest. Released and newest are different states, and only an explicit column or a workflow knows which is which.
What a change affects. Where-used analysis requires the reference graph between models, drawings and assemblies. Without it, impact assessment is a conversation rather than a query.
Whether the part already exists. Duplicates hide behind different names in different folders, and finding them needs shape and attribute comparison rather than filename matching, which is why search fails inside a PDM vault for much the same reason.
Why a decision was made. The calculation that justified a wall thickness usually lives in an email, a review deck or somebody’s head, not in the drawing it produced.
The honest framing is that a document library is a good filing system and a poor product record. Teams that outgrow it generally move to a vault or a PLM system, and the options for putting AI on top of a PDM are worth reading before committing to that migration. Until then, the gap is closed by an assistant that reads across the documents and reconstructs what the library never stored.
Setting Up a Library an Assistant Can Actually Use
Most of the available improvement is configuration, and it is cheap compared with a migration. Five changes do the bulk of the work:
Promote the facts out of filenames. Revision, project, release state and part number belong in columns, not in the string before the file extension. A content type applied across the library makes those columns consistent instead of optional.
Use managed metadata for anything with a fixed vocabulary. A term set for project or discipline prevents the nine spellings that a free-text column collects within a year.
Keep a readable derivative beside every native file. A drawing PDF next to the native model gives both search and an assistant something to parse, and it outlives the day a seat licence lapses.
Watch the size ceilings. Large exports that exceed the indexing limits are stored but never read, so the derivative matters most for exactly those files.
Keep permissions as inherited as you can. Trimmed results are correct behaviour, but a library carrying hundreds of broken inheritances produces answers that differ per person in ways nobody can debug.
None of this requires buying a PDM system, and all of it makes one easier to adopt later, because the metadata you standardise now is the metadata a vault will import when the time comes.
FAQ
Find any engineering document faster
Leo connects to where your drawings already live and makes them findable.
Leo reads engineering documents wherever they are filed, in SharePoint, a network drive, a PDM vault or a PLM system, and answers with a citation you can open and check.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
