Most architects never think of themselves as data managers. But that's a fair description of what spec writing has become. Every clause you finalise rests on a product decision, and every product decision rests on information that came from somewhere: a manufacturer's PDF datasheet, a BIM object downloaded from a library, a test certificate, a sales rep's email, or a clause you copied from the last project because it worked.
That sourcing happens quietly, and it rarely follows a system. A technologist might pull a U-value from a brochure, a fire rating from a third-party certificate, and a finish reference from a website that's been updated since the project started. Each piece is fine on its own. The trouble starts when they have to agree with each other, and with the drawings, and with the schedule. Manufacturer product data is the raw material of the whole specification, yet it usually enters the document in fragments, from a dozen sources, with no record of where it came from or when.
A manufacturer's datasheet and a specification clause are not the same kind of object, and treating them as interchangeable causes most product-data problems. A datasheet is a marketing and technical document. It describes everything a product can do, across every variant, in conditions that may not match yours. A clause is a contractual instruction. It says exactly what's required on this project, in this location, to this performance.
Turning one into the other is real work. You have to strip out the variants that don't apply, pin down the specific performance values you're relying on, and phrase it so a contractor can price it and a building control officer can check it. Get this wrong and you create ambiguity that surfaces at the worst possible time, usually on site, usually as a substitution request. The product library architecture a firm builds, the way it stores, tags, and reuses this information, decides whether that translation happens once and gets reused, or happens badly on every job.
It helps to be precise about the jobs manufacturer product data is doing once it lands in a specification. It identifies the product, usually with a manufacturer name and a reference. It states the performance you're relying on, things like thermal conductivity, fire classification to BS EN 13501, acoustic reduction, or slip resistance. It sets the standards the product must meet. And it carries the conditions of use that make the warranty valid, which is the part people forget.
Each of those jobs points at a different document. The reference comes from a catalogue. The fire classification comes from a test report, not the brochure. The warranty conditions sit in a separate technical guide that nobody reads until there's a dispute. So a single well-written clause might draw on three or four sources, and the spec writer is the only person who ever sees them together. When that knowledge lives in one person's head, it walks out the door when they do.
Most practices have a product library of some kind. A shared drive, a folder of favourite datasheets, a master spec that gets cloned for each project. These are genuinely useful, and they're also a slow-motion liability. Products change. A manufacturer reformulates a membrane, withdraws a panel, updates a fire test, or shifts a value after a regulatory change. Your saved datasheet doesn't know any of this.
The result is drift. The clause that was correct in 2023 quietly becomes wrong, and nobody notices because nothing in the workflow forces a check. This is the same problem schedules have, where a window schedule and its specification slide apart over months of small edits. Product data drift is harder to spot because it happens outside your office entirely, on the manufacturer's side, and the only signal you get is a rejected submittal or a contractor pointing out that the product you named no longer exists. Good spec product sourcing isn't a one-time task. It's a maintenance problem, and most firms have no maintenance routine.
This is where the way firms handle product data is starting to shift. The bottleneck was never finding a datasheet. It was reading it, extracting the values that matter, checking them against a standard, and keeping the whole thing current across hundreds of products and dozens of live projects. That's pattern work at a scale humans handle slowly and inconsistently. It's also exactly the kind of work that AI tools are now good at.
Platforms like Avoice approach this by ingesting a firm's existing material: its datasheets, past specifications, schedules, and product libraries, and turning that scattered information into structured, searchable data. Instead of a folder of PDFs nobody can query, you get product information that's tied to the right Uniclass and CAWS classifications and grounded in your own projects rather than a generic clause library. Avoice uses AI agents to pull the performance values out of manufacturer documents and place them where they belong in a clause, so the translation from datasheet to specification stops being manual archaeology every time.
The more useful part is consistency checking. Because the product data and the rest of the document live in the same structured system, it becomes possible to flag when a fire rating in a clause doesn't match the schedule, or when a named product appears in the spec but not the drawings. Catching that before tender is worth far more than the time saved typing.
None of this removes the architect's judgement, and it shouldn't. AI can extract a U-value from a datasheet reliably. It cannot decide whether that product is the right choice for a coastal site with a 60-year design life and a nervous client. Sourcing is partly technical and partly a question of risk, cost, buildability, and relationships with manufacturers you trust. That stays with you.
There's also the matter of source quality. A tool can only structure the data it's given, and manufacturer documentation is uneven. Some firms publish rigorous, standards-aligned datasheets. Others publish a glossy brochure and bury the real numbers. AI doesn't fix a weak source, it just surfaces it faster, which at least lets you go back and ask the manufacturer for the test report rather than guessing. The discipline of demanding good data from suppliers matters as much as the tools you use to process it.
Picture a mid-sized housing scheme at the end of RIBA Stage 4. The architect has named a render system, a brick, a window, and a flat-roof membrane. Each came from a different source at a different time. The render was chosen at Stage 3 from a glossy brochure. The window U-value was lifted from a manufacturer's website that has since been updated. The membrane was carried over from a similar project two years ago because it performed well.
On paper the spec reads cleanly. The problem only appears when the contractor starts pricing. The brick reference has been discontinued and replaced by a near-identical product with a different frost rating. The window value in the clause is now 0.2 W/m²K higher than the current datasheet, which pushes the dwelling over its target on the SAP calculation. The membrane warranty turns out to require a primer the spec never mentioned. None of these are dramatic failures. They're the ordinary friction of product data that nobody kept current, and together they cost a fortnight of queries and a round of revisions.
The point isn't that the architect was careless. The point is that no human workflow reliably catches all three, because the information lives in separate places and changes silently. A system that holds product data in one structured, classified place is the only thing that makes those checks routine rather than heroic.
The firms that handle this well treat manufacturer product data as an asset, not a by-product. They keep a single source of truth rather than a scatter of personal folders. They record where a value came from and when, so a future reviewer can check it. They separate the contractual clause from the marketing datasheet in their own minds. And they build a habit of revisiting product choices when regulations or products change, rather than trusting a saved file forever.
Tools help, but the habit comes first. A platform like Avoice makes the discipline easier to sustain, because the data stays structured, classified, and checkable instead of decaying in a shared drive, and because the AI Spec Agent can draft clauses straight from your own product information rather than generic boilerplate. If you want to see how that works against your own datasheets and past projects, it's worth putting a real specification through the Avoice AI Spec Agent and watching where it pulls the numbers from. The products you specify are the building. The data behind them deserves the same care as the drawing.
