One Product Record, Many Decisions

Classification, customs, compliance, procurement, and AI agents look like five separate workflows owned by five separate teams. They are not. Every one of them starts from the same two questions about the same product: which exact product is this, and which technical facts about it can we trust. Get those two answers right once, with evidence attached, and each workflow becomes a projection of one trusted record. Get them wrong, and every workflow fails independently — a correct-looking HS code on the wrong variant, a compliance certificate for a part you do not actually sell, an agent that confidently updates the wrong SKU.

This is why a product-data layer is not another system to publish from. It is the shared substrate underneath the systems that already make decisions — and the reason the same two questions keep reappearing is that they were never a classification problem, a customs problem, or an AI problem. They were always an identity-and-evidence problem wearing five different labels.

The market is pricing this in

Three announcements in the first weeks of October 2026 point at the same substrate from different directions.

Schneider Electric agreed to acquire PTC on 5 October 2026 in an all-cash deal, explicitly positioning PTC’s industrial software and product data as the foundation of an industrial-AI strategy — treating the product-data layer itself as infrastructure worth tens of billions, not as a reporting detail. (The transaction is an announced agreement, expected to close in 2027, not a completed deal.)

A day later, at SAP Connect on 6 October 2026, SAP made its Autonomous Enterprise architecture and Joule agents generally available and promoted an International Trade Classification Agent, which SAP says cut trade-classification effort by up to 50% in early deployments. That figure is SAP’s own claim from early deployments, not independently verified — and worth reading alongside SAP’s 19 October target of 1,000 partner-built agents, which is an ecosystem roadmap goal, not a count of agents running in production. The direction is clear even with the caveats: classification and trade decisions are being handed to agents that can only be as right as the product facts beneath them.

And ECLASS announced a new aspect for Environmental Product Declaration metadata, slated for its upcoming Release 17, which structures information about EPD documents and complements the existing Product Environmental Footprint aspect. A sustainability document stops being a PDF nobody can query and becomes structured, validated attributes on the product.

Three moves — an acquisition, an agent platform, a classification standard — and all three assume the same thing exists underneath them: a trusted product record. Mostly, it does not.

One product, carried all the way through

Take a single industrial product and follow it. An industrial lithium battery module used as backup power inside automation cabinets — a real SKU with a manufacturer part number, a rated capacity and voltage, a chemistry, a datasheet, a safety data sheet, a weight, and a set of equipment it is approved to sit inside.

Five teams will touch this one module this quarter:

Each team believes it owns a different problem. In practice, the first column of their work is identical: establish which product this is, and attach the technical facts a decision can safely stand on. Only after that do the five decision logics diverge. The waste in most catalogs is that this shared first step is redone — differently, and with different errors — five times.

The source layer: evidence arrives messy

The facts about the battery module do not arrive as a clean record. They arrive as a supplier’s spreadsheet row, a manufacturer datasheet PDF, a safety data sheet, an ERP line, and a manufacturer web page — each with its own identifier, its own units, and its own idea of what the product is called.

No single source is authoritative, and none is complete. This is the normal state of a catalog, and it is the reason turning a spec sheet into a trusted product record is a pipeline, not a copy-paste. The source layer is where evidence enters; it is not where trust is created.

The trust layer: where a record is earned

Between raw sources and any decision sits the work that actually makes a record trustworthy. It is not one step. It is a sequence of distinct functions, each of which can fail on its own, and each of which has to leave a trace.

• Identity resolution decides which records are the same product. The supplier’s abbreviated SKU, the ERP’s internal material number, and the manufacturer’s part number have to resolve to one entity before anything else is safe. This is the step entity resolution is becoming infrastructure for AI agents argues must move into the execution path, not stay in a nightly pipeline.
• Extraction pulls the capacity, voltage, chemistry, and dimensions out of the datasheet’s prose and tables into fields.
• Normalization puts every value on a common footing — one unit system, one vocabulary — so 7.2 Ah and 7200 mAh are the same fact, not two.
• Evidence attaches, to each value, the document, page, and revision it came from. A value without a source is a guess with good posture. (See product data provenance.)
• Conflict resolution handles the datasheet and the SDS disagreeing — which wins, and why, recorded rather than silently overwritten.
• Confidence scores how strong the evidence is, so a weak value can be routed to review instead of published.
• Freshness tracks whether the evidence is still current — a capacity spec, an approvals list, or an EPD can all expire, and an expired fact is a stale state, not a trusted one.

Skip any one of these and the record is not trustworthy; it merely looks finished. The crucial property is that the trust layer is built once, for the product — not once per decision.

The canonical product record

What the trust layer produces is a single record for the battery module: a resolved identity linking every source, a normalized set of technical attributes, the evidence behind each value, a confidence score, conflict decisions, and freshness state. This is the canonical product record — the persistent object every downstream decision reads from. It is not a marketing description and not an ERP line. It is the trusted answer to “which product, and which facts,” held in one place so it cannot drift into five inconsistent copies.

Decision projections: one record, many logics

Now the workflows diverge — and this is the editorial line that keeps the whole idea honest: the record is shared; the decision logic is not. Claro does not claim one model makes every decision. One trusted substrate feeds domain-specific decision systems, each with its own rules, owners, and standards.

The classification projection becomes the ECLASS / ETIM mapping work; the customs projection becomes the HS / CN / TARIC decision; the sustainability projection becomes digital-product-passport readiness and the battery evidence-gap audit; the transport projection becomes the dangerous-goods data checklist. Each is a different question. Each stands on the same facts.

The fitment angle: the same part number, many machines

The procurement projection is worth drawing out, because it shows the record carrying a relationship, not just attributes. Consider a spare part — a control module or contactor — whose single manufacturer part number is valid across several hardware revisions of an installed equipment family, the way a spare for a programmable controller or drive line stays valid across generations of the parent machine. The decision an MRO buyer or an agent needs is not “what is this part” but “is this part number valid for the specific equipment version in front of me.”

That answer lives in the record as a modeled relationship between the part’s identity and the installed-base versions it fits — not as a free-text note in a description. When that relationship is trusted, a procurement agent can confirm a replacement is valid across equipment versions without a human cross-referencing manuals. When it is missing, the same agent either refuses useful substitutions or, worse, confidently approves a part that does not fit. This is the same shift described in when a PIM becomes a system of action: once the record drives decisions directly, the relationships in it carry operational risk.

Why this is one problem, not five

The reason to build the shared record first is not elegance. It is that the failures are shared. A wrong identity does not break classification and spare customs; it breaks both, plus compliance, plus the agent, at the same time. A stale attribute does not surface in one projection; it surfaces everywhere the attribute is read. Solving the five workflows separately means paying for five private copies of the same identity-and-evidence work, each drifting on its own schedule, each with its own silent errors.

Building it once means a correction propagates everywhere. Fix the chemistry value, with evidence, and the customs code, the DPP field, the dangerous-goods handling, and the agent’s answer all move together — because they were always projections of the same fact.

Turn evidence into reusable master data

The battery module is one product. The same shape holds for every SKU in an industrial catalog: a handful of disagreeing sources, a trust layer that resolves identity and earns each attribute with evidence, one canonical record, and as many decision projections as the business needs. The scarce asset is not another decision engine. It is the trusted substrate underneath all of them.

Send Claro a supplier catalog and its technical documentation — a datasheet set, an SDS batch, a price file — and see how much of it resolves to one trusted, evidence-backed record that classification, customs, compliance, procurement, and your agents can all read from.

Send a catalog and its technical docs

Related

FAQ

What do classification, customs, compliance, and AI agents have in common? +

They all start from the same two questions about the same product: which exact product is this, and which technical facts about it can we trust. Each workflow then applies its own decision logic to that shared, evidence-backed record.

Does Claro make every decision from one model? +

No. Claro maintains one trusted product record — resolved identity, normalized attributes, and the evidence behind each value. The record is shared; the decision logic is not. Classification, customs, compliance, and procurement systems each read that substrate and apply their own rules.

Why build a shared product record instead of solving each workflow separately? +

Because the same identity and attribute errors break every workflow at once. Resolving identity and trusting attributes once, with provenance, means an HS code, an ECLASS class, a DPP field, and an agent action are all computed from the same facts instead of from four private, drifting copies.

What is the difference between a canonical product record and a decision projection? +

The canonical record is the resolved identity plus validated, evidence-backed facts about one product. A decision projection is what a specific system derives from it — a commerce listing, an ECLASS or ETIM class, an HS/CN/TARIC code, a battery passport field, or an agent-permitted action.