September 2026
Muir AI Named a Winner in the World Economic Forum's (WEF) AI for Resilient Supply Chains Challenge
Your submission has been received and we'll be in contact with you shortly.
Return home
Thank you for registering
October 2026
Every platform in this category claims to produce a defensible cost estimate. Six requirements separate the ones that hold up when the BoM is messy, the data is stale, or nobody has the part on the bench, and each of them is testable on your own data during the evaluation.
Looking to subscribe to our newsletter? Click here.
A should-cost platform builds an independent estimate of what a part ought to cost, from its material, its manufacturing process route, and the geography and labor base of the plant that makes it. The output is a figure the team can defend in front of a supplier, rather than a market price or an average of what the part has cost in the past.
Every tool in the category claims that. The differences show up on the days an evaluation demo never covers: the Bill of Material (BoM) arrives in the wrong shape, the reference data behind the model is nine months old, the design changes the week before a negotiation, or the part belongs to a competitor and nobody has one on the bench.
Six requirements separate a platform that holds up on those days from one that produces a good first model and then drifts. Each of them can be tested during the evaluation, on your own data, instead of asked as a question in an RFP.
Cost models rest on input prices, and those prices move faster than most reference libraries update. The U.S. Bureau of Labor Statistics producer price index for steel mill products stood at 331.4 in March 2026 and 374.2 in July 2026, a rise of roughly 13 percent across four months. A model built on a first-quarter table and reused in the third quarter is wrong on the largest single line in most metal parts, and wrong in a direction the supplier has already noticed.
Two questions get at this. How often does each class of input refresh, and what does the model do when an input goes stale? A platform that timestamps its inputs and shows which figures are current gives the team something to negotiate with. A platform that returns one confident number with no vintage attached has moved the freshness problem back onto the engineer.
Model a steel or copper-intensive part, then ask when each material and energy input was last updated and where the figure came from.
Real BoMs arrive with merged headers, inconsistent part naming, missing material callouts, mixed units and duplicate rows. A single product BoM commonly carries hundreds of line items and thousands of parameters, and cost modeling teams can spend beyond 40 hours cleaning one before any modeling begins.
The loss is not the hours. It is the unit-cost savings the team never finds, the resourcing case it never builds and the design tradeoffs it never prices, because the week went into reconciling spreadsheet formats. A platform that requires a clean input has moved its hardest problem into your team's calendar.
Send the worst BoM you have, unedited, rather than the tidy sample the vendor asked for.
Every evaluation runs into parts with no supplier disclosure behind them: a competitor's assembly, a sub-tier component covered by an NDA, a new design that has a specification and no quotes. What the platform does with those parts is the requirement most RFPs leave out.
This is the work Muir does through BoM comprehension and the product twin. The platform reads the incoming BoM, resolves structure and part identity, and generates a product twin wherever supplier data or design specification is missing, inferring material, process route and source geography from its material and manufacturing databases so a cost model can be produced anyway. The competitive side of the question runs two ways. Where a physical tear-down is practical, AI cost modeling shortens the path from a disassembled unit to a costed BoM. Where a tear-down is cost-prohibitive, where a unit cannot be sourced, or where the spend is not worth a single data point, the product twin produces a should-cost model from limited inputs, as little as a product name or a basic specification, with no physical unit required.
Name a part your team has never been able to get data on, and ask for a model of it.
One model answers one question. Cost engineering work is comparative: this process against that one, this source country against another, this material grade against the alternative that still clears the specification.
The dimensions worth varying are process, geography, supplier and material. Stamping against fine blanking on a bracket. The same casting quoted from three countries with different energy and labor bases. Production volume sits in a different category. It is an assumption the model makes, on a high-volume basis, which the team then refines through the impacts that follow from it such as overhead and labor allocation.
Throughput matters because it changes which questions get asked at all. A team that can run one scenario a week saves the tool for parts that already look wrong. A team that can run twenty in an afternoon runs them across a whole program.
Ask how long the second, third and tenth scenario take once the first model exists.
AACE International's cost estimate classification framework ties expected accuracy to the maturity of the inputs behind an estimate. In its process-industries recommended practice, 18R-97, a concept-screening Class 5 estimate carries an expected range as wide as minus 50 to plus 100 percent, while a Class 1 estimate built from a detailed take-off narrows to no wider than minus 10 to plus 15 percent. That practice is written for capital projects and explicitly excludes assembly manufacturing, so the numbers do not transfer to a machined bracket. The principle does: an estimate is only as defensible as the inputs behind it, and a number that arrives without its inputs cannot be classified at all.
That is the test for any platform using AI to fill gaps. Inference is useful and often necessary. It also has to be visible. Every inferred value should carry provenance, so the engineer can see which fields were declared in the source file, which the system generated and which were edited by hand. A supplier will dismiss a number the team cannot decompose in the room.
Pick one component in a finished model and ask where every value in it came from.
Integration covers a wide range in this category, from a file export to a live connection into PLM and ERP. Ask which objects move, in which direction, and on what trigger. A model that has to be rebuilt by hand after every engineering change gets rebuilt for the first two changes and then abandoned. The same models are worth considerably more once they also feed supply chain work, and that only happens if they live somewhere the rest of the organization can reach.
Ask what happens to an existing model when a part number is superseded.
Evaluations in this category are usually run as feature comparisons and won on demo quality. A better structure is to give every vendor the same three parts, one clean, one messy and one you have no data for, and the same two weeks. Judge what comes back on input freshness, on how much of your team's time it consumed, and on whether the numbers can be decomposed line by line.
To run that test with us, book a demo and bring the messy BoM. We will model it, show which values were inferred, and hand back something your suppliers can argue with. It is also worth reading how BoM data quality shapes cost models before an evaluation starts.
A should-cost platform builds an independent estimate of what a part or product ought to cost, from its material, its manufacturing process route, and the geography and labor base of the plant that makes it. The output is a defensible figure a cost engineering team can put in front of a supplier, rather than a market price or an average of what the part has cost in the past.
Six things, all testable on your own data rather than answerable in an RFP. How often the input data refreshes and whether each figure carries a date. What the platform does with a messy BoM sent unedited. Whether it can model a part you have no supplier data for. How long the second and tenth scenario take once the first model exists. Whether every value in a finished model can be traced to its source. What actually moves between the platform and your PLM and ERP systems, in which direction, and on what trigger.
Yes. Muir generates a product twin, an inferred representation of the part that fills gaps in supplier data and design specification from material and manufacturing databases, and produces a cost model from it. Where a physical tear-down is practical, the platform shortens the path from a disassembled unit to a costed BoM. Where a tear-down is cost-prohibitive or a unit cannot be sourced, the product twin produces a model from as little as a product name or a basic specification.
Process, geography, supplier and material. Stamping against fine blanking, the same casting sourced from different countries, an alternate material grade that still clears the specification. Production volume is treated as an assumption the model makes, on a high-volume basis, which the team then refines through the impacts that follow from it such as overhead and labor allocation, rather than as a dimension the platform sweeps.
You've signed up!
You've signed up!
Don't worry, we don't spam.
Understand cost, navigate tariffs.
Drive deeper intelligence into product design cycles.
Scaled PCFs and reduction insights.
Determine your full supply chain and its cost.
Baseline your footprint and decarbonize.
Building Product Intelligence.
Find open roles at Muir.
Muir has plans for any scale.
