How we handle brand and model
By equipment type we mean brand and model. This page explains the principles we use to keep our register of brands and models tidy.
Why we work systematically on this
Section titled “Why we work systematically on this”The purpose of our register is to make equipment users more self-sufficient — so they can find answers themselves, understand their equipment, and trust the information they get, without waiting on anyone else. With today’s AI and language models, we can turn this help into a dialogue: instead of clicking through folder after folder to find the exact variant or model year, a user can simply ask and get an answer tailored to the equipment actually in front of them.
For that dialogue to work well, the data it’s built on needs to be clean. That’s why we work systematically on brands and models, as this page describes.
After some years delivering digital solutions to both the equipment rental and contracting sides of the construction industry, we’ve accumulated a substantial number of equipment designations — well over ten thousand different models. We regularly clean this up, based on a clear set of principles.
We are not building a product catalogue
Section titled “We are not building a product catalogue”Our aim is not to build a complete overview of every brand and every model on the market. Our catalogue is a byproduct of what you actually use our solutions for — such as training on equipment, sharing information about it, or running inspections and controls.
Equipment types are brand and model — not categories or anything else
Section titled “Equipment types are brand and model — not categories or anything else”We don’t create categories ourselves. That’s your tool: you create your own categories fitted to your day-to-day work, use case, and trade, and these vary freely from customer to customer. What we do actively do is prevent a category from being registered as an equipment type — the two shouldn’t be mixed. Sometimes such entries, or other misregistrations and test data that isn’t really equipment at all, still turn up afterwards. We clean these up the same way we clean up duplicates, without affecting genuine equipment types or the information linked to them.
We have a low threshold for creating new equipment types
Section titled “We have a low threshold for creating new equipment types”Our customers care about sharing knowledge and building confidence in the field. That means it has to be easy to set up the structures needed to register that kind of sharing. The result is that equipment types appear with small variations from existing ones, and sometimes outright duplicates.
We merge duplicates, and sometimes variants
Section titled “We merge duplicates, and sometimes variants”Based on the principles described here, we regularly — both manually and automatically — merge duplicates and tidy up brands and models. When two equipment types are merged, the duplicate entry itself is removed, but everything linked to it — equipment, documents, training history, and other related information — is redirected to the correct model and is never lost.
Data we receive from customers’ systems
Section titled “Data we receive from customers’ systems”Many of our customers sync equipment data from their own systems — for example, thousands of equipment types from a rental company. We handle this data under the same principles as the rest of the register, with a few additions:
- We merge these equipment types too, so they better fit our end users’ use case. What works in a rental catalogue isn’t necessarily the right structure when someone needs to find a manual or receive training.
- Our cleaned-up version is never synced back to the source system. It’s adapted to our use case, not the customer’s rental catalogue.
- Many of the equipment types we receive aren’t relevant to any other user. We’d rather hide these than delete them; that functionality is being planned but hasn’t been built yet.
Our approach to variants
Section titled “Our approach to variants”Different manufacturers have different conventions for naming their models. Some try to keep a model designation stable for many years and use the model year as the differentiator instead, while others add small variations to the name itself. We have no ambition to hold every variant in our database, and will in some cases treat these as duplicates.
What we treat as duplicates:
- Model years or “steps” that don’t meaningfully affect operation.
- Models that aren’t really different, just variations sold through different dealers.
What we keep as separate, distinct models:
- Where the drivetrain itself is different. Combustion vs. electric drive is often indicated by nothing more than an “E” suffix on the model name, and “H” can mean hybrid — in these cases the models are different enough that they should be treated as such.
- Where the controls or operation differ.
Manuals that only cover one specific model variant or model year do occur, and in those cases we encourage storing them on the main model anyway. Our experience is that we can’t reliably distinguish these in any good way, so it’s better to keep the variants together under one entry and inform the user about it — ideally with the help of artificial intelligence.
How our AI handles this
Section titled “How our AI handles this”We use AI in two places in this process: when new equipment types are being created, and when a user is trying to find the right equipment or information about it.
We maintain editor-curated lists of brands and models on an ongoing basis — both proactively and reactively. When something new is created, we first check against these lists to find the right existing entry before allowing something entirely new to be created. Among other things, we use patterns for how a brand names its models and serial numbers, as well as known aliases and common misspellings, so that more duplicates are caught at the point of registration — not just cleaned up afterwards.
When a user searches for equipment or information about it, the AI is aware that model variants exist and makes sure to inform the user about this. Ideally, it will ask the user to clarify which model they’re actually standing in front of right now.