Engineering even a simple product often requires adhering to thousands of pages of specifications stored in PDFs. When specifications change, it can cause a chain reaction that takes weeks or months to resolve.
XSB’s SWISS product uses AI to transform PDFs of legacy documentation into a Knowledge Graph of smart connected documents. SWISS connects the ideas that are siloed in legacy systems to provide the information that engineers need when and where they need it.
In our conversation with Rupert Hopkins, the Founder and CEO of XSB, we discussed how moving from documents to linked knowledge increases productivity, decreases errors, and makes the ideas locked in PDFs machine-understandable.
How does SWISS affect the day to day life of the people that rely on specifications and requirements documents?
SWISS offers a big boost in productivity for product specialists working on any particular design. Instead of going to the engineering library, downloading the PDF spec, reading it, interpreting it, and moving on to the next test, all of that information is at their fingertips. By making SWISS interoperable with the systems the engineers work on, users can consume the information they are looking for the moment they need it.
Why do documents within model based engineering cause such a headache?
Even for something as simple as an Army combat jacket, an engineer will need 5,000 pages of specifications and standards to produce the final jacket. But the user doesn’t actually need those 5,000 pages, they really only need a paragraph here, or a table there, or a method on another page. We know that all the unstructured information is in these documents but you can’t efficiently find the detail you need.
That’s because a PDF is really just a picture of the blocks of text, tables, and diagrams of the specs, materials and processes we need to do our jobs. Fundamentally, almost all of our document technology, including PDFs, is for telling a printer how to spray ink on paper. PDFs don’t tell the user how to navigate the ideas that are in the document, or find what they need beyond a simple keyword search. And the ideas in PDFs are not linked to the ideas in related documents in any way. Each PDF is an island.
A PDF doesn’t really have any of its meaning embedded into it. We can’t ask this PDF document any questions or query it in any way. We can’t easily navigate a level deeper about what parts they are defining or what materials are needed.
What is the advantage of bringing these PDF documents into a Knowledge Graph?
By taking related concepts and linking them together in a Knowledge Graph, the documents become both human and machine-understandable. Engineers themselves can understand and query these documents and the machines can also pullout information from those documents.
In the current PDF-based world, to test a part to see how it stands up to salt spray, a design engineer will design the part, the industrial engineer will find a test method from a document, and then a technician has to read the document and type in time, temperature, and salinity. In the world we are creating, that test chamber is reading the time, temperature, and salinity directly from the specification. We are eliminating all the manual data entry between the author and the machine.
![Rupert Hopkins CEO XBS](/img/XBS Rubert Quote.png “Rupert Hopkins CEO XBS”)
How do you transform those thousands of pages of PDFs into the connected documents that your customers use?
We take the syntax of the document—the titles, sections, sub sections and tables—and think of those markers as the latitude and longitude of a given document. Those ‘coordinates’ then describe where the ideas in the document live. From there we create a single authoritative point for a single idea that other references can point to. I know that the salt spray test mentioned in one document is the same as a test in a different document. It doesn’t matter who I am, or what enterprise engineering system I’m working with, I know exactly where the information I need is.
From an engineering perspective that’s extremely useful. With these smart, connected documents I can now trace ideas that used to be across thousands pages to find just the context I need. I can see what materials the spec call for, what regulations apply to those materials, and if that spec is now out of date. Ultimately, the user doesn’t need to know that this context refers to two ideas spread across three documents.
Today there is a huge manual effort inside large corporations when the technical data changes. Someone has to figure out how many airplanes on the assembly line are affected by that change. They have to go through every single one of those documents to figure out if they changed. That stuff should be done by computers; it’s a waste of time for these smart people. By creating these smart, connected documents, the documents know themselves. The documents can alert the user that, by the way, since the last time you looked at me, some of the things you reference have changed.
Of that complex process that turns static documents into knowledge, what do you think is the most novel part of the SWISS?
The real novel thing was rejecting the idea that static documents were the only way to convey this information. Engineers accepted the tedious work of combing through thousands of pages of PDFs because there wasn’t any other to access those ideas. By introducing a Knowledge Graph of smart, connected documents we fundamentally changed the way that engineers, designers and project managers interact with this complex network of specifications and requirements.
Now that these ideas are within a Knowledge Graph they can be used as an authoritative source of truth that ultimately powers the machines we interact with.