IPC-1751 Builds Supply Chain Infrastructure for the Future

Estimated reading time: 6 minutes

IPC-1751 Committee Chairs Nikki Johnson, VP of operations and regulatory at Source Intelligence, with over 20 years of experience in compliance standards, and Dr. N Nagaraj, a chemical engineer and former NASA contractor who helped develop early IPC compliance solutions, discuss IPC-1751, the newly adopted JSON-based standard that replaces the older XML format. In this roundtable-format conversation, Johnson and Nagaraj explain how IPC-1751 serves as a modular "envelope" that connects related standards (IPC 1752–1757, IPC-1782) for material composition, lab reports, and conflict minerals. They explain how the shift to JSON improves accessibility and AI readiness, and how better data traceability could strengthen supply chain security and CMMC compliance.

Nolan Johnson: Let’s start with understanding how IPC-1751 was developed and how it fits into the larger family of standards.

N Nagaraj: IPC-1751 is the basic business information exchange, and within that, there are other standards for the actual material composition, process chemicals, and conflict and other metals and minerals. All those standards are brought together by the new 1751 revision.

We solicited input from everyone, especially people with deep domain expertise, including Chuck LePard, Nikki Johnson, and Brenda Bailey, as well as many electronics companies.

Nikki Johnson: IPC-1751 is the envelope, and you can put any number of declarations or data that you want in that. On the product compliance side, IPC-1751 is the piece that will be shared amongst these other standards.

IPC-1751 tells you which company is requesting the data, from whom they are requesting it, which parts are included in the request, and what type of data is being requested. IPC-1751 encompasses the data about the product for which you're trying to get data, who you're trying to get it from, who's responsible for that data, who's the contact, and who's the authorized representative.

The data in IPC-1751 is then shared with every other declaration you attach. By moving to JSON and making it modular, we've made it easy to attach different information.

For example, you start at IPC-1751, where you define the product for which you want to provide information. Then, via 1752, you give product compliance information, including a full material declaration and hazardous substances. With IPC-1753, you can attach a lab test report in JSON format and embed a PDF. This all supports the compliance declaration you input. Next is IPC-1755, where you attach the conflict minerals information. If you have chemicals related to the process, IPC-1757 pulls in that data. At this point, you have a complete set of product compliance, including evidence to back it up.

Now we can turn our attention to the first set of standards outside our 175X family to use the IPC-1751 envelope for reporting their data: IPC-1782, the traceability standard. Now you start to see how this data could travel throughout the supply chain. Design data from IPC-2581 could be included as well.

Nolan Johnson: I'm glad you brought up IPC-2581 because your descriptions don’t seem to include design data, just manufacturing data only?

Nagaraj: IPC-2581 specifies some of the schema that represents the intelligent data file format used to describe PCB and board assembly products with details sufficient for tooling, manufacturing, assembly, and inspection. The format may be used for transmitting information between the designer and manufacturer. It's most useful when manufacturing cycles include computer-aided processes, etc. The designer gives a 2581 file to the manufacturer, whereas IPC-1751 is more about the material composition and how the information flows across the supply chain for compliance and other requirements.

Nolan Johnson: Is IPC-1751 working with the entire manufacturing supply chain, taking that design and effecting it into an actual product?

Nagaraj: It's more focused on the material content. There is manufacturing information presented in IPC-2581, but that's to confirm the product is, say, lead-free, and these were the processes used to ensure it.

IPC-1751 focuses on compliance, content, and traceability. There's an IPC-1782 traceability standard that will attach to the IPC-1751 by specifying information like, “You have given me IPC-2581, and I followed it.”

Nikki Johnson: Our number one goal in developing this standard is to normalize the data within the supply chain to make it easier to flow, potentially enabling hands-off processing.

Having done this for 20 years, I can tell you every supplier provides their data a little differently. As a supplier responding to customer requests, you may get 20 different formats that your customers want you to fill in. Each customer has their own specialized templates and formats, and that puts a burden on the supply chain. The data needs to be normalized so it can easily flow B2B with no human involvement.

Twenty years ago, with no AI to do it for you, all this required a human to take the data for each component off the form, put it into a system that could then roll it up to the top level in your bill of materials, so you could determine the compliance of your product. To enable data to flow within the supply chain and roll it up in your own PLM or compliance systems, it has to be normalized. It’s much easier to relay information when everyone is speaking the same language.

Nolan Johnson: Which begs the next question: Why now?

Nikki Johnson: It's the natural progression of the standard. This isn't new to us; it's just a revision that adds new features and changes the format.

It started as a human-readable PDF, with XML backing it up so you could export from it. That structure became too big to maintain. IPC is a standards organization, not a template organization. So, we had to move away from that PDF in 2010 and adopt the XML standard exclusively.

Now, XML is great for B2B, which was one of our goals. But the other goal, to transfer the data within the supply chain, needs a human-readable format, which we didn’t have for the 1752A or B version of the standard. Those revisions were simply supported by XML. At that time, we intended the sectionals to be modular and to attach to one another, but in practice, nobody was doing that. It wasn't happening the way we intended with the XML.

With the shift to JSON, we've addressed many of those issues. First, the structure is completely modular. That’s good for our standards but also allows for other standards to join us and tag their information at the end. Even better, this new human-readable form/B2B form is both in a way XML couldn’t.

Finally, the connected factory initiative (CFX) is written completely in JSON. Now, when the compliance information comes in JSON, it fits in very well with the CFX initiative also. That's another reason we did it now.

Nolan Johnson: A major CMMC deadline was just pushed back, and one of the implications is in the supply chain, where contract manufacturers may not be aware that their component has a military application until they get a notification about certification. Could tracking this manufacturing provenance help automate and enable the supply chain to become aware that their product is being used in a way that requires CMMC certification?

Nagaraj: To put it directly, CMMC is not affected. But IPC-1751 does give you unique contact and business information, which is helpful. Information, however, doesn’t flow from downstream to upstream that well, especially when there's been a problem with these conflict minerals. You might identify a smelter that's not good, but because there are so many levels upstream, you don't know how to contact them to remove that smelter, as that node of the supply chain may be embedded more than a few levels upstream.

That’s the same thing here. If your product is used in a drone, for example, you can't do much about it, unless you have some kind of feedback from the supply chain.

Nolan Johnson: Does IPC-1751 further enable this information to move upstream? Much of our early discussion was about how the information would move downstream for compliance, components, chemicals, etc. Does it move back upstream? Is it a two-way street?

Nagaraj: Those are questions I've been grappling with for the past few days, mainly because I heard some customers asking the same thing: "I've got this one smelter, and it has to be removed, but I don't know which of my suppliers is connected to that chain.” We know that information is embedded somewhere, so what if you can send a request to your supplier, and they can send it to their supplier, and so on? I was thinking, "Why can't I have a query that, when it comes to me, AI decides it's not for me, it's for my supplier, and forwards it automatically?" There is a need for it.

Nikki Johnson: Consider that we've designed a format for data; we haven't necessarily defined or limited how that format can be used, or whether it can only be used upstream or downstream. We're focused entirely on the format and, to some extent, the content, and how it’s all structured. Our format could go upstream or downstream; it wouldn't matter, so long as you're correctly using the format.

Nagaraj: You're right. Going forward, your question, her answer, and my comment all lead to the possibility of further improving the standard, where we can also probably add, as an amendment, that rather than sending them queries, you're also able to send some kind of standard notification: “You need to do this or get rid of this smelter for me, or get rid of this substance in this part and get me a part without that substance.” If we can do that, that will be big. Your point does lead to something very constructive. We do need that.

Nolan Johnson: Great. We just established what will be in the next revision, didn't we? This has been an educational conversation. Thank you.

Nikki Johnson: Thank you, Nolan.