Frequently asked questions

The Industrial Data Utility is Mōksana's model for delivering clean, canonical MRO, spare-parts, and equipment data as an always-on service rather than a one-time project. Like an electricity or water utility, you connect to it and draw continuously updated, standardized, enriched part data on demand — through an API — instead of running periodic cleanup campaigns that decay the moment they finish.

Traditional cleansing is a project: you extract your material master, send it out, get a cleaned file back, and load it — then quality degrades again as new parts and sites come online. A utility is continuous. Mōksana standardizes and enriches records against a live 3M+ SKU knowledge graph and keeps them clean as your data changes, so you never re-buy the same cleanup. The result is a durable source of truth, not a snapshot.

Building and maintaining a canonical parts taxonomy, OEM reference library, and matching engine is a multi-year effort that most asset-heavy operators don't want to staff. Consuming it as a utility gives you the same canonical source of truth without the headcount: you point your systems at the API, and the normalization, enrichment, and governance run for you. You focus on uptime and procurement, not on data plumbing.

Asset-intensive industries — manufacturing, oil & gas, chemicals, mining, utilities, energy, and packaging — where millions of low-value SKUs, multiple ERP/EAM instances, and legacy free-text records make MRO data especially hard to govern. Teams that feel the pain most are maintenance planning, procurement, reliability engineering, and master data management.

MRO data enrichment is the process of adding missing or incomplete attributes to a part record — manufacturer name, manufacturer part number (MPN), descriptions, technical specifications, units of measure, lifecycle status, and classification codes — so each item is fully described and orderable. Enrichment draws from verified OEM catalogs, supplier libraries, and your own first-party sources such as BOMs, work orders, and technical documents.

It describes how much more complete your records become after Mōksana processes them. On average, enriched records carry roughly 3.7 times the usable, structured attributes of the original — turning sparse, free-text entries (often just a vague description) into fully specified parts with manufacturer data, specifications, and standardized classifications that planners and buyers can actually act on.

Two sources. Public/verified sources include OEM databases, supplier catalogs, and industry reference libraries used to populate manufacturer numbers, specs, and classification codes. First-party sources include your bills of materials, technical equipment documents, maintenance work orders, and invoices — where critical data is often trapped in unstructured PDFs. Mōksana extracts, structures, and reconciles both against its knowledge graph.

Yes. Beyond filling attributes, enrichment can flag current product status — active, discontinued (EOL), or not-recommended-for-new-design (NRND) — and surface successor parts. That lets buyers and planners see obsolescence risk before they order and plan controlled transitions or last-time-buys for critical spares.

SKU normalization is the standardization of part records into a consistent structure — uniform descriptions, naming conventions, units of measure, and classification — so the same physical item is represented the same way everywhere. It converts entries like "pump, gear, 2hp" and "2 HP gear pump, cast iron" into one canonical, structured record aligned to standards such as UNSPSC, eCl@ss, or ISO 8000.

ERPs require near-exact matches, so a single character or spacing difference hides a duplicate. Mōksana uses machine learning and natural-language matching against its 3M+ SKU knowledge graph to recognize parts by meaning, specifications, and manufacturer references — not just text. It catches linguistic variations, regional naming, and vendor inconsistencies, and returns confidence-scored matches rather than rigid yes/no results.

Duplicates fragment a part across multiple records and locations, hiding true stock levels. A technician searching one description may not see the same part stocked under another, so they reorder or wait — extending mean time to repair while the part sits on a shelf nearby. Normalizing to one canonical record restores cross-site visibility so available stock is actually findable.

It reflects the share of part records Mōksana confidently matches and resolves automatically against its knowledge graph. High-confidence matches are applied directly; ambiguous or critical items can be routed for human-in-the-loop review, so you get scale without sacrificing the precision that regulated and safety-critical spares demand.

Mōksana is API-first and designed to sit as a master-data layer between your systems of record — including SAP (ECC and S/4HANA), Oracle, and IBM Maximo, alongside EAM, WMS, and supplier-catalog sources. Rather than replacing these systems, it harmonizes the part data flowing through them so each one references the same canonical record.

No. Mōksana layers onto your existing systems through its API and applies changes back to your material master via change requests — so you keep your ERP/CMMS of record and simply feed it clean, enriched, deduplicated data. Asset-heavy operators have unlocked significant working-capital savings this way without an ERP migration.

Yes — migrations are one of the highest-value moments to normalize. Without cleansing, a migration carries forward every duplicate and incomplete record unchanged. Running data through Mōksana first means S/4HANA (or any target) is loaded with a deduplicated, enriched, standards-aligned master from day one, instead of inheriting legacy data debt.

Your systems call Mōksana's API to normalize and enrich part records — at creation time to prevent new duplicates, or in bulk to remediate an existing master. The platform's product tiers (Core, API, Flow, Index, Engine, and Nexus) let you consume capabilities programmatically, from single-record lookups to continuous synchronization across multiple sites and ERP instances.

Yes. Because ERPs don't natively validate new records against meaning, duplicates re-accumulate after every cleanup. Mōksana can validate a new material request against the knowledge graph before it's created — checking manufacturer data and existing records — so governance is enforced at entry and your master stays clean over time, not just after a project.

It's a structured, canonical reference of more than 3 million SKUs that maps parts, manufacturers, specifications, classifications, and the relationships between them. Every record you send is matched and enriched against this graph, which is what lets Mōksana recognize that two differently-worded entries are the same physical part — and supply the attributes either one is missing.

A flat database stores records in isolation; a knowledge graph stores relationships — which manufacturer makes a part, which assets it fits, which items are interchangeable, and which successor replaces a discontinued SKU. Those connections power smarter matching, cross-referencing, and obsolescence handling that simple lookup tables can't, and they get richer as the graph grows.

Yes — that's the design point. You don't need to pre-clean anything. Mōksana's matching works directly on inconsistent, free-text, and incomplete records, using the knowledge graph to resolve them into canonical parts. The messier the starting data, the more enrichment and deduplication value the graph delivers.

Mōksana combines automated, AI-driven matching at scale with human-in-the-loop validation for critical spares, regulated items, and ambiguous records. High-confidence changes apply automatically; sensitive ones are routed for approval — so you get both throughput and the control that safety-critical and audited environments require.