Asset Maintenance Workflow: how to automate it

An asset maintenance workflow can fail before anyone picks up a tool.

A vibration event arrives twice after a delivery retry. A preventive inspection is already open on the same conveyor drive. The first reading breaches the threshold that was effective when the event occurred. An older reading then arrives after the repair has been completed. If the software treats every message as a new fact, it can create duplicate work, apply today's rule to yesterday's evidence, or silently reopen a machine that has already passed through completion and return-to-service decisions.

That is not a reminder problem. It is an authority problem.

In week 14 of our case-study series, SwarmCraft structured and completed a 65-task customer-owned asset maintenance operation for Harbourline Foods, a fictional three-site food manufacturer. The application replaces MaintainX as the maintenance system of record inside the agreed boundary: canonical assets, observations, anomaly evaluation, preventive and corrective work, parts coordination, downtime, technician evidence, completion, return to service, migration evidence, access decisions, and append-only history.

The project goes beyond wrapping another computerized maintenance management system (CMMS) with forms and notifications. It takes ownership of the records that make the maintenance operation coherent.

If you want the category landscape first, start with Best asset management software. For the cost and duplication problem around the category, read Why asset software sprawl hides in requests, reminders, and maintenance. The MaintainX alternatives article approaches the same decision from the switching side.

The case for replacing the maintenance record

The replacement case is not based on a hypothetical dislike of SaaS. Maintenance practitioners describe concrete friction.

In one Industrial Maintenance discussion about replacing MaintainX, the original poster reports weak parts search, inaccessible asset history on iPads, and limited control over work-order forms. Other participants describe preventive-maintenance configuration and asset ordering problems. A recent MaintainX review on G2 raises a closely related operational issue: requester visibility can lead to duplicate work orders, while reporting and consolidated exports still require work.

Those accounts are anecdotes, not a statistical verdict. They are useful because they expose the same boundary we tested: parts, asset history, work relationships, requester visibility, and reporting are not isolated features when they all shape one maintenance decision.

MaintainX itself documents a capable REST API, signed webhooks, and separate data exports for requests, work orders, assets, locations, parts, meters, costs, and other record types in its export guidance. That breadth makes migration possible, but it also shows why replacement is not a single CSV import. The objects, relationships, files, quantities, currencies, timestamps, decisions, and open states have to arrive as one trustworthy operation.

The operation boundary we chose

The application owns the maintenance record. Adjacent specialist systems exchange bounded facts without gaining authority over it.

This is a MaintainX replacement with a disciplined perimeter. The boundary follows the complete maintenance operation rather than the incumbent's product catalogue.

Project stats

The initial driver completed every selected task in 65 agent requests. A later human-directed recovery fixed one ambiguous database trigger, repaired brittle browser assertions, established a repository-native design system, regenerated all screenshot evidence, and brought every recorded test tier to green on 6 September 2026.

This is a substantial production-shaped foundation, not evidence of a completed customer cutover. The target has no live MaintainX account, customer mappings, production identity configuration, industrial connector, model provider, object store, or rehearsed production recovery environment. Those are named adoption tasks on top of an implemented and tested operational boundary.

The asset maintenance workflow we built

The story follows one Packaging Line 3 conveyor drive from evidence to repair and then through a late-event reconciliation.

Eight actors have distinct responsibilities.

Asset maintenance workflow steps

The implemented asset maintenance process follows this sequence:

1. Establish the canonical conveyor-drive identity, hierarchy, criticality, lifecycle, external references, effective maintenance plan, threshold versions, and procedure versions.
2. Admit each telemetry delivery as immutable raw evidence with a source identifier, sequence, observed time, unit, value, quality, and delivery identity.
3. Preserve both deliveries when a retry occurs, but create only one governed observation for the same source event.
4. Evaluate that observation under the threshold and suppression versions effective at its original observedAt time.
5. Open one anomaly and surface the already-open preventive inspection without merging its lifecycle into corrective work.
6. Let bounded AI summarise cited readings, history, procedure context, likely fault, missing evidence, and candidate parts.
7. Require the reliability engineer to consider or dismiss that advice and separately create governed corrective work with a reason, priority, required skill, procedure version, and evidence contract.
8. Reserve the bearing at its source site, dispatch and receive the cross-site transfer, and preserve quantity, decimal scale, operational unit cost, currency, valuation date, and source provenance.
9. Request a downtime window with asset criticality, current condition, scope, parts readiness, duration estimate, and consequence.
10. Allow the assigned technician to start only after the part, procedure, evidence requirements, and approved window are visible.
11. Capture readings, procedure steps, photographs, findings, failure code, labour, downtime, installed and returned parts, notes, and deviations.
12. Reject incomplete completion submissions without changing authoritative work state.
13. Record maintenance approval of technical completion and a distinct authorised return-to-service decision.
14. Consume the installed bearing transactionally, release unused quantity, and retain operational cost provenance.
15. Accept the late vibration observation after repair, evaluate it under historical rules, and route it to reconciliation without silently reopening the asset or creating another work order.
16. Append the reconciliation decision and preserve the complete source-time-ordered asset history.

These asset maintenance workflow steps form a practical asset maintenance workflow template: delivery is not observation, observation is not anomaly, anomaly is not work, AI advice is not diagnosis, completion is not return to service, and a late event is not permission to rewrite history.

One event arrived twice, but work happened once

The first browser journey retains the original vibration delivery, a second delivery of the same source event, and an exact replay. It then shows the one governed observation and the threshold evaluation that produced one anomaly.

The distinction matters for connected maintenance. MaintainX's own webhook guidance tells integrators to acknowledge quickly, process asynchronously, implement retries, and make handlers idempotent. The owned API goes further by preserving the raw delivery attempts while suppressing duplicate consequences. It can explain both what arrived and why only one item of governed work followed.

The preventive inspection remains related but separate. A reliability engineer can decide that it supplies enough scope, link it to corrective work, or record why new corrective work is required. A shared asset does not collapse two different purposes into one generic work order.

AI assists diagnosis without acquiring authority

The AI surface receives an allow-listed evidence packet. Each output section must cite the supplied evidence identifiers and carry explicit uncertainty, provider, model version, and prompt version. Unknown citations, unexpected fields, missing uncertainty, and language that claims approval or machine-control authority are rejected.

The reliability engineer can record that the advice was considered or dismissed. That disposition does not approve a bearing diagnosis, create work, reserve a part, approve downtime, complete a repair, or return the conveyor drive to service. Deterministic code and accountable people retain those powers.

That is the useful AI distinction for this asset management workflow. AI compresses the reading work across telemetry, history, procedures, related work, and parts context. It does not become the maintenance system of record.

The repair is a governed chain, not a green status

The corrective path joins several records without allowing one to impersonate another:

• the bearing reservation and cross-site transfer retain exact movement and provenance;
• production approves a bounded downtime window;
• only the assigned technician can start and submit the work;
• completion eligibility is recalculated by the API from persisted evidence;
• maintenance reviews technical completion; and
• return to service is requested and decided separately.

The browser also proves the failure path. A missing photograph, wrong reading unit, incomplete procedure step, absent parts evidence, or missing reason produces a deterministic completion_ineligible response. The rejected attempt remains visible and work stays in progress. A browser button cannot manufacture eligibility.

Return to service is deliberately narrow. It is the maintenance operation's recorded disposition after approved completion and acknowledged external prerequisites. It does not start the conveyor, override isolation, or claim physical safety.

Late evidence does not rewrite a completed repair

The final twist is an older source observation that arrives after completion. The API accepts the distinct observation, marks it late and out of order, evaluates it against the versions effective at the time it occurred, and appends a review-required reconciliation with automaticAssetAction: none.

The reliability engineer can record that it was already covered, new evidence, a sensor fault, or a separate anomaly. Until that governed decision occurs, the system does not reopen the asset, duplicate the repair, or revise an earlier decision.

This is where an owned equipment maintenance workflow earns its value. The current state remains readable, while the full append-only history can still answer what happened, when the source says it happened, when the application learned about it, which rules applied, and whose decision changed the operation.

Migrating amounts is part of migrating authority

The migration workspace is one of the strongest parts of the build because it refuses to reduce the MaintainX replacement to record counts.

The inventory covers sites, locations, hierarchy, identifiers, criticality, procedures and versions, preventive maintenance, meters and readings, requests, work relationships, parts, files, users, roles, integrations, open exceptions, and audit references. Each export records its identity and time, schema version, file hashes, row and attachment counts, currencies, decimal scales, relationships, unsupported fields, and known limitations.

The parallel comparison then places retained source values beside proposed canonical records. It samples status history, hierarchy, file integrity, exact quantities, amounts with currencies, and open relationships. An unresolved parent mapping or amount mismatch stays visible instead of being coerced into a plausible-looking destination.

The tested presentation carries amount migration explicitly:

• quantities use decimal rather than binary floating-point semantics;
• unit, scale, and source authority travel with every quantity;
• money retains currency, precision, valuation date, and source provenance;
• reconciliation compares amount totals by currency rather than inventing a converted grand total; and
• operational maintenance cost never pretends to be an accounting-ledger balance.

The cutover surface remains blocked until required comparisons, exception dispositions, and governing decisions exist. Its disabled action is not decorative; Playwright asserts that missing authority cannot be supplied by the browser.

The designed transition uses one writer at every moment: inventory, dry runs, correction, repeatable reruns, parallel comparison, a source-side write freeze, final delta import, reconciliation, explicit activation, integration redirect, monitored operation, and retained rollback evidence. The current target implements the read-only migration and comparison contract plus the browser proof. Live extraction, customer mapping, canonical migration writes, durable activation records, and production execution still require customer-specific implementation and rehearsal.

What the custom asset maintenance operation includes

Technology implemented

What the browser evidence proves

The maintained browser and API-backed system evidence covers:

• duplicate and replay deliveries producing one governed observation;
• source-time threshold selection and one anomaly;
• separate preventive and corrective work lifecycles;
• cited AI advice with no authoritative side effect;
• exact parts reservation and cross-site transfer;
• downtime, technician evidence, completion, and return-to-service gates;
• rejected incomplete completion with unchanged work state;
• a late observation routed to reconciliation with no silent reopen;
• server-side access denial with unchanged protected records;
• degraded telemetry intake followed by exactly-once recovery;
• migration inventory, exception ownership, parallel comparison, amounts, quantities, files, cutover readiness, and rollback evidence;
• responsive layout at 390 pixels; and
• six representative axe-tagged accessibility checks.

The screenshots use deterministic fictional data. They prove what the target implements and what the tests assert. They do not prove a Harbourline Foods deployment, a live MaintainX migration, legal compliance, physical machine safety, or achieved production recovery objectives.

How SwarmCraft structured the build

SwarmCraft created the 65-task Asset Maintenance project before implementation. The plan moved from living discovery records and repository foundations through identity, permissions, PostgreSQL, canonical assets, observations, anomaly rules, preventive and corrective work, parts, governed execution, migration, browser evidence, accessibility, production packaging, CI, observability, cutover, and recovery.

That sequence matters. The design did not begin with a dashboard and add authority later. Stable identity, record classification, history, permissions, amounts, and failure semantics were established before the user-facing maintenance and migration surfaces that depend on them.

The post-build design-system pass corrected an equally important weakness. The initial interface had grown feature by feature without one visual consumer contract. The recovered target now declares a single design-system entry point, typed exports, semantic colours, status language, spacing and typography foundations, accessibility rules, an inventory, adoption guidance, and a runnable workbench. The refreshed screenshots therefore show one calm industrial operating language rather than a pile of locally styled AI-generated panels.

What this says about AI-built workflow software

AI contributed in two different places, and they should not be confused.

First, an AI build agent turned a detailed operational scenario into 65 independently completed tasks across product code, database migrations, tests, infrastructure, and runbooks. The output became credible only when repository evidence, database constraints, browser assertions, and human review exposed and repaired its gaps.

Second, the product contains a bounded AI advisory surface. It can retrieve approved context and prepare a cited diagnostic briefing. It cannot change a canonical asset, set a threshold, approve its own diagnosis, create authoritative work without a governed rule or human decision, approve downtime, consume stock, close work, return equipment to service, or issue an industrial-control command.

That separation is the opportunity. AI can make a specialised owned API and interface economically practical, then assist inside the operation without becoming its authority.

Replace the record, then own the responsibility

The Week 14 result is not a nicer request form around MaintainX. It is an owned maintenance operation with one canonical asset identity and one reproducible path from machine evidence to accountable work.

The replacement becomes credible when the organisation can answer these questions from its own records:

1. Which asset did the evidence belong to?
2. Which source event arrived, how many delivery attempts occurred, and which observation became governed?
3. Which rule versions were effective at the event's source time?
4. Why did preventive and corrective work remain related but separate?
5. What did AI suggest, which evidence did it cite, and what did a person decide?
6. Which part quantity moved, at what operational unit cost and currency, and with what provenance?
7. Who approved downtime, completion, and return to service for their separate purposes?
8. What changed when late evidence arrived—and what deliberately did not?
9. Did every migrated record, relationship, file, quantity, amount, currency, open state, and sampled history reconcile?
10. At the activation instant, which system was the sole writer and what evidence supports recovery if cutover fails?

Owning those answers is what turns asset maintenance automation into an asset maintenance system of record.

Use Deep Discovery to plan the MaintainX replacement

A MaintainX replacement crosses source inventory, asset identity, history, telemetry, work, parts, amounts, access, integrations, cutover, continuity, and operational responsibility. Deep Discovery is the route for mapping those records and controls into a coherent owned operation. It is currently available through a limited account-enabled rollout.

The goal is not another maintenance dashboard. It is a complete asset maintenance workflow that the organisation can operate, explain, recover, and improve on its own terms.