Asset Hierarchy (EBS)

When a bearing fails on the third gearbox of a packing line, "Line 2 breakdown" in the logbook tells you nothing useful six months later. You need to know it was the bearing, on that gearbox, on that line, in that plant — every time, in every report. That's what an Equipment Breakdown Structure gives you: a fixed place for every fault to live, from the plant gate down to the part.

The Problem With Flat Asset Lists

Most spreadsheets and even a lot of CMMS tools store assets as one flat list with a "parent" column somewhere. It works until you have 300+ assets across three shifts and two shift-in-charges naming things differently. A conveyor motor gets logged as "Motor 3," "M3 Line B," and "Spare Motor (old)" by three different technicians — and now your failure history is split three ways.

AssetAI's Equipment Breakdown Structure fixes this by rendering two hierarchies as one tree:

• A Location tree — plant, area, line, location — so you always know where an asset physically sits.
• An Asset tree — parent and child assets nested underneath — so you always know what it's made of.

The two trees build in a fixed order: location roots first, then the root assets sitting in each location, then their children recursively. Empty branches don't clutter the screen, and if a technician creates an asset without placing it properly, it doesn't vanish — it falls back to the top level where you'll notice it and fix it.

Five Levels, Not Fifty

Every asset in AssetAI carries one of five EBS levels: Equipment, Assembly, Sub-Assembly, Component, Part. That's it — not a configurable taxonomy, not an open-ended tree depth you design from scratch. A gearbox is an Assembly. The bearing inside it is a Component. The specific seal on that bearing is a Part.

This matters more than it sounds like it should. On the floor, "the gearbox is down" and "the input-shaft bearing seized" are two completely different maintenance stories, two different spares requirements, and two different mean-time-between-failure numbers. If your history only ever tags the machine, you can never tell whether you have a gearbox problem or a bearing-quality problem from a specific vendor. Five fixed levels force that granularity without asking your planning team to invent and maintain a classification scheme — something that usually rots within a year because nobody enforces it.

If your engineering team already lives and breathes ISO 14224, KKS or RDS-PP tagging, be upfront with yourself here: AssetAI does not import or map to those standards-body taxonomies. The five levels are fixed by design. Teams that need a wholesale RDS-PP structure imported as-is should look elsewhere; teams that need "fault traced to component, not to machine" without a six-month taxonomy project will find this fits. For plants that do need to reference formal reliability standards for other reasons, our standards page has more on how AssetAI relates to ISO frameworks generally, and ISO's own standards catalogue is the authoritative source if you're benchmarking against 14224 directly.

Finding an Asset in a 40-Machine Unit (Or a 400-Machine Group)

A tree is only useful if you can find your way through it fast, especially when a supervisor is asking where the spare part is and the shift is running. AssetAI's filters work on:

• Text search across asset code and name
• Asset Type
• Criticality
• Status

The detail that actually saves time here: when a search matches a node three levels deep, every ancestor above it stays visible too. You're not staring at an orphaned "Bearing SKF-6205" with no idea which line it's on — the plant, area, line and parent assembly are all still on screen, so the path is never broken.

Click any node and you get four tabs — Details, Children, BOM and History — with live counters for child count, BOM lines, total and open work orders, active PM plans, and the last 10 work orders. A shift engineer can open the gearbox node, see there are 4 open work orders against it right now, and decide whether it's safe to keep running before the next planned stop.

Two Ways to Browse, Depending on the Job

Not every question needs the full tree. The Assets screen also gives you:

• A flat indented tree for quickly scanning everything in one view
• A per-asset subtree panel showing one asset plus all its descendants, useful when you're auditing a single line before a shutdown

If you're doing a pre-shutdown BOM check on one gearbox, opening the subtree panel is faster than navigating the full plant tree. If you're onboarding a new engineer and want them to understand the whole plant's asset structure, the indented flat view does that better. Access to any of this is gated by the `assets.view` permission, so contract labour or visiting auditors see only what their role allows.

What This Deliberately Doesn't Do

Two honest limits worth stating before you build a workflow around them:

• No drag-and-drop re-parenting. If a motor moves from one gearbox to another, you correct the parent in the asset form. It's a deliberate choice — re-parenting by accident, mid-scroll, in a 500-asset tree is a bigger risk than the two extra clicks it takes to do it properly.
• No enforced depth limit or cycle prevention on parenting — this is genuinely unverified in the current build, so if your team builds unusually deep or circular asset chains, test this before relying on it in production.

Neither of these is a dealbreaker for most plants, but they shape how you set up governance around who edits the asset form.

Where This Fits in a Multi-Plant Group

If you run one line in Pune and another in Coimbatore, both under the same company code, the EBS gives you one hierarchy across sites rather than two disconnected spreadsheets that someone reconciles every quarter. Location codes are unique per company (up to 40 characters, across exactly four levels), so a "Line 2" in one plant never collides with a "Line 2" in another. When you export to CSV, the location is written as a full path and the EBS level as its label — so a reliability engineer comparing bearing failures across both plants gets a clean, comparable dataset without manually reconstructing hierarchy from codes.

This structure is what other parts of AssetAI build on — it's not the same thing as the asset registry itself, but the tree that makes the registry navigable. If you're weighing whether a structured EBS is worth the setup effort against your current spreadsheet, our use-cases page has examples closer to your industry, and it's a fair question to bring straight to a demo — seeing your own asset list rendered as a tree tends to make the case faster than any description can.

If your plant currently runs on one of those standards,... the practical question is how to get the hierarchy set up and kept clean once teams start using it day to day. That's less about theory and more about data discipline — location codes, permissions and export habits that hold up across a multi-plant rollout.

Setting Up the Hierarchy in a Real Plant

Location codes are unique per company and capped at 40 characters, spread across exactly four levels — plant, area, line, location. That constraint forces a naming convention early, which is worth deciding before anyone starts creating assets rather than after. A typical approach is to fix a short prefix per plant, then let area and line codes describe themselves in plain terms maintenance staff will recognise on a shop floor, not codes only an engineer could decode.

Because the parent of an asset is set from within the asset form — there's no drag-and-drop re-parenting — getting the hierarchy right at data-entry time matters more than it would in a tool that lets you rearrange the tree visually later. Practical habits that keep the structure usable:

• Create the Location tree completely before bulk-loading assets, so nothing falls back to the top level by accident.
• Assign the EBS level (Equipment, Assembly, Sub-Assembly, Component, Part) consistently across similar machines, so filtering by level returns comparable results across lines.
• Decide asset-coding conventions per plant up front — this is the same discipline plants already apply when working toward OEE or TPM tracking, where inconsistent asset naming quietly breaks downstream reporting.
• Reconcile the tree periodically against a walk-down of the actual plant, since nothing in the system enforces a depth limit or blocks cyclical parenting — worth verifying against your own data if you're migrating from another CMMS.

Access, Export and Multi-Plant Considerations

The tree is only visible to users holding the `assets.view` permission, so before rollout it's worth confirming who on the maintenance and reliability teams actually needs to see the full structure versus just their own line. This matters more in Indian manufacturing environments where a single EBS often spans multiple plants under one company record, each with its own area and line naming, and where contract maintenance staff may need visibility limited to their assigned equipment.

For reporting outside the platform, CSV export writes the location as a full path and the EBS level as its label, which keeps exported data readable in a spreadsheet without needing to look up level codes separately — useful when sharing an asset register with auditors or a reliability consultant who isn't logging into AssetAI directly. Filtering itself runs in PHP over the company's full asset list on each render, which is a detail worth knowing if you're planning an unusually large asset base and want to understand how the screen behaves under load (verify against your own tree size before committing to a structure).

None of this replaces a wider maintenance strategy — the EBS is the addressing system that PM plans, work orders and history all attach to, not a substitute for deciding what that strategy should be. For plants weighing where a structured asset hierarchy fits against broader ISO standards or industry-specific practice, it's worth reading how the rest of AssetAI's use cases build on top of this same tree, or starting from what a CMMS actually does if the concept is new to your team.