Material Matters
/
August 6, 2026

Bringing Material Intelligence to Revit

Dave Lemont

Executive Chairman, Acelab

Before Revit, coordinating a building was manual work. A plan, a section, an elevation, and a schedule were four separate drawings that happened to describe the same building. Nothing connected them. Move a wall and someone had to find every view that wall appeared in and correct each one by hand. The set was only as accurate as the last person who checked it.

Revit changed the premise. A wall stopped being a line and became a parametric object that knew what it was, what it was made of, and where it sat in the building. Every view became an expression of that object rather than a separate document. Change the wall once and the plan, the section, the elevation, and the schedule all followed. That principle is bidirectional associativity, and it ended manual geometric coordination.

Twenty-five years later, geometry is still the only part of the building BIM coordinates this way.

WHAT REVIT DID NOT DO

The material data riding on top of that geometry never got the same engine. Specs, keynotes, material tags, finish schedules, and the product attributes behind them still live in flat text files, hand-typed identity fields, and spreadsheets that sit outside the model. They are what connects a line on a drawing to a product a contractor can price and order. All too often the spec, the schedules, and the drawings do not agree, and the contradiction comes back as an RFI, a substitution request, a change order, or the wrong product on site.

THE DOCUMENTATION IS FRAGMENTED AND NOT AUTOMATED OR COORDINATED

What BIM managers have solved so far

Think about what your firm has already built. Project setup and file structure. Modeling rules and naming conventions. Family management. Coordination and sheet organization protocols. The modeling side of BIM has been worked over pretty thoroughly, and most of that work was yours.

The material side is held together with string. A workbook here, a script there, a shared parameter file, a naming convention everyone agreed to once. Each piece works. Nothing connects them, and you are the connection, which means the process of BIM is still disconnected from how buildings get built.

Where it breaks

Look at how that connection gets maintained.

Nobody is working from the same list

Firms handle this differently. Some run a keynote system. Some tag off material parameters. Some maintain their own shared parameters and tag those. The method varies by office, and sometimes by project within the same firm. What breaks is the same either way.

In many firms it starts with keynotes. The table is a flat text file. One firm-standard list, copied from project to project, edited by hand. There is no reliable central source, so every project starts from a slightly different version and every team member trusts their own copy. Two people edit the same file and the standard quietly forks.

Some firms have built real processes around this. A master spreadsheet, columns for each field, rules about who edits it and when, sometimes formulas that generate the keynote text ready to paste. That takes real effort to build.

It can work. Keeping it working is the hard part. Product information changes constantly, so someone has to track discontinued lines, reformulations, and new certifications, and get every one of those changes into the file. Harder still is getting the firm to use it. Every project team has to be trained on it and held to it, on every project, under every deadline.

The data is typed, not sourced

However the list is maintained, the data still has to get into the model by hand. The material identity data behind every tag is entered one asset at a time. Someone opens Edit Type, finds the material, and types the description, the mark, the keynote, the manufacturer, and the cost into the identity fields. Then does it again for the next one. A generic Revit material ships with none of this, so the tag reads blank until a person fills it. Multiply that by every material on the project, and again by every project in the firm. And whatever you built writes into Revit, not back out of it, so the moment someone edits a value in the model, the source it came from is wrong and nothing tells you.

The problem is not only the typing. It is what you end up with. A keynote in Revit is a string of text. A material description is a string of text. Neither one knows the product it names. It does not know the certification behind the product, the recycled content, the cost, or whether the product still meets the project targets. The tag looks authoritative on the sheet. It is only as accurate as the day someone typed it.

Someone also had to find that data before they could type it. Accurate product information does not sit in one place waiting to be used. Teams assemble it by hand, Googling manufacturers, emailing reps, digging through cut sheets and old submittals, then confirming that what they found is current. That effort produces a value in a field and nothing more. It does not travel. The next project starts from zero and the same team hunts down the same data again. Today the team is the source of truth, which means the source of truth walks out the door when the project closes.

Some firms are working on this. The sustainability group builds a materials standards library: products vetted against the firm's criteria, with EPD and HPD coverage tracked product by product. That work is serious, and at many firms it is somebody's full-time job.

Keeping it current is difficult. Product lines change and certifications lapse, so the library has to be re-checked against them on an ongoing basis. Operationalizing it is harder still. The library sits outside the project workflow, so using it means leaving the model to go find it and carrying values back by hand. A standard that does not connect to the workflow depends on every project team choosing the extra step.

One change, four corrections

Then the product changes. It always does. A substitution arrives during CDs, a finish gets value-engineered, the manufacturer discontinues the line you specified. Now the same fact has to be corrected in four places at once. The tag on the drawing. The row in the finish schedule. The entry in the keynote legend. The section in the spec. Change three and miss the fourth, and the set now says two different things about the same product. This inefficiency has a domino effect through construction as misinformation creates confusion and redundant RFIs.

This is why the nights before a submission deadline get long. Someone sits down and cross-checks the tags against the schedule against the spec against the keynote legend, by eye, looking for the disagreement a contractor would otherwise find for them. Some of it gets caught. Some of it ships.

None of this is a Revit failure. Revit was built to coordinate geometry and it does that well. The material data riding on top of the geometry was simply never given the same engine.

Material intelligence: a material information model meets BIM

The selection becomes the model

Every product selection in Material Hub feeds into a material information model. It carries the full attribute set. Aesthetics, performance, certifications, carbon, and more.

Your firm's material standards live in the Firm Library. Keynote and tag conventions, and the vetted products behind them, set once and carried into every project. The vetted product arrives in the project already carrying its certifications and EPD data, so using the firm standard is the path of least resistance instead of a detour out of the model. One source your whole firm can trust, so the accurate data travels with every decision instead of living in one person's memory and leaving when they do.

Not every selection has to come from the Firm Library. Any product in Material Hub carries the same data, across 250,000+ products and 2,000+ certifications, so a team specifying something new gets it with its attributes already attached instead of assembling them by hand.

How the two models connect

The relationship has to be established before any of it works. Download the Revit plugin and link your Material Hub project to the model. Then map the two together: your Revit materials to the building materials they represent, and your Revit families and objects to the building products they represent. That mapping is what tells each system which selection corresponds to which element in the model.

Once the mapping exists, data moves in both directions. Material Hub fields write to Revit parameters. Model assets come back the other way, including counts, quantities, and where each product is actually placed.

The connection is bidirectional, and you choose which system owns each field, per project. The sync respects that choice. It covers the fields your keynotes and tags read from: Keynote, Type Mark, Material Mark, Description, Cost, and the type and material comments. Most of those used to be read-only, filled in by hand one asset at a time.

That means you stop managing identity data one asset at a time. Every mapped asset appears together in one schedule, so you review and edit across the whole project in a single view instead of opening Edit Type again and again. You can also push the exact Material Hub fields you want onto Revit elements and materials as Shared Parameters, written natively onto the model on every sync. Acelab stays the source of truth, so a value updated in Acelab updates in Revit. The model never holds stale data.

Now the substitution is one edit. Change the product once, and the material tag, the keynote, the Revit schedule, the finish schedule, and the spec section all follow, because they were all drawing from that selection to begin with. All of it stays in sync.

Keynotes, material tags, and shared parameters all attach to modeled elements. The family or object has to exist in the model before it can carry data. For most of the building, that is how your team works already. For finishes and FF&E, often it is not.

For interiors teams who don't model everything

Not every team models every finish. Interiors and FF&E work rarely lives fully in the model, and that is a modeling reality, not an oversight. A paint color, a wallcovering, a fabric on a chair specified but never placed: none of these has a family or object to carry a tag. No host means no attachment, and no attachment means the bidirectional connection has nothing to run through. So the finishes end up in schedules and spreadsheets, disconnected from the drawings meant to describe them.

Acelab gives those teams a path that does not depend on modeling every element. Build the finish schedule in Material Hub from real product data. Smart Docs generates it, and every entry carries its product, its finish, its performance and sustainability data, its cost. Then place that schedule on your Revit sheets.

The associativity holds, it just runs on a different path. Your drawing schedule and your Acelab schedule are two views of the same material information model, so change a finish selection and both reflect it. Neither one is tied to geometry, because the geometry was never modeled. For finishes, the document is the deliverable, so that is where the coordination has to live.

You are not retyping a table or hunting for the latest version before a deadline. The schedule on the drawing shows what was actually selected.

Teams without a Revit license can do all of this. They work visually in Material Hub with product images, technical data, and certifications, and produce a finish schedule the whole project can rely on.

The same discipline, now in the documentation

For twenty-five years the model has been coordinated and the documentation has not. The geometry took care of itself while the material information behind it was typed, copied, cross-checked, and corrected by hand.

That changes when the material decision becomes a model. One selection holds the data, and the material tag, the keynote, the Revit schedule, the finish schedule, and the spec section are all views of it. Your firm's standards live in the Firm Library instead of in a file someone copies. The connection to Revit is bidirectional, so the model and the source agree without anyone maintaining the agreement.

The return shows up in a few places. The hours your team spent typing identity data and cross-checking documents against each other go back into design. Errors that used to reach the contractor as an RFI or a change order get caught by the structure instead of by a person reading four documents side by side. And because accurate product data arrives with the selection rather than after a search, teams evaluate more options before committing, which is where better material choices come from.

The building information model coordinates the geometry. The material information model coordinates everything the geometry is made of.

Imagine a world where your specs, your schedules, and your Revit drawings are always in sync and always accurate.

This is what material intelligence looks like in practice today.

See how bidirectional Revit sync works for your firm →

Get started with Material Hub