Preventive Maintenance & Service Ops
Work order scheduling, parts inventory linkage, inspection checklists and tire lifecycle — the group with a UI-wired 2-stage AI diagnostic on every screen.
What this group does
Preventive Maintenance & Service Ops schedules work, links parts inventory to it, runs driver safety inspections, and tracks tire wear — all 4 screens use the add-on’s 2-stage AI diagnostic pattern (see Overview), and on every one of them Stage 1 is a real, working “Search …” button in the record’s modal, not embedded-but-unwired code.
Screen preview
A quick look at the screen. Use the toggle in the corner to switch between the dark and light themes.
Work orders, parts and tire tracking
The shared 2-stage engine in this group
| Screen | What Stage 1 Compares Against | What Stage 2 Diagnoses | What You See in the Result |
|---|---|---|---|
| Work Order Scheduler | Other maintenance rules and work orders on the same screen | Runs the work order audit | Whether the job meets its SLA, an overdue-risk rating (critical/high/medium/low), recurring-component risk, whether a schedule conflict was detected, the recommended technician skill, an estimated cost range, and a summary |
| Parts Inventory Link | Other parts and compatibility records on the same screen | Runs the parts inventory audit | A stockout-risk rating (critical/high/medium/low), the impact of active reservations, suggested alternative parts, an estimated reorder lead time, a recommended reorder quantity, and a summary |
| Inspection Checklist | Other inspection standards and checklists on the same screen | Runs the inspection audit | Whether the vehicle is at out-of-service risk, a list of critical safety defects, a severity grade, DOT compliance status, a recommended action, and a summary |
| Tire Lifecycle Tracker | Other tire telemetry records on the same screen | Runs the tire lifecycle audit | The wear rate (mm per 1,000 km), a predicted replacement distance, whether an alignment anomaly was detected, a description of that anomaly, a recommended action, and a summary |
All 4 screens’ Stage 1 search compares the current record against every other live record on the same screen — there is no static reference corpus (e.g. an OEM service bulletin library); the candidate pool is the screen’s own ledger. All 4 use the same underlying similarity-search logic and route to the user’s local Ollama only. Stage 2 result is rendered in the modal and is never saved to the record — permanent effects come from a separate action button (see below).
1. Work Order Scheduler
Purpose: Vehicle-linked maintenance/repair work orders (Scheduled PM, Emergency Repair, Recall Service) by scheduled date, assigned workshop/technician, estimated cost and status.
Ledger columns
- Vehicle id/plate/VIN, title, description
- Maintenance type — scheduled PM / emergency repair / recall service
- Scheduled date, assigned workshop, estimated cost, priority (low–critical)
- Status — scheduled / in progress / on hold / completed (plus legacy
open, kept for backward compatibility and rendered identically toscheduled) - Source device and fault code — populated when the work order was auto-created by Telematics & IoT Config’s alarm trigger
Key actions
Standard create/edit/delete, plus the 2-stage diagnostic modal above. There is no separate persistent action beyond editing status/fields directly.
ID format: WO-YYYY-XXXX. Saved automatically to the server.
2. Parts Inventory Link
Purpose: Allocates spare parts inventory against open work orders — SKU, compatible vehicle models, stock qty, reorder point and allocation status.
Ledger columns
- Part SKU, description, compatible vehicle models
- In-stock qty, reorder point, unit cost
- Allocation status — reserved for WO / in stock / backordered, reserved work order id
ID format: PRT-YYYY-XXXX. Saved automatically to the server.
3. Inspection Checklist
Purpose: Driver safety inspections (Pre-Trip DVIR, Post-Trip, Annual Safety) by failed item count, severity grade and audit status.
Ledger columns
- Vehicle id/plate/VIN, inspector name, inspection type, inspection date
- Failed item count and description
- Severity grade — pass / minor defect / out-of-service risk
- Audit status — approved / work order triggered, triggered work order id
ID format: INS-YYYY-XXXX. Saved automatically to the server.
4. Tire Lifecycle Tracker
The Tire Lifecycle agent is a sector-specific agent: it is written with fleet maintenance domain expertise, so it reads tread depth, distance and pressure the way a tire specialist would and checks them against tire wear standards instead of generic rules.
Purpose: Per-vehicle, per-axle-position (front-left, front-right, 4 distinct rear positions, spare) tread depth, cumulative distance and pressure telemetry.
Ledger columns
- Vehicle id/plate, axle position, DOT serial code
- Tread depth (mm), total distance (km), pressure (psi)
- Status — good / rotation due / immediate replacement
ID format: TIR-YYYY-XXXX. Saved automatically to the server.
Adding a tire: in the New Tire window, the Vehicle field is a searchable list — type a plate or model to filter your vehicles. Vehicles are created in the Fleet module, not from this window. In the table, the highlighted sparkle button on each row opens the AI diagnostic described below.
What it does
From a tire’s tread depth, total distance and pressure, the diagnostic produces (1) the wear rate (mm per 1,000 km), (2) the distance at which the tire should be replaced, (3) whether there is an alignment or irregular-wear anomaly, and (4) a recommended action and a short summary.
Unlike simpler diagnostics, this agent can read the standards reference when it needs values it wasn’t given. It opens the tire wear standards and looks up the new-tread depth for the vehicle class, the replacement threshold, the inflation-pressure range and the allowed tread difference between the two tires on the same axle.
Current limitations
Heavy vehicles currently assume light-vehicle standards
Vehicle class isn’t sent with the request, so heavy truck/bus results are indicative only. The standards depend on the vehicle class (light vehicle or heavy truck/bus), but the diagnostic only receives the plate, axle position and measurements. Unless the related records say what kind of vehicle it is, the agent assumes a light vehicle.
Nothing is saved to the tire record
The result disappears when you close the window. To act on it, use a separate action such as scheduling a rotation or replacement.
How it works
- Pick a tire. In the ledger, click the Run Tread Wear & Alignment Diagnostic button on the tire’s row. The 2-stage diagnostic window opens for that tire.
- Stage 1 — related tire records (optional). Click Search Wear Specs. The screen compares this tire with the other tire records in the ledger (same vehicle, similar position, similar wear) and lists the closest matches, each with a checkbox. Untick the ones you don’t want to send. If you skip this step, every other tire record in the ledger is sent instead.
- Stage 2 — the diagnostic. Click Run Stage 2 Diagnostic. The screen sends the tire’s vehicle plate, axle position, tread depth, total distance, pressure and the selected related records to the server. The button reads “Running diagnostic…” while the agent works.
- The diagnostic runs in steps. The server checks your sign-in and then asks the AI model to assess the tire. The model can answer straight away, or it can first ask to read the tire wear standards reference. If it does, the server reads the document for it (the agent can only read documents provided for the Fleet Ops add-on, nothing else), hands the content back, and the model then calculates the wear rate and replacement distance with the real thresholds. This can take up to 5 rounds; most diagnostics need 2.
- The answer is checked. The server confirms that the model’s answer contains every expected field with the right type. If something is missing, the model is asked to correct it before you see anything.
- The result appears in the window. You see an Alignment Anomaly Detected / No Alignment Anomaly badge, the summary, the wear rate, the predicted replacement distance, the anomaly description (only when an anomaly was found) and the recommended action. You never see the intermediate steps.
- Logging. Runs are logged. See Observability.
Which engines support multi-step: multi-step behavior requires Cloud LLM or Local LLM. See Agentic AI overview for details.
What to expect
- Waiting time: the step-by-step diagnostic needs at least two AI rounds, so it takes longer than the other diagnostics in this group — typically between a few seconds and about a minute, depending on the engine.
- A tire already below the replacement threshold is reported with a predicted replacement distance of 0 km (replace now).
- If the diagnostic cannot finish within 5 rounds, or the AI provider returns an error, the window shows a red error message instead of a result.
Server routing (all 4 screens)
Stage 2 for all 4 screens routes through whichever AI engine you’ve selected in Settings → Agentic. When Ollama, Local LLM or Web LLM is selected, the analysis runs entirely on your machine or in your browser and never reaches the server — the Render server has no network path to a user’s own Ollama instance. With Cloud LLM (API) selected, the server handles the analysis instead, calling the Anthropic or Cohere API depending on the selected mode. Every server call is logged (duration, model, success/failure, screen name), visible in Settings → Analytics.
Why the routing check matters
Skipping this check and always calling the server would produce a nonsense error whenever a user has selected Ollama — the server cannot reach a user’s own machine.
Embedded AI Assistant
Every screen in this group has an embedded AI Assistant panel docked to the right edge. Tick one or more rows in the ledger and the panel lists them under Selected, with Analyze and Summarize shortcuts that send those records to the assistant by id and key fields. With no selection it works on the whole ledger. The ledgers are also paginated, with the page size adapting to your screen height.
| Screen | Example suggestions |
|---|---|
| Work Order Scheduler | Flag overdue high-priority orders; list orders with no workshop assigned |
| Parts Inventory Link | Flag parts at or below the reorder point; list reserved parts with no work order |
| Inspection Checklist | Flag severe failures with no work order; list vehicles with repeated failed items |
| Tire Lifecycle Tracker | Flag tires below minimum tread depth; list tires with abnormal pressure |
- Save as Report stores an assistant answer in the reports list so it can be reopened later.
- Add Knowledge attaches your own reference text so the assistant answers with it as additional context.
- The assistant follows the engine you selected in Settings → Agentic. With Ollama, Local LLM or Web LLM it runs on your machine or in your browser and never reaches the server. Panel width, font size, accent color and whether it opens automatically are controlled in Settings → AI Assistant.
Pages in this section
Frequently Asked Questions
open work order status mean?scheduled/in_progress/on_hold/completed set (Telematics & IoT Config’s alarm trigger used to create work orders with this status) and is kept for backward compatibility — the UI renders it identically to scheduled.