From Rigid Standards to Semantic Systems

Why the LLM era changes how we think about B2B integration

By Wim Dijkgraaf, Founder & CEO at Quotation Factory

In the LLM era, the foundational assumption behind decades of B2B integration standards has changed: computers no longer need rigid, predefined schemas to understand meaning. Large language models can read any reasonable structure — UBL, JSON, raw text, PDF — and extract exactly what you need. This shifts digital supply chain integration from syntax-driven enforcement to semantic-driven collaboration.

Below is the evidence, the implications, and what it means for metalworking supply chains.

How it started: designing for dumb computersFor the last decades, we’ve designed digital systems under one basic assumption:

“Computers are dumb. So if systems need to talk, everything has to be fixed, rigid, and standardized.”

So we built schemas. We wrote specifications. We created validation rules. We argued in working groups about field names and code lists.

And in many ways, that worked. It gave us reliable electronic messages between buyers and suppliers. It gave us structures like UBL and networks like SCSN. It allowed us, at Quotation Factory, to fully automate an RFQ-to-quote flow for metalworking companies across the supply chain.

But in my recent livestream demo, something very simple made me pause:

The same UBL RFQ that took years of standards work to refine… …I could drop into a large language model and ask:

“Analyze this UBL Request for Quotation and extract the powder coating specification.”

And I got back exactly what I needed, as clean JSON, without the model “knowing” anything about UBL as a standard.

That's when the core question crystallised — one that now applies to every company building digital supply chains:

In the LLM era, do we still need our systems to depend on rigid message formats to do smart things together?

The short answer: not always. Read on for what that shift looks like in practice.

What we achieved *because* of standards

Let me first state this clearly: I’m proud of what standards have enabled so far.

In the demo, I showed how a metalworker receives:

• a STEP file with an assembly
• a PDF with engineering drawings

We upload them into Quotation Factory. The system:

• analyzes the geometry
• identifies operations and their specifications
• determines material types
• extracts drawing and revision numbers from PDFs

On top of that, we enrich the RFQ with process details that may not be explicitly in the drawing – for example:

• powder coating: RAL 1007, two-layer, corrosion class 1, single-sided
• welding: TIG, total length, material thickness, etc.

From there, Quotation Factory generates a formal RFQ as a UBL XML document that fully complies with the UBL standard – and therefore also with SCSN, which has adopted UBL as its basis.

That UBL RFQ can be sent over the SCSN network to another party. On the receiving side, the supplier simply drags and drops the XML into their Quotation Factory environment. Instantly:

• all materials are mapped to their own article master
• the powder coating specification is correctly interpreted
• the welding specification is fully understood

Routes are created, nestings are generated, a bill of materials is built, and with a single click the supplier can send a complete quote back over the same channel.

No retyping. No deciphering emails. No manual mapping.

This is the pre-LLM promise of standards fulfilled: If we agree on a message format, we can automate a lot.

Where standards quietly lock in mediocrity

And yet… there’s a structural problem in how we’ve built this world.

Standards are created by committees and institutes. Many smart, well-intentioned people come together, reach consensus, and ship a specification.

But consensus is slow. Change is slower. And in practice, standards tend to optimize for the middle:

• They capture the lowest common denominator of requirements.
• They freeze today’s understanding of what “should” be in a message.
• They make it hard to express anything that wasn’t anticipated.

If I’m a powder coater and I want to know one extra thing from my customer before I quote… but that field is not in the standard, I’m stuck. I cannot get that information through XML until:

1. a working group agrees
2. the standard is updated
3. everyone upgrades their systems, validators, and mappings

Until then, any extra nuance I need lives in unstructured places: emails, PDF attachments, phone calls. The standard, which is supposed to help, becomes the bottleneck.

So yes, standards bring reliability. They let you say, “Your message doesn’t comply, so I’m rejecting it.”

But they also make the process rigid by design.

And rigidity is a dangerous property in a world that now changes faster than the lifecycle of a typical standard.

The LLM moment: semantics over syntax

Now contrast that with what happened when I took the exact same UBL RFQ and gave it to a large language model.

I didn’t import a schema. I didn’t explain the UBL specification. I didn’t tell it where in the XML the powder coating lived.

I simply said:

“Analyze the attached UBL Request for Quotation and extract the powder coating specification.”

The model read the XML, understood the semantics, and returned a structured JSON object with exactly the powder coating details I care about.

I did the same for the welding specification. Same result.

From there, you can imagine a very different architecture:

• An agent understands the semantics of your domain (e.g. powder coating for a metalworking shop).

• It ingests whatever structured or semi-structured input you provide: XML, JSON, CSV, raw text, PDF, UBL, something homegrown – it doesn’t care.

• It extracts the relevant fields, maps them to your internal logic and API contracts (for example, an MCP-based connector), and checks whether:

  • the RFQ contains more detail than you can handle, or
  • critical information is missing.

If something is missing, the agent can ask back in real time:

• It can query your systems.
• It can ask a counterpart agent at the customer side.
• Or it can escalate to a human: “We need this extra parameter before we can quote reliably.”

Suddenly, the interface is no longer:

“You must conform to my rigid schema, or I reject you.”

It becomes:

“Tell me what you need, in whatever reasonable structure you have, and I’ll work with it.”

That’s the shift from syntax-driven integration to semantic-driven collaboration.

Where standards still matter (and where they don’t)

I’m not arguing we should throw all standards out of the window.

There are domains where strict, rigid formats are both necessary and desirable:

• Invoices tied to tax and legal requirements
• Regulatory reporting
• Safety-critical and compliance-heavy processes

In those areas, rigidity enforces reliability, traceability, and legal certainty. That’s non-negotiable.

But a huge part of day-to-day industrial collaboration is not regulatory in nature. It’s:

• RFQs
• technical specifications
• sales orders
• engineering changes
• supply-chain coordination

Here, the business objective is flexible, high-quality digital collaboration across a chain of partners.

In that context, the question is legitimate:

Do we still want to design our collaboration around rigid, centrally-governed message formats? Or do we want to design for flexibility first, and let LLMs and agents handle the semantics?

From finite rules to the infinite game

At Quotation Factory we think a lot in terms of the “infinite game” of business: the goal is not to “win once”, but to stay in the game, adapt, and remain relevant over long time horizons.

Rigid standards are a tool for a finite mindset:

• Define the rules
• Freeze them
• Optimize inside those boundaries

Semantic systems powered by LLMs support an infinite mindset:

• Assume the rules will change
• Assume new data will appear
• Assume partners will have different needs
• Optimize for adaptability and understanding

For traditional metalworking companies, this matters a lot. Their competitive advantage is no longer only in machinery and craftsmanship, but also in how flexibly they can connect, quote, and deliver in digital supply chains.

If we lock that flexibility into fixed schemas, we’re baking yesterday’s understanding into tomorrow’s infrastructure.

What this means for architectures like Quotation Factory

Today, we’re in a hybrid world.

On the one hand, Quotation Factory:

• speaks UBL
• is compatible with SCSN
• automates RFQs, quotations, and orders end-to-end using these standards

On the other hand, the same platform can sit in architectures where:

• an LLM or agent layer interprets incoming content
• semantics are extracted on the fly
• internal APIs stay stable while external formats differ per partner

In practice, I see a near future where:

• Standards remain the backbone for legally and financially critical messages.
• Semantic agents become the interface for the messy, rich, business-critical collaboration around them.
• Systems like Quotation Factory don’t just consume standards, but cooperate with LLM-driven agents that understand any reasonable input.

In that world, the question “Is this XML perfectly compliant with standard X.Y?” becomes less important than:

“Did we understand what the customer wants – and can we respond instantly, accurately, and profitably?”

Where we go from here

I’m proud of what we’ve built on top of standards. It’s impressive that, today, a complex RFQ can move through a metalworking supply chain with:

• CAD files
• engineering drawings
• process specifications

…all being interpreted and automated, all the way up to a sales order, with zero human touch time in common cases.

But pride in what we’ve built shouldn’t blind us to what just became possible.

The LLM era gives us something radically new:

• Systems that read, interpret, and restructure information like a human expert would.
• Agents that can negotiate missing information instead of simply rejecting messages.
• Architectures that are format-agnostic and semantics-first.

So my thesis is simple:

In the pre-LLM era, rigid standards were a necessary foundation. In the LLM era, that same rigidity may well be our biggest constraint.

Our challenge as an industry – and my personal challenge as a founder – is to redesign our digital supply chains with this new capability in mind.

Not to destroy what standards gave us, but to liberate our systems from the idea that they can only be smart if everything is fixed upfront.

An open invitation

If you’re a metalworking company, a machine builder, or a supply-chain leader asking yourself:

• “What does this mean for my RFQ and quoting process?”
• “How much of my current integration stack is actually still necessary?”
• “Where could semantic agents give me flexibility without losing control?”

…I’d be happy to explore that together.

Not with a sales pitch, but with concrete examples from your own reality.

Reach out, share how you exchange RFQs and quotes today, and let’s see what changes when we stop assuming our systems are dumb – and start designing for the world where they can finally understand.