SharePoint search fails for technical documents because it matches keywords against file text and metadata, while technical questions arrive in chemical context: an application, a constraint, a regulation. A keyword index cannot tell the governing TDS from a stale revision, and it reads a viscosity value as text. Kimia, a chemical intelligence platform, answers technical questions from a structured product record instead of a keyword index.
SharePoint matches keywords, technical questions arrive in chemical context
SharePoint indexes the text and metadata of every file in a library, and search returns the documents whose words match the words typed. That works when the searcher knows the file name or an exact phrase inside it. A technical question rarely comes in that form. Buyers and reps ask in application language: substrate, process conditions, regulatory status. A TDS is written in attribute language, so question and document share few words.
The match fails at the vocabulary, before ranking even matters.
In practice: a rep searches a SharePoint library for an adhesive that bonds polypropylene film at line speeds above 200 m/min. The search returns every document containing "polypropylene", ranked by keyword relevance. The data sheet of the grade that holds at that speed sits somewhere in the list, indistinguishable from the rest.
Keyword relevance cannot separate the governing revision from a stale one
A folder of uploaded documents goes stale the day after upload, and an old marketing deck can outrank the current spec sheet at random. SharePoint keeps version history inside each document, but search ranks across libraries by relevance signals, not by which document is authoritative. Two revisions of the same TDS, saved in two site libraries by two teams, appear as two separate results. Nothing in the index records which one the business has published.
In practice: a distributor asks for the current SDS on a grade sold into the EU. The rep's search returns three copies with different revision dates across two libraries. The rep forwards the newest-looking file, while the copy the customer's regulatory team already holds came from somewhere else entirely.
A data sheet is data, and a keyword index reads it as text
A generic search system reads every attribute as undifferentiated text, so storage condition and suitable substrate carry the same weight, and SKUs collapse into the base product. A viscosity of 3,000 mPa·s inside a PDF table is a string of characters to SharePoint, never a value with a unit and a test method attached. Filtering products by a numeric threshold, a regulatory status or a substrate compatibility is a query the index has no field to run against.
In practice: a formulator wants dispersions with viscosity under 3,000 mPa·s and food-contact approval for EU flexible packaging. SharePoint cannot compare numbers locked inside PDF tables, so someone opens the candidate data sheets one at a time and builds the comparison in a spreadsheet.
An AI layer over the document library inherits the same problems
A tempting fix is to aggregate every TDS, SDS and application note into one searchable system and make it conversational. Retrieval gives a system access to information, not judgment. It cannot tell which facts are binding, which of two conflicting data sheets governs, or whether the evidence supports a recommendation at all. And at thousands of products and tens of thousands of files, plain retrieval dilutes, so accuracy decays quietly as the library grows.
In practice: an assistant piloted over a few hundred documents answers well. Rolled out across a full portfolio, it retrieves the data sheet of a discontinued grade because the file was never deleted, and presents that answer with the same confidence as a current one.
Chemical context lives in a structured product record, not a search box
Kimia builds a structured product record for every item in the portfolio, consolidating information that was distributed across shared drives, email threads and individual files. Attributes are typed, units and test methods stay attached, and regulatory status is a first-class field with every attribute traced to a source ranked by authority. Questions asked in application language are matched to products through that record, and each answer cites the governing document. When a decisive attribute is missing, Kimia asks for it instead of guessing.
In practice: a rep asks Kimia's Technical Sales Assistant for a REACH-compliant grade with peel strength on polypropylene at 60°C. The answer names the candidate products, states the values behind the match and cites the data sheet each value came from.
What changes
Found by meaning: questions in application language return products, never ranked file lists.
One governing answer: every response draws on the record the business has validated.
Sourced replies: each answer cites the document behind it.
Fewer escalations: commercial teams answer customer questions without waiting on technical experts.
SharePoint remains a competent file store. The failures begin when a file store is asked to answer chemical questions, and answering those takes a product record built for chemistry, which is what Kimia provides.
Customer stories
Univar Solutions deploys Kimia to accelerate technical sales. Bostik runs Kimia in production, and Aldric Tourres, Global Director of Digital at Bostik, says: "Kimia has become our partner of choice within Bostik for scaling technical expertise globally." Kimia is also live at Stahl.
FAQ
Does SharePoint search work for TDS and SDS files?
Yes, for finding a file whose name or text matches the words typed. It fails on technical questions, because a TDS describes a product in attribute language while buyers ask in application language, and because keyword relevance cannot tell the governing revision of a document from a stale copy saved in another library.
How is a chemical intelligence platform different from document search?
Document search returns files ranked by keyword relevance. A chemical intelligence platform answers the question itself: Kimia holds a structured record for every product, with typed attributes, units and test methods, matches an application need to products through that record, and cites the governing document in each answer. The output is a sourced answer rather than a list of files.
Why does adding AI on top of SharePoint still give wrong answers?
Because the assistant inherits the library it reads. Retrieval gives it access to the files, and access is not judgment: it cannot tell which facts are binding, which of two conflicting data sheets governs, or that a discontinued grade should no longer be recommended. Retrieval also dilutes at scale, so accuracy decays as the library grows.
Does Kimia replace SharePoint?
No. SharePoint stays where teams store files. Kimia consolidates product information that was distributed across shared drives, email threads and individual files into one location, builds a structured record from it, and draws on that record when answering queries or generating documents, so reps and customers stop working from outdated or incomplete versions.
Can Kimia find a comparable product for a given item?
Yes. When a product is unavailable, or a customer is committed to a product you do not stock, Kimia identifies alternatives from your own portfolio that match the relevant technical criteria, and it surfaces substitutes for competitor products. It also finds duplicate SKUs that perform the same function, which is common after acquisitions where ranges overlap.
