Mechanic AI

Mechanic AI is the judgement layer over work that already exists: which broken thing matters most, who fixes it, and what breaks next. Say "A60H-12 has a hydraulic leak — get someone on it" and Dozer sets a severity, picks the technician whose specialization and workload fit, and writes the assignment together with the reasoning behind it.

It owns no collection of its own. Triage and assignment are writes onto repair-tickets (owned by Daily Ops) and availability onto mechanics (owned by Site & Fleet) — which is also how you call it directly:

Update a repair-ticket — PATCH /api/v1/repair-tickets/a60h-12

curl -X PATCH "https://trydozer.com/api/v1/repair-tickets/a60h-12" \
  -H "Authorization: Bearer $DASH_API_KEY" \
  -H "Project-ID: pr_northpit" \
  -H "Content-Type: application/json" \
  -d '{"title":"title","status":"status","priority":"priority"}'

Assign the EXC-347 hydraulic ticket to Maria

data_set {
  "collection": "repair_tickets",
  "object_id": "a60h-12",
  "data": {
    "title": "title",
    "status": "status",
    "priority": "priority"
  }
}

{
  "object": "repair-ticket",
  "id": "obj_123",
  "title": "Hydraulic leak at the boom cylinder",
  "description": "Hydraulic leak at the boom cylinder — flagged on pre-trip",
  "location": "North Pit",
  "diagnosis": "Worn cylinder seal; replacement ordered",
  "hours_worked": 1,
  "created_at": "2026-07-25T12:00:00.000Z",
  "updated_at": "2026-07-25T12:00:00.000Z"
}

Let the agent do it

mechanic-dispatch owns triage, routing and escalation — hand it the symptom and it picks the technician.

tasks_create { "project_id": "pr_northpit", "skill_id": "mechanic-dispatch", "run": true,
               "prompt": "A60H-12 has a hydraulic leak — get someone on it." }
tasks_status { "task_id": "ts_…" }     // → the ticket, the assignment, and the reasoning

It reads far more than it writes — equipment, recent timeline events, open tickets, technician specialization and workload — and then assigns in a single batch: the ticket flips to assigned with assigned_mechanic set to the mechanic's object id (never a display name), a timeline event records who and why, and the mechanic's status flips in the same write. Closing a repair reverses it: ticket closed, mechanic available, equipment back to in_use, plus the work-order summary.

Severity governs urgency and is declared, not improvised: severity 1 dispatches immediately, severity 2 dispatches in turn but confirms first, severity 4 goes back to a mechanic to classify before anything dispatches. Nothing dispatches silently — every assignment writes the update and the event that explains it. Notification is gated on what is actually connected; with nothing connected the skill says so and skips the step rather than implying it sent.

predictive-maintenance reads the fleet daily and flags pre-emptive work from engine hours since service, recurring SPN/FMI codes and fuel-rate drift — "What should we service this week?" It never writes on its own: it summarizes the suggestions and asks "create these 3 tickets?", and a no writes nothing. Suggestions you confirm become tickets with a stable dedup key and telemetry provenance, so re-running the analysis tomorrow does not open the same ticket twice. code-lookup feeds the same queue from a dash fault code.

Writing a ticket by hand follows the same rules as Daily Ops: status is one of open / assigned / in_progress / closed, an assigned_mechanic must be a real mechanic id, and a validation failure names the field in param (Error Codes).

Next: Daily Ops for where tickets come from · Site & Fleet for the mechanics roster · Devices & Media for the telemetry that opens tickets before a human notices.