Last issue, we built the intake valve, the first refining station where product identity enters the system. We installed the filter: category confirmation, unit of measure governance, UPC capture, vendor designation, and intent classification. If that station is running, the organization knows what a product is, how it’s described, and what it’s intended to be.

Now comes the question that determines whether that product is allowed to go anywhere at all.

The second refining station is Regulatory Data. It is not a processing step. It is a gate. Nothing should move past it without clearance; not a shipment, not a sale, not a line item on a website.

If SKU Definitions answer “what is this thing?”, Regulatory Data answers the question that immediately follows: what are we allowed to do with it?

Where can it be sold? How can it be transported? Are there restrictions on who can buy it, where it can be stored, or what documentation has to travel with it? Does the organization have a legal obligation to meet before this product touches a customer’s hands?

A quick distinction on language, because this piece uses two terms that are related but doing different jobs. Regulatory refers to the external requirements imposed by governments, trade bodies, and jurisdictions. What the rules are. Compliance refers to the organization’s ability to meet those requirements. Whether you’re satisfying the rules. The station holds regulatory data, because that’s what the data describes: external obligations. The gate checks compliance, because that’s the function it performs: confirming the organization can meet those obligations before a product moves forward. One is the input, the other is the checkpoint.

The specific data elements at this station include Country of Origin, hazmat classification, Safety Data Sheets (SDS/MSDS), selling restrictions (both geographic and regulatory), and regulatory frameworks like Prop 65, RoHS, REACH, SCIP, and Conflict Minerals reporting. Whether these apply to a given product depends on what that product is and where it’s going, which is exactly why this station comes second in the sequence. You can’t assess the regulatory profile of a product whose identity isn’t stable. Category and supplier information from Station 1 tell you which regulatory questions even need to be asked.

A solvent requires hazmat classification, an SDS, potentially Prop 65 and REACH assessment, and shipping restriction documentation. A fastener requires RoHS certification, or at minimum a company declaration that the product meets RoHS standards, plus Country of Origin documentation. Even the categories that seem simple carry regulatory obligations. The category doesn’t just organize the catalog. It activates the regulatory requirements.

An honest framing on urgency is worth getting out of the way early, because this station’s intensity varies more than any other in the refinery. If you’re a US-based distributor selling domestically within the continental United States, your regulatory burden here is relatively light: state-level requirements like California’s Prop 65, some basic hazmat classification, maybe some restricted chemical handling. The regulatory overhead between state lines is manageable for most product categories.

That picture changes the moment the organization starts expanding. Once you’re sourcing product from overseas, selling into international markets, or serving customers who are importing across borders, the regulatory landscape multiplies. Different governments, different trade agreements, different environmental standards, different reporting requirements. A product that moves freely within the domestic market may need entirely different documentation to cross a border. And every new territory adds another layer.

The station is second in the sequence because the inputs are available and the logic is sound. Category and supplier data from Station 1 give you everything you need to start assessing regulatory requirements. But the depth of investment this station demands depends on where the organization sells. For a domestic-only distributor, this may be a lighter station early on. For a company going global, or one that’s already there, this station becomes one of the most operationally demanding in the entire refinery. The process should be in place either way. The intensity scales with your footprint.

As supply chains globalize, the distributor’s role becomes a regulatory one on top of a logistical one. Customers don’t want to figure out compliance themselves. They expect their supply chain partners to have already figured it out. When a customer asks whether a product can ship to a specific region, whether it meets a particular environmental standard, or what documentation needs to accompany the shipment, they expect an answer. And they expect it to be correct. The distributor who can answer those questions confidently becomes a strategic partner. The one who can’t becomes a risk the customer has to manage around.

Both the manufacturer and the distributor carry responsibility here. Manufacturers originate the data. They know the composition, the certifications, the regulatory status. Distributors carry the obligation to capture that data, keep it current, and apply it correctly across every market they serve. Neither side gets to point at the other when something goes wrong. The regulatory exposure belongs to whoever is holding the product when the question gets asked.

There’s also a timing argument that most organizations miss. The sooner regulatory data enters the product dataset, the sooner the organization understands what it’s dealing with. Most freight classes, shipping restrictions, and storage requirements are derivable from the category a product sits in, and the manufacturer has that information available. Getting it early, immediately after SKU identity is established, tells the business how much it needs to invest in managing each product before resources get committed to enrichment. The alternative is enriching a product fully and discovering its regulatory constraints late; wasted effort on a product you didn’t fully understand how to move, store, or sell.

Most organizations get the sequencing wrong here because regulatory teams are often formalized after the product creation and enrichment process is already running. The business builds around volume and sales growth, and regulatory gets layered in later, often dealing with products that are already enriched and in-market. This framework positions regulatory as Station 2 because the inputs it needs are already available from Station 1. There’s no practical reason to wait.

In a perfect world, every product would be fully cleared before it ever transacts. Practically, that would bottleneck the 99% of legitimate sales that can proceed without issue. The model is not to hold up the business; it’s to ensure that regulatory follows immediately after product creation. Not months later as an afterthought. The intake valve lets fuel into the system quickly so the business can serve the customer. The compliance gate checks that fuel right away.

There’s also a locality dimension here that plants a strategic seed most organizations don’t anticipate. Regulatory data is tied to place; where a product originates, where it can be sold, where it can’t, and how it moves in between. Maintaining locality tables that connect products to the regions they can and can’t serve starts tying the product dataset to the customer and sales dataset earlier than most organizations expect. That intersection creates visibility into expansion opportunities: which existing products can reach new markets, and which existing customers might need products the organization already carries but hasn’t positioned for them yet. We’ll come back to this in a later issue, but the seed gets planted here at Station 2. Regulatory data doesn’t just protect the business. It starts teaching the business where it can grow.

When this station is healthy, nobody thinks about it. Products move, shipments clear, documentation is there when someone asks for it. When it’s not healthy, the failures tend to be sudden, expensive, and occasionally legal. Regulatory problems are silent right up until they aren’t.

A hazmat product shipped without proper classification gets flagged by the carrier. A product crossing a border without accurate Country of Origin documentation gets detained at customs. These aren’t data quality inconveniences; they’re operational shutdowns with real cost. The shipment doesn’t move. The customer doesn’t get their product. Someone scrambles to produce the documentation that should have been in the system before the order was placed. And the next time that customer has a choice between two distributors, they remember which one couldn’t get a shipment through.

Selling restriction violations tend to be quieter and more dangerous. A product restricted under Prop 65 gets sold in California because nobody flagged it. A product with geographic limitations ends up on the website, available to anyone with a shipping address. The organization discovers the gap when the fine arrives or when a customer receives a product that shouldn’t have been sold to them.

When a customer requests a safety data sheet for a chemical product and the organization can’t produce it, or produces a version from three years ago, the damage goes beyond compliance. In regulated industries, that’s a compliance failure. In the customer’s eyes, it’s a competence failure. If the distributor can’t produce basic safety documentation, what else are they getting wrong?

The globalization trap catches companies that have been selling domestically and start expanding into new markets. They discover that their regulatory dataset was built for one jurisdiction. Products that were fully compliant at home now have gaps: missing certifications, undocumented restrictions, regulatory markers that don’t exist in the current dataset because they were never needed. Every new market reveals another layer of requirements, and the competitors who already have this data captured are the ones winning the business in those markets.

Underneath all of these failures is the “it’s the vendor’s job” trap. Organizations treat regulatory data as something the manufacturer should provide. And they should. But when they don’t, or when what they provide is incomplete, outdated, or in a format that doesn’t fit, the distributor is still the one holding the liability. The customer isn’t going to hold the manufacturer accountable for the distributor’s failure to capture a hazmat classification. The regulatory body isn’t going to fine the supplier because the distributor’s website didn’t display a required warning. The vendor’s failure becomes your exposure, every time.

What makes regulatory gaps particularly frustrating is that they hide. Unlike SKU Definitions, where duplicates and inconsistencies are visible when you pull a product line, regulatory gaps sit quietly in the system. The product has a clean description, a correct unit of measure, a proper category assignment. Everything looks healthy. But nobody knows whether it requires a safety data sheet, whether it has a selling restriction, or whether the Country of Origin on file is still accurate. Those gaps stay invisible until a specific transaction, a specific customer, or a specific regulatory body surfaces them. By then, they’re already a problem.

Without the compliance gate functioning, unchecked products flow into every downstream station. Operations doesn’t know what requires special storage. Fulfillment doesn’t know what has shipping restrictions. Marketing doesn’t know what can legally be promoted in certain markets. The gate was never closed, so everything that entered at Station 1 passes through Station 2 unexamined and carries its regulatory unknowns forward.

If you read the previous issue on SKU Definitions, this structure will feel familiar. The intake valve needed a filter to turn raw material into usable fuel. The compliance gate needs its own filter to assess what can and can’t move through the rest of the refinery.

The filter here works differently than the one at Station 1. At the intake valve, the filter was a set of sequential governance layers: category confirmation, then UOM standards, then UPC capture, and so on. At the compliance gate, the filter operates more like a rulebook with toggles. The category tells you which rules apply. The rules themselves are regulatory data requirements that get activated, or don’t, based on what the product is and where it’s going.

Every other requirement at this station depends on this foundation. When a product is correctly categorized at Station 1, that category tells you what regulatory questions need to be asked.

A solvent category activates hazmat classification, SDS requirements, potentially Prop 65, REACH, and shipping restriction documentation. A fastener category activates RoHS certification requirements and Country of Origin. An electrical components category may activate RoHS, REACH, and Conflict Minerals reporting. A basic hand tool category might only activate Country of Origin.

Building a regulatory profile at the category level, a defined set of which regulatory requirements apply to products in that category, means the organization isn’t starting from scratch for every individual SKU. The category does the heavy lifting. The product-level work becomes confirmation and capture rather than discovery.

Think of it as a matrix. Categories down one side, regulatory requirements across the top. For each category, specific requirements are toggled on or off. When a new product enters the system and gets categorized, its regulatory profile is already waiting. The team knows what data needs to be captured, what documentation needs to be sourced from the manufacturer, and what can be marked as not applicable.

Each regulatory requirement in the profile is a toggle that gets activated by the category. Here’s what each one looks like in practice.

Country of Origin. Required for international trade, directly affects tariff classification, and in some cases determines whether the organization can legally transact at all. Sanctions are the sharpest example: a product originating from a sanctioned country can’t be sold in certain markets regardless of what it is. Tariff fees are the financial side; the Country of Origin determines duty rates that hit the P&L directly. The manufacturer knows this information. It should be a required field at or immediately after product creation. If the vendor provides it, capture it. If the vendor doesn’t, flag the gap and make it a condition of the next data exchange. This is not a field that should get backfilled six months later when someone tries to ship internationally for the first time.

Hazmat classification and documentation linkage. Products classified as hazardous materials require specific handling, shipping, and storage protocols, but the toggle here goes beyond whether a product is hazmat. It’s about connecting the classification to the systems that act on it. The warehouse management system needs it for storage location decisions. The carrier integration needs it for shipping documentation. The order management system needs it for handling surcharges or shipping method restrictions. A hazmat flag sitting in a field that nobody reads is data. A hazmat flag connected to the warehouse, the carrier, and the order flow is a capability.

SDS/MSDS capture, versioning, and accessibility. Safety Data Sheets are living documents. Manufacturers update them as formulations change, regulations evolve, and new hazard information comes to light. The toggle activates for any category where products may require safety documentation: chemicals, solvents, adhesives, cleaning products, and others. The requirement goes beyond initial capture into ongoing maintenance: when a supplier provides an updated SDS, it replaces the previous version, not sits in someone’s inbox. The current version needs to be stored, versioned, and accessible to customer service, the website, the sales team, and the warehouse. On demand, without a scramble.

Selling restriction mapping. Selling restrictions operate at the intersection of product and place, and this is where locality tables come into play. Which categories can’t go to which regions? Which products require specific disclosures in specific markets? A Prop 65 restricted product shouldn’t be sellable in California without proper disclosure, regardless of which branch processes the order. A product banned in the EU shouldn’t appear on a website serving European customers.

The governance here needs to operate at two altitudes. At the regional level, broad restrictions can be applied near the point of creation, wide enough to let local markets serve their customers without friction. A branch in Texas doesn’t need California-specific restrictions slowing down counter transactions. Product-specific restrictions layer on top as the regulatory team completes its assessment.

The locality tables themselves become the filter that a business owner has to manage: which categories to which locations, which products carry which restrictions in which markets. Those tables connect the product dataset to the organization’s sales geography, and they need to be maintained as both the product catalog and the selling footprint evolve.

Regulatory certifications (RoHS, REACH, SCIP, Conflict Minerals). These toggles activate based on category and selling region. A company selling electrical components into the EU needs REACH and RoHS data. A company selling domestically in the US may not need it today but will need it the moment it starts serving customers who export. The certification data typically comes from the manufacturer, either as specific test results or as company-level declarations of compliance. Capturing it at the category level means the organization knows which certifications to request from each vendor, rather than discovering the gaps one product at a time.

Supplier regulatory requirements. This toggle is about the organization’s relationship with its vendors. What regulatory data is the supplier expected to provide as a condition of doing business? In what format? What happens when it doesn’t arrive?

Most distributors have some version of a vendor onboarding process. The compliance filter extends that process to include regulatory data as a non-negotiable component. A vendor that can’t or won’t provide SDS documentation, Country of Origin, or applicable certifications is a vendor that’s transferring regulatory risk to the distributor with every product it supplies. Leadership needs to decide whether that’s acceptable.

The category regulatory profile is the rulebook. The individual data requirements are the toggles. When a product enters the system and gets categorized, the rulebook tells the regulatory team (or the data team, depending on who owns this) exactly what needs to be captured, sourced, and validated. Nothing more, nothing less.

Instead of treating every product as a blank slate that might need anything, the category narrows the scope immediately. A product in a low-regulation category might only need Country of Origin verified. A product in a high-regulation category might need six or seven toggles addressed. The rulebook makes that determination automatically based on what Station 1 already established. That’s what keeps the work manageable.

As with the intake valve, “good” at this station is not a fully audited, perfectly compliant catalog where every regulatory data point has been verified across every jurisdiction. That’s the destination. Good means the organization has built the infrastructure to manage regulatory data as a continuous capability, and it knows where its gaps are.

Every product has a regulatory status, even if that status is “not yet assessed.” The absence of data is documented rather than invisible. The organization can query the catalog and immediately identify where gaps exist: by category, by vendor, by product line, by region. The gaps aren’t hidden inside individual product records waiting to surface at the worst possible moment.

Hazmat classification is captured and connected to operational systems. The warehouse knows what requires special handling. The carrier integration generates proper documentation. The order system applies handling restrictions. This happens by process, not by someone remembering which products are hazardous.

SDS documents are stored, versioned, and accessible. When someone requests one, the organization can produce the current version without delay.

Selling restrictions are defined at the product level and enforced at the point of sale: counter, phone, and website. A restricted product doesn’t appear where it shouldn’t. A product requiring disclosure includes the disclosure. The system carries the restriction. The salesperson executes the transaction.

The organization has a defined process for onboarding regulatory data from suppliers: what’s required, what format it arrives in, and what happens when it doesn’t. Governance at the point of entry.

And regulatory data is treated as a living dataset. Regulations change. Products get reclassified. New markets bring new requirements. The organization has a mechanism for monitoring and updating, even a simple one.

Regulatory is the stage most likely to live in organizational limbo. It doesn’t drive revenue conversations. Nobody walks into a quarterly review excited about Prop 65 status. And because the data originates with suppliers rather than being generated internally, it’s easy for leadership to treat it as someone else’s problem. But the liability sits with the organization regardless of who was supposed to provide the data.

Leadership’s job here is to make sure regulatory data has an owner. Not someone who personally verifies every product, but someone accountable for the process, the standards, and the gaps. In a lot of organizations, this ownership is genuinely unclear. It might sit with procurement, a compliance function, the product data team, EHS, or nobody at all. The specific answer matters less than the fact that an answer exists and everyone knows it.

Here’s where this gets messy in practice. In a lot of organizations, the people who determine regulatory rules and the people who manage product data don’t talk to each other. Regulatory and compliance sit within the legal entity, completely disconnected from the product data lifecycle. They determine rules and business conditions, but they don’t participate in how product data gets created, enriched, or maintained. When those teams operate in isolation, the result is predictable: requirements get handed off without context, the data team treats them as an interruption rather than an input, and nobody is invested in improving the process. It becomes a dump-and-run situation; compliance mandates arrive, get grudgingly applied, and the underlying process never gets better. If you’ve seen this dynamic in your organization, you’re not alone. It’s one of the most common and most frustrating dysfunctions in B2B data management.

Fixing it requires direct participation. Whoever determines regulatory rules needs to be connected to whoever manages product data. In some organizations, that’s the same person or team. In others, it’s a relationship that has to be built deliberately. Either way, the regulatory function needs to understand how data flows through the product lifecycle, and the data team needs to understand why specific regulatory requirements exist and what triggers them. Without that connection, both teams stay frustrated, and the gaps persist.

When this station fails, the cost tends to hit all at once. Fines, shipment holds, customer trust damage, legal exposure. When it’s running, the cost of maintaining it is modest; just part of the regular cadence of data management. Think about this station the way you’d think about insurance. The investment feels excessive when everything is running smoothly. The absence of it feels catastrophic when something goes wrong.

This area of data management is also not shrinking. As supply chains globalize, as regulations evolve, as new reporting requirements emerge, the regulatory dataset grows. Every new market brings new requirements. Every regulatory update means existing products need reassessment. The organizations that build the infrastructure now can scale into new markets without regulatory data becoming the bottleneck. The ones that don’t will find their growth outpacing their compliance readiness.

Regulatory teams too often get put in place after the product lifecycle process has already been defined. They inherit a system that wasn’t built with them in mind and are asked to retroactively govern products that are already enriched and in-market. The most impactful move leadership can make at this stage is to position regulatory upstream: as a gate that operates immediately after product identity is established, not a function that audits after the fact. Station 1 gives you identity. Station 2 gives you clearance.

Pick one product category that you know contains products with regulatory implications: hazmat items, chemical products, items with known selling restrictions, products you ship internationally. Pull the active SKUs in that category and evaluate them against five questions.

First: Do you have a documented Country of Origin for every SKU in this category? Is it current?

Second: Are hazmat classifications captured at the product level and connected to your shipping and warehousing systems, or are they managed through tribal knowledge and manual lookups?

Third: Can you produce a current Safety Data Sheet for every product in this category that requires one? Right now, without a scramble?

Fourth: Are selling restrictions defined at the product level and enforced systematically (at the counter, on the phone, and on the website), or do they depend on individual salespeople knowing the rules?

Fifth: Do you have a defined process for what happens when a vendor doesn’t provide the regulatory data you need? Or is the gap simply accepted?

Five questions, one category. What it reveals is whether your compliance gate is functioning or whether unchecked products are flowing into the rest of your operation without anyone knowing what they’re allowed to do with them.

Once you can trust what a product is and whether it’s cleared to move, the next question is physical: how does this thing get stored, picked, packed, and shipped?

Next issue, we move to the third refining station: Operational Data. Dimensions, weights, packaging, and logistics data. It’s where the gap between “we have a product” and “we can fulfill an order” either closes or becomes painfully visible.