A configurable enterprise operations platform for complex, field-driven work.
MX is the central platform where operational data, workflows, assets, people, locations, forms, inspections, mobile field activity, reporting, and AI-enabled automation come together. Configurable enough to support different operational models — governed enough for the enterprise.
↳ Built for the operations that cannot wait.
Five disciplines. One platform.
MX is built around five operational disciplines that share a common data model, permission system, audit trail, and field execution layer. They reinforce each other — that is the point.
↳ Supported by Business Intelligence (BI) and Artificial Intelligence (AI) layers, hooking into data from each block.
Your operation. Your objects. Your workflow.
MX is not a fixed schema with a few custom fields tacked on. The data model is configurable — object types, fields, relationships, statuses, workflows — and configuration is governed, versioned, and reversible.
Object types
Work orders, assets, locations, forms, inspections, crews, equipment, sites — and anything else your operation needs to model.
Fields, refs, geometry
Typed fields. Relationships across objects. Geometry attributes (point / line / polygon) on anything that has a location.
Workflow states
State machines per object type. Transitions gated by role, condition, location, or time. Escalations built in.
Versioned & audited
Every config change is versioned, peer-reviewable, and reversible. No live tinkering against production data.
↳ Configurable, not lightweight. MX retains the data integrity and control of an enterprise platform. Your own team configures it: scheduled jobs, settings, and AI-drafted forms and dashboards are all self-service.
Everything an action touches is governed.
No default of 'admin can see everything'. Permissions apply to reads, writes, workflow transitions, AI tool calls, and configuration changes — across data, work, fields, and integrations.
↳ AI agents are subject to the same permission model as users. There is no AI bypass.
Who did what, where, when, and why.
Every action — by user, by mobile crew, by integration, by AI agent — is recorded with context. The audit trail is not a separate log; it is how MX remembers.
Every load accounted for, out as well as in.
Debris haul, equipment moves and demobilization are where recovery budgets leak. In MX each load is a record — bill of lading, hauler, tracked movement — reconciled into its purchase order at day end. Raising one is a guided flow, not an afternoon of paperwork.
Bill of lading per load
Every movement — debris out, equipment between sites, plant home at demob — is a load with a bill of lading: what, how much, from where, to where, and by whom. A load can be prepared before the driver is known, or recorded after the move, and issued when it is ready.
Hauler assignment
Loads are assigned to haulage vendors and their vehicles. The vendor works within its own scope, the same way a subcontractor does on a multi-employer site.
The haulers, not just the loads
Carriers and brokers are companies in MX — contacts, dispatch email, their own people — imported from the list you keep today. Insurance certificates and tax forms sit against the company with an expiry date, and MX warns you by email before cover lapses, rather than leaving it to a diary note. When a load is raised, the pickers offer the carriers you work with and leave out the ones you have retired.
Tracked while it moves
Pickup, transit, and delivery are recorded against the load, with the weight ticket or delivery evidence attached at the point it exists.
Reconciled into purchase orders
At day end the loads are reconciled against the purchase order they draw on. A load that does not match is held with its reason, not lost in the total.
The loads that need chasing, listed
A needs-attention view flags the transports that are overdue, the ones nobody has picked up, anything booked on two jobs at once, and loads recorded as delivered somewhere other than their destination. Each flag links to its job, and how long each check waits before it complains is set per program.
Cold chain, in the same place as the load
A refrigerated trailer shows its supply, return and ambient air temperature against the set point it is holding, with a chart of how it has behaved over the last day, week or month. On the map every reefer is colored by what it is actually doing — holding, drifting out of range, switched off, or no longer reporting at all. The silent one is the one that costs you a load. And a trailer drifting out of range does not wait to be noticed — the reading raises a work request against that unit, at its location, in front of whoever covers it. So does a tracker that has stopped reporting altogether.
The rest of the platform, in brief.
The same data model and permissions underlie everything else MX offers — so each capability stays connected to the operation around it.
One platform.
Configured to your operation.
Walk us through the work you manage today. We will map MX to it — what it looks like configured, what it integrates with, and what it changes.

