Straight answers, including the ones with a caveat.

A multi-tenant enterprise asset management and maintenance management platform built for oil & gas, for oilfield-services firms, equipment manufacturers and project operators. It covers the equipment master, work orders, inspection and certification, reliability analytics, inventory, projects, workforce and suppliers, with Root, an AI assistant, over all of it.

Both, in the sense that matters. It manages the full asset lifecycle the way an EAM does (classification, properties, hierarchy, certification, reliability), and it manages the work performed on those assets the way a CMMS does.

Small and mid-sized businesses in oil & gas that need enterprise-grade asset discipline without an enterprise implementation. The domain model comes from a real oilfield-services maintenance system rather than from a generic asset template.

No. RelyentX is a standalone system of record and runs with no ERP at all. An optional sync with Epicor iScala, SAP or another ERP is planned and not available yet.

Rotating equipment, pressure vessels, separators, compressors, generators, flow meters, instruments and lifting gear among others. Classification is a five-level taxonomy and property sets are defined per class, so a class that is not there yet is added rather than forced into a generic shape.

Seven, as one closed set: hydro test, load test, MPI, UTI, visual inspection, SRV calibration and thickness. A certificate entered by hand is validated against that set. One path is deliberately looser: a discipline Root reads off an uploaded certificate is stored as extracted, so an imported certificate can carry a value outside the set. Where a scan yields no discipline at all, the import records a generic placeholder rather than choosing one of the seven on your behalf.

Both, and the split is worth knowing. SRV calibration is the one discipline whose certificate is produced in the product, from the readings you enter against a traceable master test device, on either the fixed nine-point DKD-9 scheme or a custom point count, and it flags the case where the reference device’s own calibration had expired on the test date. Every other discipline is uploaded and held against the equipment. RelyentX does not certify conformance to an inspection standard: the certifying body named on a certificate is yours.

It answers questions from your own data, showing the records it drew on, produces downloadable reports, extracts and draft checklists, and proposes allow-listed actions that you approve individually before anything runs.

It retrieves from your own records and is instructed to build answers only from what it finds, to cite those records, and to say so when a fact is missing. It is a language model, so treat what it produces as a draft to check rather than a guarantee, which is why, when an answer draws on retrieved records, those records are shown beside it.

No, and the site will not claim otherwise. RelyentX measures reliability from the events your work produced. There is no forecasting or anomaly-detection model in the product.

Yes. English and Arabic are both first-class, with a full right-to-left layout and an Arabic type face across the product and this site, not a translation layer over a left-to-right interface.

In a hosting location the infrastructure code restricts: it accepts only an approved set of locations and refuses any other value. We name the location, and every third party that processes your data, in writing before a pilot. Three AI features run at third-party providers, and each receives your data. To make records searchable, the text of every record and document is sent as it is written. To read documents, the page images and extracted text of a certificate imported from a chat, and the page images of a chat file our own text extraction could not read, are sent, up to a daily limit per workspace. The page images and extracted text of other scans our own extraction is not confident about, such as a file saved to a record, are sent only in a workspace where reading has been switched on, and it is off by default. To answer a question to Root, the question, the records retrieved for it and the text of any file attached to the chat are sent. Root answers and document reading are routed only to providers whose published policy is not to train on the request; the search-indexing provider states it never trains on API data. How long each provider keeps a request follows its own terms. This processing is not limited to where the platform is hosted. We name each provider in writing in the security review.

By the modules you turn on and the people who sign in. A seat covers one named person, and there is no per-site or per-asset charge. We are not publishing the module split or any figures yet; ask and you get both against your own scope.

Roles come from a fixed catalogue and are held as an additive set per user, on top of a view-only floor everyone has. Registering and editing equipment, and managing people, suppliers, projects, downloads and acceptance forms, each require a named permission at the endpoint; other changes today require a signed-in member of the tenant. Users are also scoped to the tenant’s country, business unit, project and package layers, and the database enforces tenant isolation on every row. The security page has the detail.

Book a demo. The useful version of that conversation runs against your asset classes and your certificate disciplines, so bring an example of both.