Rotables Break Generic Inventory Systems

Generic inventory systems treat every stock item the same way: it comes in, it goes out, you count what's left. That model works for consumables. It falls apart the moment you introduce rotables — components that are repaired, overhauled, and returned to service rather than consumed and discarded.

If you're running MRO operations in aviation, rail, defence, or heavy industry, you already know this. The question isn't whether your current system has gaps; it's how deep those gaps run and what it's costing you.

What Makes Rotables Fundamentally Different From Consumables

A consumable has one life cycle step: it gets used. A rotable has a state machine. An aircraft engine fan blade leaves the wing, enters a repair shop, gets inspected, may be scrapped or repaired, receives a new part number revision, and eventually returns to a serviceable pool — where it can only go on specific aircraft tails if it has the right certification history attached.

That state machine typically includes: Serviceable, Unserviceable, In-Repair, Awaiting Inspection, Condemned, and Quarantine. Each transition requires a documented trigger — a work order, an inspection record, a Part 145 sign-off, an airworthiness directive compliance note. A system that tracks only quantity-on-hand collapses all of this into a single number. That number is meaningless.

The serialisation requirement compounds this. Each rotable has a unique serial number, and the system must track that individual unit's entire history: every installation, every removal, every repair cycle, every life-limited component within it that has its own cycle count. An aircraft wheel assembly, for instance, contains bearings with independent time-since-overhaul limits. Generic inventory systems have no data model for a component-within-a-component with its own independent limits.

Why Generic ERP Modules Fail at This

Standard ERP inventory modules — SAP MM, Oracle Inventory Management, even Dynamics 365 Supply Chain — are built around the batch/lot model. Lot tracking gets you serial number visibility in a basic sense, but it doesn't give you airworthiness status, maintenance programme compliance, or removal/installation event history as first-class data entities.

The workarounds people build are telling. Teams create shadow spreadsheets to track serial number history. Technicians maintain paper logbooks because the ERP can't capture the fields they need. Someone builds a custom Access database in 2009 that's still running in production in 2024. These aren't process failures; they're the system forcing its users to work around it.

The data model mismatch is specific:

Concept	Generic Inventory Model	Rotable-Aware Model
Unit identity	Batch/lot number	Unique serial number
Quantity tracking	Count on hand	Individual unit states
History	Goods receipt / goods issue	Full event log per serial
Limits	Expiry date	Cycles, hours, calendar time (per component)
Status	In stock / out of stock	Serviceable / Unserviceable / In-Repair / etc.
Documentation	PO reference	Maintenance release, Form 1, 8130-3

Building rotable tracking on top of a generic model means fighting the data model at every step.

How Do You Actually Model a Rotable System?

The core entity is the serialised component record, not the part number. Part numbers describe what a component is; serial records describe what this specific unit has done and is allowed to do.

Each serial record carries:

• Current airworthiness status with the authorising document reference
• Installation history: tail number, position, date on, date off, cycles/hours at removal
• Repair history: work order references, repair station, findings, parts replaced
• Life-limited component (LLC) tracking if the assembly contains sub-components with independent limits
• Next due: the earliest of any scheduled maintenance interval, life limit, or calendar limit

The state transitions need to be enforced at the application layer, not just recorded. If a component is Unserviceable, the system should make it physically impossible to raise a pick order against it. This sounds obvious, but it requires the inventory and maintenance planning modules to share the same underlying status model rather than synchronising via batch jobs.

What Does the Right Architecture Look Like?

The data model question is separate from the technology question. You can build a rotable-aware system in PostgreSQL with a Django backend, in a graph database if your relationship queries are complex enough to warrant it, or on top of SAP's MRO-specific modules (PM + MM with serialised stock enabled). The technology choice is secondary to getting the domain model right first.

A few architectural decisions that matter:

Event sourcing for serial history. Rather than updating a single "current state" record, append every state change as an immutable event. This gives you a complete audit trail without needing separate logging infrastructure, and it makes compliance reporting significantly easier. The trade-off is query complexity: you need read models (materialised views or CQRS projections) to answer "what is the current status of serial X" efficiently.

Separate serviceable and unserviceable pools at the database level. Not as a status flag on a single table, but as physically separate records or warehouse locations enforced by the data model. This prevents the class of bugs where a status update fails silently and an unserviceable component gets picked.

Limit calculations as a service, not a column. Life limits change when regulatory amendments are issued. If you store "next due date" as a static column, you have to run update jobs every time a limit changes. If you store the raw parameters (cycles since new, hours since overhaul, last overhaul date) and calculate limits on read, a regulatory change becomes a configuration update rather than a data migration.

Integration with maintenance planning. The rotable pool and the maintenance schedule need to be the same system, or tightly integrated via a reliable event bus rather than nightly file exports. Scheduling a component for overhaul should immediately remove it from the available pool. A nightly sync means you're flying blind for 23 hours out of every 24.

When a Custom Build Is the Wrong Choice

If your operation is small (under a few hundred tracked serials), purpose-built MRO software like AMOS, Ramco Aviation, or IFS Aerospace is almost certainly the better call. These systems have spent decades encoding aviation regulatory requirements. Building equivalent compliance capability from scratch is a multi-year effort, and you're competing with vendors who've already done that work.

Custom builds make sense when your operational model doesn't fit standard MRO assumptions — defence applications with unusual security requirements, multi-modal operators mixing aviation and rail, or businesses where the rotable tracking needs to be embedded within a larger proprietary operational platform.

How Do You Handle Regulatory Compliance in the Data Model?

Compliance in rotable tracking isn't a reporting layer you bolt on. It's a structural constraint on the data model.

Airworthiness Directives (ADs) and Service Bulletins (SBs) reference specific part numbers and serial number ranges. The system needs to be able to answer: "Which of my serialised components are affected by AD 2023-15-08, and what is the compliance status of each?" That query requires linking regulatory document records to component records by part number range and tracking compliance actions as events on each serial.

Similarly, the EASA Part 145 / FAA Part 145 release documentation (Form 1 / 8130-3) needs to be a first-class record attached to each maintenance event, not a scanned PDF in a document management system with a manual link in a notes field.

Getting this right means working with your CAMO (Continuing Airworthiness Management Organisation) or equivalent during the design phase, not after development is complete.

Conclusion

Rotable inventory is a solved problem in the sense that the domain is well understood. It's an unsolved problem in the sense that most operations are still running it on systems that weren't designed for it.

If you're evaluating whether to customise an existing ERP, adopt a purpose-built MRO platform, or build something specific to your operation, start with the data model question. Map your actual state machine, your actual limit types, and your actual regulatory documentation requirements before you evaluate any technology. The technology decision follows naturally once you know exactly what the system needs to represent.

If you're building something custom and want to pressure-test the domain model before you start writing code, that's a conversation worth having early.

---

FAQ

Why can't we just use serial number tracking in our existing ERP? Most ERP serial tracking records where a unit is, not what it's allowed to do. Rotable management requires airworthiness status, maintenance event history, life-limit calculations, and regulatory document links as native data structures. Bolting these onto a generic serial tracking module typically produces the same shadow-spreadsheet problem you started with.

What's the difference between a rotable and a repairable? The terms overlap, but in most MRO contexts a rotable is a component that is routinely removed and returned to a pool for scheduled overhaul, while a repairable is one that is repaired on an unscheduled basis after failure. Tracking requirements are similar; the planning and forecasting logic differs because rotables have predictable removal intervals and repairables don't.

How many status states does a rotable typically need? Most operations need at least six: Serviceable, Unserviceable (Awaiting Inspection), Unserviceable (Repairable), In-Repair, Condemned, and Quarantine. Some add Serviceable (Limited) for components approaching a life limit, and In-Transit as a physical location state separate from airworthiness status. Fewer than six usually means the model is hiding information.

Can we handle rotable tracking in a spreadsheet for a small fleet? For a very small operation, maybe. The failure modes are well documented: version conflicts, no audit trail, no enforcement of state transitions, and no limit alerting. As soon as you have more than one person updating the spreadsheet, or more than a few dozen tracked serials, the error rate typically becomes operationally significant.

Does event sourcing add too much complexity for a team that just needs to ship? For the serial history specifically, yes, the complexity is worth it — regulators can ask for a complete component history going back years, and rebuilding that from update logs is painful. For other parts of the system, a conventional CRUD model is fine. You don't need event sourcing everywhere; you need it where the audit trail is a hard requirement.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.