Equipment answers scoped to model and revision.

Start with the asset

Most maintenance questions are not answerable until the machine is identified. Two units of one product line can differ by model variant, serial range or firmware revision, and with them the fault causes, torque values and part numbers.

Asset identity is therefore resolved before the question is answered, from an asset tag, a serial plate photograph or the work order's asset, depending on what your asset register exposes. Where it cannot be resolved, the system asks rather than returning text that reads correctly but describes another machine.

What the implementation can include

Retrieval over manuals, bulletins, procedures and parts catalogues; asset resolution from tags or nameplate images; read and write access to an agreed maintenance management system; and offline caching where licences permit. Scope depends on what your CMMS, ERP and inventory APIs expose. This page describes work that can be scoped for a project, not a system already running at a customer site.

Manuals, bulletins and the applicability problem

Equipment documentation is rarely a uniform corpus. It can include print-layout OEM manuals, scanned installation instructions, bulletins that amend a manual without replacing it, exploded parts diagrams whose callout numbers are the only link to a part number, and tables that lose meaning when flattened.

Applicability is held as metadata rather than inferred from text: the models a passage covers, the serial or build range, the firmware revision and the engineering change level. That metadata rarely exists in the source documents, and producing it from title pages, bulletin headers and effectivity tables is a measurable part of the build, with coverage established on a sample of your own documents, scanned pages included.

Retrieval filters on those fields before ranking, the pre-ranking metadata filtering described on our RAG chatbot development page, so passages labelled for another revision are excluded. Passages whose applicability cannot be determined are the hard case: withholding them costs recall, including them voids the filter, so the rule for them is agreed before implementation, and scored against cases drawn from closed work orders.

Safety-critical procedures are retrieved, not generated

Some requests must not be answered by composed text: energy isolation and lockout, confined space entry, hot work, stored energy in accumulators and capacitors, arc flash boundaries and PPE selection. A wrong instruction has a physical consequence, and a procedure assembled from two sources is not the controlled procedure.

Those requests are classified at intake and escalate rather than being answered from a best guess. The system returns the controlling document with its revision, which for energy isolation is your own energy control procedure rather than an OEM manual page, or routes the request to a named person. It does not issue, approve or stand in for a permit, an isolation certificate or an arc flash assessment.

Which requests fall into this class, and what each routes to, is defined by your safety function, and we build the classification and routing to that definition. We do not write, approve or advise on safety procedures, permit systems or compliance obligations.

Writing to the maintenance management system

A CMMS or field service write is a compliance event. A work order carries required fields that differ by site: functional location, asset, problem, cause and remedy codes, time booked, parts issued, status transitions and sometimes a permit reference.

Writes are therefore built as typed tool contracts with validation, in the way described on our AI automation services page: the asset must exist, the status transition must be legal in your configured workflow, and a failure code must come from your own catalogue. Which actions run directly and which queue for approval is agreed per action.

Technicians retry on intermittent connections, so every queued write carries a client-generated reference. Where the target system can store that reference and enforce uniqueness, the write is idempotent at the system of record. Many maintenance endpoints cannot, and duplicates are then caught in the queue before the call. Which applies is established against your API.

Parts availability across storeroom, van and supplier

Stock sits in a plant storeroom, in van stock, on consignment and in transit, and some is reserved against another work order. On-hand quantity is not availability, so a figure ignoring reservations and location can point at committed stock or stock at another site.

An OEM number, your internal material number and a supplier catalogue number can all refer to one item. A superseded predecessor is different: supersession runs in one direction, sometimes several steps deep, and sometimes replaces one part with a kit or with a part needing other changes to fit. A lookup follows that chain and states where it ended.

Offline capability and hands-busy use

The network is often absent where the work happens, in plant basements, machine rooms and customer premises without guest access. An offline design caches documents with their applicability metadata, queues writes for replay and resolves conflicts with planner changes. What gets cached is a design decision: scheduled work can be cached per assignment, but breakdown work names the asset at dispatch, so a cache is usually scoped by site, line or asset class against a storage budget, with defined behaviour when an asset is not cached.

Whether documents may be cached at all is checked first. OEM manuals and bulletins are usually licensed rather than owned and often arrive under portal terms restricting copying or offline storage, so the permitted scope of a cache is established with those terms in hand.

Gloves, hearing protection and line noise constrain the interface: short answers readable at arm's length, push-to-talk rather than open microphones, and confirmation that does not need precise touch targets. Hazardous areas restrict which devices may be carried.

What a project costs

Every engagement starts with a fixed-price discovery sprint at USD 2,500 over two weeks, which produces the architecture, initial screen designs, acceptance criteria, a running-cost model and a fixed price for the build. The sprint fee is deducted from the build.

Running cost has an ingestion component that recurs whenever an OEM issues a revised manual or bulletin, a per-question component across retrieval, reranking and the model call, index storage and the cost of distributing offline caches. A shutdown or seasonal peak concentrates questions into a few weeks, so the model is built from your own pattern.

Part of the AI Feature Implementation Sprint → · Explore our work → · Discuss an AI project →