In Part 2(A), Chetan described the three decisions every outgoing RFQ demands.
Who should receive this RFQ?
What is a commercially reasonable price?
Which supplier gives us the greatest confidence to award the business?
Every procurement leader recognises these decisions immediately. As engineers, however, we naturally ask a different question: Why are these decisions still so difficult to support with software?
After spending the last two years working on this problem, I've come to believe the answer isn't another sourcing workflow, another supplier database or another AI assistant. The real challenge is much deeper.
Procurement isn't simply choosing suppliers. It is determining which engineering and commercial experience accumulated over decades is relevant to the decision in front of you. That turns out to be a surprisingly difficult technical problem.
Problem 1 — The Missing Join Key
Every sourcing decision begins with a deceptively simple question: Have we sourced something like this before?
Most enterprise systems immediately search by part number. Experienced buyers don't. They search by experience. They remember a supplier who successfully manufactured a similar housing. An engineer who solved a difficult tolerance issue. A negotiation that produced an unusually competitive outcome. A supplier that consistently delivered difficult parts on time.
Notice what connects those memories. Not part numbers. Not purchase orders. Engineering similarity.
Every enterprise system organises information around transactions, supplier codes and part numbers. None understands that two different part numbers may represent almost the same engineering problem.
Before procurement can connect supplier history, quality outcomes, commercial performance and manufacturing capability, it first needs a shared engineering identity. Geometry provides the common join key.
Once that engineering identity exists, procurement is no longer searching transactions. It is searching experience. Geometry doesn't answer the sourcing question—it identifies the engineering problem so the right enterprise evidence can be brought together. Without that join key, decades of engineering and commercial knowledge remain fragmented across unrelated records.
Problem 2 — Relevant Evidence
Finding historical information isn't the difficult part. Finding the right historical information is. When procurement asks “Have we bought something like this before?” they aren't really asking about part numbers. They're asking:
Which suppliers successfully manufactured similar engineering families?
What quality issues emerged?
How did previous negotiations conclude?
Which suppliers consistently delivered?
Which commercial assumptions proved correct?
Historical prices are useful. Historical quality is useful. Supplier scorecards are useful. Manufacturing physics is useful. None of them has value until the system first determines whether the underlying engineering problem is actually comparable.
Relevance precedes intelligence.
Problem 3 — The Unknown
Every AI system is under pressure to produce an answer. Manufacturing shouldn't be.
Sometimes the organisation has built almost exactly the same component before. Sometimes the answer can be composed from familiar engineering features. Sometimes there is genuinely no relevant historical evidence. Those are fundamentally different situations.
A guessing system always returns an answer. An evidence system knows when the evidence is matched, composed, or unknown—and says so.
That distinction matters because confidence isn't created by certainty. It is created by understanding the limits of what the evidence can support.
Problem 4 — Confidence Through Evidence
Once relevant evidence has been identified, another challenge remains. How should procurement use it?
Historical sourcing tells us what happened.
Manufacturing physics estimates what should happen.
Supplier performance reveals who has consistently delivered.
Quality history exposes hidden risks.
Commercial outcomes explain previous negotiations.
Market conditions explain what has changed.
Each provides an independent source of evidence. None is sufficient on its own. The technical challenge is not collecting this information. Most enterprises already possess it. The challenge is continuously reconciling independent sources of engineering, manufacturing and commercial evidence into a commercially defensible position.
That is what we mean by Cost Confidence. Not another should-cost estimate. Not another supplier ranking. A confidence level that procurement teams can understand, explain and defend.
Why Existing Procurement Software Doesn't Solve This
ERP systems record transactions. Supplier management systems measure supplier performance. Costing software estimates manufacturing cost. PLM systems manage engineering data.
Each performs its intended role exceptionally well. What none of them were designed to do is continuously connect engineering identity, commercial history, manufacturing evidence and supplier experience into a single sourcing recommendation.
The systems don't need replacing. They need a shared engineering identity that allows every system to speak about the same component in the same way.
Bringing It Together
The three sourcing decisions Chetan introduced appear independent. Technically, they are not. Each depends on the same foundation.
A shared engineering identity.
Relevant enterprise evidence.
An understanding of what is known—and what isn't.
Continuous reconciliation of independent evidence.
Only then can procurement answer the questions that matter. Who should receive this RFQ? Is this quotation commercially reasonable? Which supplier deserves the award?
When an outgoing RFQ is prepared, buyers shouldn't have to compare spreadsheets, reconstruct supplier history or rely solely on memory. They should be able to begin with one engineering question—and receive decades of engineering, manufacturing and commercial learning as traceable evidence.
And when the sourcing decision is complete, the organisation shouldn't simply remember what happened. It should remember why. Because every award rationale, every supplier outcome and every production result becomes evidence that strengthens the next sourcing decision.
That is how engineering intelligence compounds.