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.

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 😉

The United States Department of Defense manages one of the largest procurement budgets in the world. Of the department’s $700 Billion annual budget, more than $200 billion is spent on goods and services from contractors.1 Purchases run the gamut from aircraft carriers to combat boots.

There are enormous challenges in procuring this array of goods and services with the right level of quality and speed while stewarding taxpayer dollars. One branch of the Department of Defense, the Defense Logistics Agency (DLA), is turning to digital models from XSB to reduce the cost, time, and errors associated with PDF-based procurement.

Defense Logistics Agency

The Defense Logistics Agency, the nation’s combat logistics support agency, manages the end-to-end global defense supply chain for the five military services. DLA procures more than $46 billion annually across several supply chains: subsistence (food/water), clothing and textiles, bulk petroleum and other energy products, construction material and equipment, personal demand items, medical material and equipment, and repair parts for land, sea and air systems.

DLA’s Clothing and Textile department manages more than $1.3 billion in demand for nearly 5000 Clothing and Individual Equipment items. Consider, for example, the Army Combat Uniform (ACU). The ACU is a complex garment incorporating camouflage, chemical treatments, fire retardant, NIR Signature management technology, and permanent IR IFF squares for identification with night goggles–just to name a few features designed to keep our soldiers safe and healthy.

The Problem

The requirements to procure, manufacture and test the ACU are distributed across a web of related, but disconnected, technical documents including Specifications and Standards, Purchase Descriptions (PD), and other Technical Data Packages (TDP) with multiple Interim Changes. Product technical requirements are derived from documents authored inside (e.g., Military specs) and outside the Government (e.g., Non-Government Standards from ASTM, AATCC, and NFPA, etc.). These technical documents vary in age from thirty-year-old scanned PDFs, to more modern Microsoft Word and XML Documents. The purchase description for the ACU has references to 98 documents and 5053 pages from 13 document sources.

ACU Network of Requirements Documents
Different stakeholders including the military services, DLA Product and Contract Specialists, Government and industry testing labs, and suppliers to the government must find and use the requirements embedded in these documents. The documents are rich with technical information but were made for printing and reading. They are poor containers for technical data. They are not interoperable, and their uneven format makes it difficult for users to search, query, use, reuse, update, edit and manage. The problem is further complicated as different stakeholder groups establish multiple, independent collections of these documents on network drives, Microsoft SharePoint instances, on their local desktops, and even paper in folders.

Requirements in traditional documents are stored as static and disconnected objects, but they represent a dynamic web of concepts distributed across an ever-changing network managed by different authorities. The disconnected nature of a document-based approach makes tech data management difficult and can result in decisions based on inconsistent, incomplete, and out-of-date information. Different Clothing & Textile division stakeholders use the same information to perform different tasks during the product life cycle. A Product Specialist may support a military service by inserting contract-specific Interim Changes into an item requirement. In response, the manufacturer needs to alter a factory work instruction to ensure the finished product includes these changes. An industry test lab must change a First Article Test Plan to reflect the revised requirement. The DLA Product Test Center needs to know the impact of that change is reflected in manufacturer test reports. The problem with this disconnected document approach is that changes to one document are poorly communicated to other document stakeholders.

The Solution: TexSpecs

The DLA turned to XSB to help them create TexSpecs: “interoperable structured digital models of purchase descriptions, interim changes, and other specification-based technical documents which reduces the cost, time, and errors associated with PDF-based tech data management.”2

DLA’s transformation to a Model-Based Enterprise results in improved decision making and increased confidence that a design will perform as expected. This Model-Based approach enables users to query, edit, and analyze technical data that was previously locked in the document format. Linking the concepts within and between documents provides powerful change management and configuration control mechanisms. According to Deloitte, this approach can generate up to 65% process cost savings. It also helps DLA’s Clothing & Textile stakeholders avoid mistakes and rework resulting from decisions made with out-of-date information.

A Closer Look

XSB helped DLA convert documents from 13 different sources to interoperable, linked data models using Artificial Intelligence and semantic technology. The collection of these former documents, now models, is stored as a knowledge base, or graph, and is called the Digital Model Library (DML). The knowledge graph establishes a single, enduring, authoritative source of truth that captures the state, history, and relationships between tech data sources. Changes made to a document model in the DML propagate throughout all affected data and systems, ensuring stakeholders have accurate and up-to-date information. This Model-Based digital thread is the product DNA for the management of the associated clothing and individual equipment items. Digital models of Clothing & Textile documents provide many advantages over PDF documents:

consistent and instantaneous integration of Interim Changes
enhanced configuration management across stakeholders,
Automated and rapid analysis to ensure compliance with government procurement procedures and interoperability with other digital models from Government and Industry.
In addition, digital models can be exported as MS Word documents enabling the Agency to retain its traditional, document-based processes and workflows while undergoing digital transformation.

The knowledge graph, or DML, can be accessed by humans through a Web browser, or by machines and systems through a powerful Application Programming Interface (API). The DML now contains 146 Purchase Descriptions, 620 Government Specifications, Standards, and Commercial Item Descriptions, and 2130 Non-Government Standards from ASTM, AATCC, and others.

1 The Department of Defense (DOD) An Orientation November 12, 2021

2 DLA C&T Modernization Efforts with DLA MUST Program TexSpecs& SRP Tool Brief for Joint Advanced Planning Brief to Industry (JAPBI)