MetalWhiz™

The problem

Forty profiles. Each one carries section properties, span tables, gauge options, finish ranges, fastener schedules and code approvals. That is thousands of individual facts, published across data sheets, span charts and test reports.

An architect specifying a roof does not want to read all of that. They want to know whether a 24 gauge panel will span eight feet on open purlins, and whether the finish they picked is available in that gauge. Every one of those questions used to arrive as an email, get forwarded to an engineer, and come back the next day.

Meanwhile the answers already existed. They were just spread across forty documents nobody outside the company could navigate.

What we built

A copilot that reads the same published data a specifier would, and answers in the language architects actually use. It sits on the product pages and in a dedicated terminal, and it is fluent in the vocabulary — pitch, purlin spacing, uplift, spangle, open area.

Ask it to spec a standing seam roof for a 6:12 pitch and it returns the profiles that qualify, the gauges that span the distance, and the finishes offered in each. It cites the profile it drew the answer from, so the specifier can go and check.

Why it holds up

It is grounded in the product library rather than the open internet. It cannot invent a span, offer a finish that is not manufactured, or quote a test result that was never run — the failure mode that makes most product AI unusable in a technical industry.

When it is not certain, it says so and points to a person. Every answer carries the same caution the engineer would give in an email: verify important specifications before you build. That single line is what makes the tool safe to put in front of a specifier at all.

What changed

The routine questions stopped reaching the engineer, and the specifier stopped waiting a day for an answer that already existed in a PDF. The catalog became something you can ask, rather than something you have to read.