Manufacturer content libraries A product a specifier cannot place is not in the project.

Range coverage structured the way a specifier searches

Not the way an internal catalogue is organised. Those are rarely the same shape.

Parametric behaviour that matches the options you genuinely offer

And refuses the ones you do not.

Type catalogues

Where the range is large enough that separate families become unmanageable.

Complete product data

Model references, materials, finishes, performance data and the identifiers a schedule needs to populate.

Correct categorisation

So the product appears in the right schedule rather than an adjacent one.

File sizes a specifier will tolerate

Over-modelled geometry slows every model it enters, and content that slows a model gets deleted from it.

A maintenance route

Because ranges change.

Geometry gets the product into the model. Data gets it into the specification and the schedule.

A family with correct geometry and empty parameters produces a schedule full of blanks, and the specifier fills those blanks from whatever information is nearest to hand. That is frequently a competitor's published data, because theirs was complete. Complete, correctly named parameter data is what carries a product from model to procurement without a substitution happening somewhere in between.

A common and expensive error is building families that can be configured into products that do not exist.

The specifier configures it, specifies it, and the order arrives for something your factory cannot build. What follows is a substitution request, a delay, and a specifier who is slightly less inclined to use your content next time. Content should refuse impossible configurations. That is a modelling discipline rather than a technical one, and it requires understanding the product range properly before anything is built.

This is the failure nobody plans for. A library published once and never revisited slowly diverges from the range it represents. Discontinued products stay available. Updated dimensions do not propagate. A specifier who places an object and later discovers it is out of production does not make that mistake twice.

Maintenance is scoped separately for exactly this reason, and it suits a continuing arrangement rather than a project.

1. 1. Range review.What to build, at what level of development, and how a specifier will search for it.
2. 2. Structure and naming.Family structure, type catalogues, naming and parameter schema agreed before production rather than discovered during it.
3. 3. Pilot family.One representative product, built and reviewed. Ideally by a real specifier rather than only by your team.
4. 4. Production in batches.Against the agreed structure.
5. 5. Data population.From your product information.
6. 6. Handover with documentation.So the library is maintainable as the range changes.

Cabinet, casework and fixture manufacturers whose products are specified by architects and designers. Manufacturers whose existing content is out of date, incomplete, or heavy enough that specifiers avoid it.

Send your BIM execution plan →