This is the first in a series about the principles of the Transform Manifesto. If you want to start at the beginning, go here. When you’re ready for the next one, go here.

For a long time, having all the right engineering documentation was all you needed to get the job done. Up until the mid 1990s, that meant piles and piles of paper documents and drawings. In the late 1990s, all the non-GD&T (Geometric Dimension and Tolerance) information such as industry specs and standards, technical data packages, work instructions, test methods, and internal corporate standards, moved from paper to PDF. At the time, it was a revolution that increased speed and enabled easy sharing – but PDF was never meant to be an engineering information tool.

Amazingly, not much has changed since then: most engineering documentation is in PDF format. This means that all the text, graphs, tables, equations, images, and references that comprise manufacturing notes, part/material/process attributes, requirements, test methods, work instructions, supplier instructions, customer requirements, and more are trapped in static PDF (and sometimes PowerPoint, MS Word, or even paper). Nearly every information user in the product development lifecycle struggles to find the precise information they need, extract the relevant data for the task at hand, and feel confident they are using the right versions and references in a sea of disconnected, static documents.

An engineering document is essentially a vast collection of individual pieces of data that engineers need to do their jobs. We believe these individual pieces of data must be liberated from the static document and free to be used where and how end-users need them.

If a worker needs the hole drilling requirements, they should be able to call them up quickly and easily and feed them into the machine. Better still, the machine should be able to extract them on its own and take action based on the data. If you need to share a complex table of values with a supplier, you should be able to extract the values and variables and transfer them easily while maintaining fidelity (and copyright ownership) to the source document. The supplier should be able to receive them in the application in which they are working. And if a change is made to the source document, the supplier should receive a notification of that change. 

We also believe that each individual piece of data is more than just a jumble of letters or numbers: it has a purpose, it conveys meaning, and each piece of data shares a relationship with many other pieces of data. This is what we mean by context.

Context is the nuance, the unwritten but implied, the actionable intelligence that helps us better understand and use the data contained in the documents. For example, from context we can glean part, material, and process attributes (such as a process that involves hazardous materials). We can determine whether a prescribed process is dependent on another process or requirement, necessitating one process to come before the other in a project timeline. Using context, we can more accurately identify candidates for additive manufacturing. With context, we can quickly and easily qualify vendors as suitable or unsuitable for a particular task.

For many decades, the general wisdom in the information economy was that “content is king”. Today, content is still critical but context is becoming ever more important. By turning documents into data, we can identify, extract, and deliver the contextual and actionable intelligence that users need to make better decisions faster. If content is king, then context is surely queen.

The SWISS platform transforms engineering documents and drawings into interoperable, intelligent, and reusable collections of data that integrate seamlessly into modern engineering workflow. SWISS combines content, context, and software to reduce manual labor and deliver insights that help individuals make better decisions faster.

What do you think? Does this resonate with you? If you think it’s time to shift from documents to data and from content to context, let’s talk.

Ready for the next in the series? Go here.

If you want to read all seven principles of the Transform Manifesto, start here.

Engineering documents have largely been left behind in the wider quest for digital transformation, but as more companies are seeing concrete benefits from addressing this “last mile” of the digital thread, we felt it would be useful to describe the critical areas where we think you and your company should be focused.

We published a set of principles – called “The Digital Transform Manifesto” (aka the “Transform Manifesto)– that you can use on the path to transform your engineering documentation into more usable, efficient digital twins. For the short and sweet version, take a look at our digestible slide deck here.

For a deeper dive into each of the seven principles, we’re posting a series of articles explaining each one and offering examples and best practices that you can implement in your own organization. Please share with your friends and colleagues and leave us a comment!

Why a manifesto? In a word, status quo. Ok, that’s two words but one concept. The status quo is hard to change but we’re going to give you powerful reasons to shift to a better way of working.

Engineering documents and drawings are full of essential data like requirements, references, materials, manufacturing processes, and more – necessary for ensuring high-quality, compliant products. But most of these documents are in flat-text PDF format, which is a poor container for data that hasn’t changed in almost 30 years. The only way to access this data from PDF is deep analysis by subject matter experts, then manually copying, pasting, and data-entry into other applications. None of this static data is linked to the sources or to the digital thread, so change management and impact assessment are difficult and uncertain. This results in overwhelming manual labor, too many errors, too much rework, and unacceptable risk.

Follow these principles to turn your engineering documents and drawings into actionable intelligence with new capabilities that reduce time, cost, and risk throughout the product life cycle.

The Seven Principles of the Transform Manifesto

1. Documents are out. Data is in. Content is out. Context is in. Read here.
2. Engineering data should be connected to a single authoritative source of truth, with changes communicated to all. Read here.
3. Engineering data should be interoperable across IP owners, users, and software applications. Read here.
4. Engineering information should be delivered at the point of need, anywhere in the enterprise, through APIs. Coming soon.
5. Engineering data should be machine-readable. Coming soon.
6. AI can be used to derive insights and intelligence from unstructured text. But AI must be used responsibly to ensure high accuracy and transparent sources. Coming soon.
7. Data contained in documents should be available as authoritative and reusable data objects. Coming soon.

We recently read this interesting view of AI and the differences between Generative AI and SynthAI.

In B2C markets, Generative AI is mostly being used for fun and to create something to share: art, poems, essays, blog posts (not this one!), and more. The content has sound grammar and vocabulary but is not always technically accurate. But in the consumer and blogger/influencer world, quality or correctness are not high priorities.

In B2B, the calculus is quite different. In knowledge work, there is huge value in precision, accuracy, and intelligent decision making. Employees have to make the best possible decisions with imperfect information, and often, by analyzing impossibly-large amounts of information. Think material selection, customer specifications, or regulatory information across multiple countries.

In the next wave of AI, large language models (LLMs) will need to focus on synthesis and analysis – SynthAI – that improves the quality and/or speed of decision-making, if not make the actual decision itself. The most obvious application here is to summarize high volumes of information that humans could never digest themselves directly. The real value of SynthAI will be in helping humans make better decisions, faster.

This also happens to be the vision of SWISS AI as well: we process large amounts of information, filter out the noise, and synthesize relevant, accurate insights. SWISS AI is designed to augment and improve humans, not replace them. As Hex CEO and co-founder, Barry McCardel explains, “When it comes to understanding the world and making decisions, you want humans in the loop. What AI can do is help us apply more of our brainwaves to valuable, creative work, so that we not only spend more hours in a day on the work that matters, but also free ourselves to do our best work.”

Read the full article here.

In general, a digital thread is a record of all the digital data that is used to engineer, manufacture, and deliver a product or service. “In the digital world, the complexity of the physical world can be distilled down to the pertinent information needed to make decisions.” This might include information about parts, materials, customer specifications, regulations, testing methods, and may also incorporate real-time data from the product such as performance metrics, user satisfaction, error rates, and more. Taken together across the lifecycle of a product, the knowledge gleaned from one activity can be shared upstream and downstream to inform others’ decision-making.

However, there is an important set of information about products and services that is not yet being captured efficiently in the digital thread: the requirements imposed by customer specs, industry standards, or regulations. If specifications are the building blocks of design and manufacturing, then requirements are the building blocks of specifications.

1. Finding requirements within the specifications requires a manual effort by subject matter experts. It’s a tedious manual process that can take 30 hours for some documents and is clearly not scalable.
    
2. Extracting the requirements and sharing them with designers, builders, manufacturers, and compliance engineers is typically done via copy/paste and saving them as new PDF files – for example, a set of hole drilling instructions. The PDF files are then shared with users downstream and incorporated into PLM and other enterprise applications as simple file attachments, not so much integrated into the digital thread as hard-linked to it without the same level of usability and trackability.
    
3. Requirements in PDF format cannot be reasoned upon for decision-making or to find patterns or potential bottlenecks in the product lifecycle. For example, it would be very difficult for a human to wade through hundreds or thousands of documents to determine if there were restricted materials in the project, or if the project called for castings or forgings (which require extra long lead times and special treatment in procurement).
    
4. Some software applications can do the job of finding requirements by primitively searching for “should”, “shall”, and “may” statements. But what if you need to find a more granular set of steps to execute a very precise task.
   
   For example, imagine that you need to find out: “What are the requirements for hole drilling and reaming?” or “What is an acceptable alloy replacement and how do I qualify it?” or “What are the tensile strength requirements for the cable and how do I test it?”. These steps are often hidden in multiple layers of documents – where one document references another which references another and another. That process is even more tedious and difficult because it requires subject matter expertise and zen-like concentration to follow the requirements thread through multiple layers of documents.

As you can see from the illustration below, starting with just one spec or drawing can expand to dozens of documents containing the requirements you need to do the job. Answering the question “What are the requirements for hole drilling and reaming?” can take hours of work and is fraught with potential human error.

To solve these challenges, SWISS uses AI and semantic modeling to transform unstructured text and data from engineering documents and drawings into machine-readable digital model data. Once that transformation is complete, the resulting semantically structured data enables a machine to follow the breadcrumbs of meaning and context and pick out the precise requirements that you need for a specific task – in seconds rather than days or weeks. These requirements can then be delivered to users exactly where they need it (e.g. in PLM, in Office365, or other enterprise applications) through the SWISS API.

We call this the “Digital Thread for Engineering Requirements”. Imagine simply asking a question like one above and getting an answer that pinpoints the information you need and gets you to the next step in your engineering or testing workflow.

The promise of SWISS and the digital thread for engineering requirements is to parse all of these requirements in seconds (rather than hours or days) and classify them according to their part, material, and process.

And in line with digital thread concepts, when changes occur to the requirements at the source (for example, a change made by a customer or a compliance engineer), alerts can be sent downstream instantly to notify relevant users.

The benefits of the “digital thread for engineering requirements” are:

• Improved quality and first-time yield rates
• Reduced rework, scrap, failures in the field and warranty costs
• Faster product development and faster time-to-market

In Part 1 of this series, we defined digital models, digital twins, and the process of change management, impact assessment, and requirements management. We also described the challenges that static PDF documents pose to modern engineering workflow, i.e. they don’t play nice with the digital thread and cost companies far too much time, money, and risk. Now, let’s talk about what engineering documents look like when converted to digital models and dig into some of the benefits. To be clear, when we use the term engineering documents, we refer to a wide range of document types including internal company specifications, external industry standards, assembly instructions, procurement technical data packages (TDPs), test methods, and supplier requirements, and other similar types.

“What do you hire an engineering document to do?”

There are many answers of course, but in general, an engineer or technical professional uses an engineering document to:

1. answer a very specific question, or
2. to identify the requirements or procedures to implement the task at hand.

In a future state, perhaps a human will simply ask the document a question and get an answer (are you listening ChatGPT?). Or perhaps machines will read the documents and construct step-by-step instructions for humans. Or better still, perhaps one day machines will read the documents and act on their own to complete the required tasks. All of these scenarios are possible with digital models and machine-readable documents. But since AI hasn’t come far enough yet, and since documents don’t talk back to users or machines, and since most documents are not in the form of digital models, users must interrogate the document by reading it. I know, I know – some of you are thinking, with a smirk and an eye-roll, “You poooooor guy, having to actually read something!!”

We are not trying to eliminate reading or trying to remove humans from the engineering process. Reading an engineering document can be compared to reading a story, except that this story is about requirements, tables, graphs, equations, test methods, parts, materials, processes, relationships to other documents, dependencies, and more. Reading a long, technically complex story just to find one small piece of data, or only to be sent onward to another referenced document is a time-consuming and tedious process. If machines could do it reliably and accurately, wouldn’t we prefer that? Furthermore, one of the most wasteful aspects of the current use patterns of engineering documents is that readers all over the world duplicate the same tasks over and over. Right now, there are likely a dozen people reading standard A123 and seeking an answer to the same exact question. In many cases, the question has already been answered many times by other people undertaking the same task, possibly even by someone in the same organization. There is no option to reuse the information gleaned by others and no option to automatically extract just the information you need without reading a large section of the document. If you take this micro-example and multiply it by the legions of engineers and technicians doing this work around the world, you can see how inefficient it is to use documents in PDF format.

LEGO: the ultimate reusable building block.

A Solution: Documents as Digital Models

Recall our definition of a digital model: “a virtual representation of a real or imagined object that describes the structure, context, and behavior of that object.” Similarly, we can define the structure, context, and behavior of a document (and its individual data elements), and use that intelligence in many useful ways.

Structure. Although a document does not have a physical structure per se, it has sections containing labeled subject matter, table of contents that define the overall content, and tables and figures each of which illustrates a topic, references, and requirements. We can develop standardized ways of presenting and labeling these structures so they can be understood and acted upon by machines and software.

Context. Using AI and semantic models, we can make useful inferences about the purpose of the document. We can infer what parts, materials, and processes are addressed, the qualitative and quantitative values given, and even where in the product development lifecycle the document and its data are most useful.

Behavior. Based on the data in the document, we can describe how this document and its individual data elements relate to every other document and data element in the product development lifecycle, what references and dependencies exist, what test methods are required, and more. If the document were able to speak to you, it might tell you that it’s a member of the MIL Spec screw thread family, that it is only applicable for non-ferrous metals, that it has 14 other dependent references, that it is relevant to three of your products on the market and two under development, and that it is invalid for use after December 31, 2021. A human being might take hours to determine all that information on their own (not including nap time).

A digital model document has defined structure, context, and behaviors.

SWISS Digital Models Tell a Story

When we combine the structure, context, and behavior of a document, a story emerges which can be used to inform, improve, and automate the product development lifecycle. We can develop actionable intelligence and deliver answers to users on-demand, or even proactively based on the task at hand.

For example, if a machine operator is drilling a hole and finishing the surface, the precise instructions can be delivered to them based on the material, the purpose of the hole, and the finish spec ordered by the customer. These instructions may be contained in multiple documents related to drilling, finishing, threading, and testing, but when converted to digital models, the required data elements (whose individual meaning and context is understood by the system) can be gathered together automatically and delivered as one coherent set of instructions. From unstructured data comes structure and intelligence.

As another example, a contract manufacturer may receive a large set of specifications and instructions from a customer. The normal process is for a team of estimators to review the entire set of documents and determine the requirements, the process steps, the parts and materials needed, and the cost (among other priorities). Several companies have stated that this process can take up to 30 hours per document and is prone to human error. An AI-enhanced system that is analyzing the customer’s specs as digital models can quickly determine the parts and materials necessary, any overly-expensive requirements, long lead-time items (like castings and forgings), equipment and time needed to deliver the product, obsolete references, hazardous materials, opportunities for additive manufacturing, and more. The result is a better, faster, and more accurate quote with less of the team’s time.

Change Management Made Easy with Digital Models

Let’s go back to the aircraft example from Part 1. Standards and requirements are changing frequently and when those changes are communicated within PDF files, it creates tedious manual labor to “follow the breadcrumbs” and assess the impact of those changes on products and processes. However, if the authoritative changes are distributed in a machine-readable format (like a SWISS digital model), then an AI-enhanced system that uses semantic reasoning (like the SWISS platform) can automatically highlight changes from the previous versions, determine how the changes impact product development, specify the parts, materials, and processes affected, and prescribe the steps needed to implement the changes.

A well-trained system could even raise red flags for potential pitfalls such as hard-to-find parts or materials, long lead-time components, hazardous materials, regulatory requirements, price spikes in specified parts, and much more. Engineers, designers, maintenance technicians and anyone else working on the aircraft can be notified instantly of changes that impact their specific area, and they can see those changes reflected automatically in the digital twin. The use of AI, semantic reasoning, and machine-readable digital models can shave dozens or hundreds of hours off a project and significantly reduce human errors.

Capabilities, Wow

When documents shift from flat-text artifacts to digital model data, a whole new world of capabilities emerges. For example:

• AI Linking – Rather than click reference links from document to document and ending up at the top of each document, an AI-enhanced system can analyze the context around the links and direct the user to the exact piece of data in the referenced link. Rather than wading through pages and pages of data to find what you need, AI can take you where you need to go.
• Reference Network – Since the system sees all the relationships between documents and data, the system can list for you all the related references, and even draw a map of the network of relationships.
• Requirements Extraction – AI and semantic ontologies can be used to automatically identify and extract all the requirements in a document or a web of documents, and classify them according to subject, importance, parts/materials/process, etc.
• API Queries – Digital model data can be queried using simple API calls from other applications. For example, a PLM (product lifecycle management) system could query for any obsolete references related to a set of documents. The results could display instantly in the PLM interface.
• Reusable Digital Data – Rather than copying/pasting content from one place to another (a very common and tedious task), users could “drag and drop” linked digital data elements into applications like MS Word, PowerPoint, and others, while maintaining the authoritative fidelity and maintaining the link to their authoritative sources. When changes occur at the source, they can be communicated to anyone using that piece of data, anywhere in the enterprise. In SWISS, we call this process “transclusion” and we’ll talk about it much more in a future post.
• Machine Readability – As described in many examples here, digital models can be machine readable which means that machines (software) can read, interpret, and even take actions based on the information. Again, let’s not remove humans from the loop, but let’s enable machines to do what humans cannot, which frees up more time for humans to do what machines cannot.

SWISS AI and semantic reasoning can decompose unstructured data into structured machine-readable text.

• CAD Model Intelligence – Engineering drawings often contain references to standards and other engineering documents. An AI-enhanced system with knowledge of those references could provide valuable inferences about the drawings such as the related parts, materials, processes, the opportunities for additive manufacturing, and more.

• HAL 9000 or Jarvis, You Choose – Ultimately, we may reach “engineering nirvana” where humans direct AI to provide the intelligence we need to make better decisions faster and then to execute decisions at our command. IronMan relied on Jarvis for all sorts of data and intelligence and he trusted Jarvis with his life. Whether you trust AI or not, it’s hard to argue with the vision of using technology to reduce duplicative non-value-added work, shorten cycle times, and mitigate risk. (BTW, you don’t have to remind me that HAL 9000 was not trustworthy 😉

A Final Analogy (for You and Your Grandma)

I once explained SWISS digital models to my 80-year old mom as being like 3-D glasses. When you go to a 3-D movie, those funky glasses enable you to see a world that you wouldn’t see otherwise. If you take the glasses off, the exact same information is there on screen, but your brain doesn’t have the tools to process it. When you overlay SWISS on top of complex engineering documents, it provides intelligence and capabilities that you wouldn’t get otherwise. It changes the entire experience. And since that experience hasn’t changed much since the mid-90s, we think it’s time. Will you join us?

The Secret Meatloaf

Hopefully, you read all of Part 2 and didn’t just skip right to the secret meatloaf. My son does that during movies and it kills me! As promised in Part 1, the secret parts, materials, and processes of my meatloaf are:

• Caramelize the onions with butter and garlic, then add to the ground beef.
• Add 1 Tbsp Gochujang sauce for a flavorful kick. If you’re averse to the kick, substitute ketchup.
• Cook about a dozen cherry tomatoes in olive oil, garlic, and salt until the tomatoes start to pop, the garlic is soft, and the smell is incredible. Puree this mixture and add to the ground beef (or add without pureeing).
• Halfway through cooking, mix 1 tbsp of your favorite BBQ sauce with 1 tbsp of mayonnaise. Yes, seriously mayonnaise. Glaze the top of the meatloaf with the mixture (learn why mayo is nearly the perfect marinade and glazing ingredient).
• Cook until the top is browned and crispy.
• Mmmmm!

What is a Digital Model?

What is a Digital Twin?

Physical Twins Can Update Their Digital Twins

Here’s the Rub (and the Pain)

Throughout a product development lifecycle and over the course of a product’s lifetime in-the-field, the producer or owner must manage a long list of varied and changing requirements distributed across multiple authoritative sources from inside and outside the enterprise. Knowing what those changes are and knowing how they impact their product or operation is a dual task called change management and impact assessment. A related process of identifying requirements for implementation is often called requirements management.

For example, when Eastern Airlines orders a plane with the upgraded landing gear, or when a new standard is published that affects a product under development, the changes can affect dozens or hundreds of parts, materials, or processes, and require significant design and engineering modifications downstream. Since the mid 1990s, these changes have been published most commonly as PDF documents. It may be a single standalone document or an entirely new specification summarized in a TDP (Technical Data Package). One technician can spend hours or days wading through PDF documents, identifying the changes, assessing their impact on relevant areas of the business, and communicating the modifications to appropriate teams, usually by copying/pasting the new requirements into new documents like work instructions, assembly instructions, internal corporate specifications, and more. The time, knowledge, and seemingly bottomless patience required for this task is monumental. As a result, the process of change management, impact assessment, and requirements management are often saddled with long delays, duplicative work, and human errors.

In an ideal world, we would automate these tasks and teach software and machines to do the work. Imagine a machine that could analyze engineering documents and industry standards and not only highlight changes from the previous versions, but provide intelligent instructions on how the changes impact product development, and prescribe the steps needed to accomplish the changes. A trained machine could even raise alarms for potential troubles down the road such as hard-to-find parts or materials, long lead-time components, hazardous materials, regulatory requirements, price spikes in specified parts, and much more.

Unfortunately, PDF documents are not machine readable so the automation scenario is not widespread and requires significant software training. To a machine, the text, tables, graphs, images, and equations contained in PDF documents are merely characters laid out in random order, without context and meaning. Furthermore, nearly every author of an engineering document lays their characters out in different ways. Industry standards in particular are highly unstandardized, but this problem also exists among OEMs and suppliers across any one particular industry. (The aerospace industry has challenged its members to develop a standardized model of digitally compatible information, outlined in a paper by AIA’s Future of Aerospace Standardization Working Group (FASWG).)

We can teach machines to read PDF – something that is already underway in the SWISS platform – but a much more efficient solution is to transform documents from flat “dead-text” artifacts into intelligent digital models that describe the structure, context, and behavior of the information contained therein.

So What Now?

By now, I hope you are salivating at the potential benefits of transforming engineering documents into a format compatible with digital models and the Digital Thread. But if you’re not, don’t worry, we’ve laid it all out in Part 2 of this article.

Part 2 will show you how the concepts of digital models can be applied to engineering documents, industry standards, product engineering, change management, and requirements management, resulting in lower costs, faster cycle times, and reduced risk.

And of course, you’ll learn the secret ingredients in my meatloaf 😉

A team from XSB including CEO, Rupert Hopkins, board member Bob Solomon, and Andrew Bank won the award for best paper in the 2022 World Standards Day paper competition. Their paper, entitled “The Next Generation of Engineering Standards: A Proposal for Digital Transformation”, addresses the shortcomings of legacy PDF engineering documents and industry standards and proposes a technical solution to benefit all parties involved including standards developers, enterprise software providers, standards end-users, manufacturers, and others involved in the engineering supply chain.

Their solution, called digital twin documents, builds on the familiar concept of the model-based enterprise. Digital twins were born during the 1990s as 2D part drawings were transformed into 3D CAD models, resulting in dramatic productivity improvements in design and manufacturing.

A digital twin document is a standardized data-centric representation of a flat-text document in which each of the data elements — such as text, tables, graphs, equations, images, requirements, and more — are transformed into individual, interoperable, and reusable data points, connected in a network of references and related concepts. These data points are aware of their position in the network, their status (active, inactive, superseded, etc.), and their relationship to other data points, and can therefore communicate to end users about changes and the impact of those changes on other parts, materials, or processes. SWISS digital twin documents are structured sets of data that are machine readable and even machine interpretable. The authors believe that in the near future, engineering documents and industry standards will be read and interpreted as much by machines as by humans.

Digital twin documents can enable a new world of capabilities and value-added benefits that are impossible to achieve with PDF files and like their CAD counterparts, they will jumpstart another massive wave of productivity gains.

You can read the full paper in the Standardization Journal at the link below. Please share it with your colleagues and let us know your thoughts.

Read the full paper here.

The World Standards Day Paper Competition is sponsored by SES – The Society for Standards Professionals.